Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Linkage between SOA and API based on CDIF

2025-04-07 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)06/01 Report--

For thousands of years, the story of the Tower of Babel has been a core dilemma faced by mankind. In order to communicate and communicate, we humans have created language, but there are still obstacles to communication. There is still a huge gap in the communication between the same language according to the context, and it is even more difficult for people to worry about the communication between different languages.

Today, with the highly developed material civilization and artificial intelligence, programmers are also facing such a dilemma. Based on the technical conditions at that time and the business requirements at that time, our ancestors gradually developed imperative programming like FORTRAN/COBOL, procedural programming like C/PASCAL, object-oriented programming like C++/JAVA, and service-oriented programming like WebService today. As a result, all kinds of heterogeneity emerge one after another everywhere, such as hardware (CPU and instruction set, hardware structure, driver), operating system (API and development environment of different operating systems), database (different storage and access formats). High-level languages rely on specific compilers and operating system API programming, which are incompatible with each other and need the support of development and running environment. Because of this heterogeneity, different software and hardware can not be interconnected on different platforms, coupled with different network protocols and communication mechanisms, systems can not be effectively integrated with each other, just like different ethnic groups communicate with each other. It is difficult to cooperate with the organization to face the challenge.

Although the languages are different, the kernels that human beings need to express are similar. By the same token, many basic functions and structures of various application systems are similar, and the services and functions they provide are similar. It would be ridiculous if every development starts from scratch, like reinventing the wheel every time a car is built.

Therefore, shielding all kinds of heterogeneity and realizing some kind of standard interoperability to achieve reuse (instead of inventing the wheel every time), through loose coupling, through abstracting the specific business, planning the whole business process through the expression of services and the atomization of business processes, this architecture is SOA.

SOA is such a paradigm for organizing and leveraging distributed systems that may be under the control of different ownership scopes.

To put it figuratively, the final service of an enterprise is like arranging for national chefs to prepare a table of top dishes, requiring Japanese sashimi and sake, French foie gras and raw oysters, German beer and elbows, Chinese stir-frying and Buddha jumping over the wall. in this case, you don't have to learn all kinds of languages to communicate with chefs, you just need to arrange the order of serving. Write down the delivery time under the photos of the dishes they have made, give it to the chef, nod to each other, click to pick up the food, and have a unified waiter standard to ensure the best user experience. Each chef has its own system behind it, and the team communicates in its own language, just like the app behind API. And the order you arrange to serve is process-driven, and the waiter picking up the food is like an API call.

In fact, printing, one of the four great inventions in ancient China, is an example of the application of SOA thought. Before printing, books needed to be copied by hand, so they were inefficient, the quality was unstable, and consistency could not be guaranteed. With printing, publishing efficiency and content consistency have been improved by an order of magnitude! The initial printing is stereotyped, which is "reuse", just as the software achieves the "reuse" effect of repetition and use in different situations through the packaging of components. However, stereotyped printing is a tight coupling, a stereotype can only print a page of a book, in which the specific "words" cannot be reused, just as the com+ components developed by Microsoft VB can only be used in the windows environment, and cannot be reused and choreographed with the EJB components developed by JAVA, because they are tightly coupled with the development environment and running environment, and must be redeveloped to be used in the UNIX environment. It is equivalent to changing the edition of a book. Then the movable type printing completely solved this problem, there is a loose coupling between the text and the layout, through typesetting to achieve the printing layout of a book. . This is another order of magnitude jump-just as we can encapsulate services, form API after API, and implement business processes through API linkage of service choreography.

Now the popular so-called micro-service, is a single movable type, through the SOA series into articles (services). At this point, schema must be mentioned. In order to do a good job of loose coupling movable type printing, each word needs to follow certain norms, such as font, character size, must follow certain patterns and contracts. Just as we can encapsulate services and form API, the sharing of services is coordinated by API pattern and schema and contract, and the business process is realized through API linkage of service orchestration.

Schema is like a fixed specification for every word in movable type printing, such as font, size, line width, etc. Without this specification, some words are big and some are small, and this is precisely the current situation in the field of micro-services: many micro-services based on XML do not have schema at all! They are just copycat SOA.

To sum up, SOA divides the complex business system into small independent systems, each system is called a service, provides a set of independent API, and then organizes the complete business through API linkage. In the early stages of the development of each business, usually one or more database tables complete the business, as most small businesses do. However, when the complexity of the business system of an enterprise expands to a certain scale, we must consider how to split each subsystem according to independent services, otherwise it will be in chaos and can not be managed at all.

This linkage, according to the requirements of the business process, can be strung together step by step, providing unlimited complexity. This is the situation within the enterprise. So, what about on the outside? Now various cloud service vendors also have numerous API, each of which can be regarded as an independent service. But if you string these independent services together, you can create new applications one by one. For example, there are three independent units, the first unit is the local health system, and his database stores the medical insurance records of someone in the place; the second unit is a hospital, and his database stores all the medical records of a person in the hospital; the third unit is an insurance company, and his database holds a person's insurance records. Originally, their systems are unrelated to each other, and through the API linkage of SOA, they can easily obtain data from the above subsystems according to certain conditions, and organize a complete new business process. For example, if someone has participated in social security and medical insurance before, and has not made more than five visits last year, and has not purchased any medical insurance from an insurance company in the first three years, then 500000 medical insurance can be provided to that person. otherwise, there will be less or reject the insurance application, and so on.

…… It can be seen that the imagination space of API linkage is infinite, but the premise is open!

Because each API is like a separate note, you can connect it a little bit and it can form a tune.

If you are a master, you can write a magnificent symphony.

If you. Enter APEMESH.

CDIF, API, SOA, cloud computing, cloud services, JSON, automated testing, automatic document generation

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report