The linkage between SOA and CDIF-based APIs

For more than thousands of years, Babel's story has been a central dilemma facing mankind. In order to communicate and communicate with our human beings to create language, communication and communication are still obstacles ... The communication between the same language depends on the context, but there is a huge gap between the different languages is to let people sit trapped intends.

In a highly developed civilization, artificial intelligence has been within reach of today, programmers are facing such a dilemma. Our ancestors based on the technical conditions at that time, based on the business needs at that time, mapped gradually developed fortran/cobol such imperative program design,c/pascal Such procedural programming, to C++/java such object-oriented programming , and then to today webservice such service-oriented programming. As a result, heterogeneous heterogeneity is ubiquitous, hardware (CPU and instruction sets, hardware architecture, drivers), operating systems ( APIs and development environments for different operating systems), databases (different storage and access formats), High-level languages rely on specific compiler and operating system API programming, which are incompatible with each other and require the support of development and running environments. Such heterogeneity makes a variety of different hardware and software in different platforms can not be interconnected, coupled with network protocols and communication mechanisms, the system can not effectively integrate with each other, as the different ethnic groups communicate with each other. It is difficult to collaborate with organizations to meet challenges.

Although the language is different, the kernel that humans need to express is similar, and similarly, many of the underlying functions and structures of various application systems are similar, and the services and functions they provide are similar. If every development starts from scratch, it is almost ridiculous to reinvent the wheel every time a car is built.

Thus, shielding heterogeneous, achieve a standard interoperability, to achieve reuse (instead of inventing the wheel every time), through loose coupling, through the specific business abstraction, through the service of the expression and the atomization of the business process to plan the entire business process, the architecture is SOA.

SOA is a paradigm that organizes and leverages distributed systems that may be under different ownership controls.

To make an image of the metaphor, a business of the end of the service is like to arrange for national chefs to prepare a table of top dishes, the need for Japanese sashimi, sake, French foie gras, raw oysters, German beer, elbow, Chinese stir-fry, Buddha jumps over, in this case, you do not have to learn a variety of languages and chefs exchange, Only need to arrange the order of the dishes themselves, in their production of good food photos under the delivery time, to the chef, nod each other to confirm, by point to pick dishes , there is a uniform waiter standard serving , to ensure the best user experience. Behind each chef is a system that communicates within the team in its own language, just like the app behind the API. The order you arrange is the process-driven , and the waiter takes the dish as if it were an API call.

In fact, the printing of the four major inventions in ancient China is soa thought application model. Before printing, books need to be copied manually, so they are inefficient, quality is unstable, and there is no guarantee of consistency. With typography, publishing efficiency and content consistency are increasing in order of magnitude! The initial printing is rigid, which is the "reuse", as the software through the package of components to achieve duplication and use in different situations "reuse" effect. However, rigid printing is a tight coupling, a rigid can only print a certain page of a book, where the specific "word" can not be reused, just as the software technology in Microsoft vb developed com+ components can only be in the Span lang= "en-US" >windows environment, cannot be reused and orchestrated with >java ejb because they are tightly coupled with the development environment and the operating environment , to be used in unix environment, must be re-developed, the equivalent of changing books will have to change the version. Then the movable type completely solves this problem, the text and the layout is loosely coupling, through the typesetting to realize a book's printing layout api, through the service orchestration api linkage to achieve business processes.

Now the popular so-called MicroServices, is a single movable, through the series of SOA into the article (service). In this case, the schema must be mentioned . Loose coupling of movable type to want to do well, each word between the need to follow certain norms, such as font, character size, must follow a certain pattern and contract. As we can encapsulate services to form a API, the sharing of services is coordinated through API patterns and contracts (schema and contract) to implement business processes through service Orchestration API linkage.

Schema is like a movable type in every word, should have fixed norms, such as font, size, line width and so on, there is no such specification, some words big, some words small, printed out of a mess, and this is precisely the current micro-service domain status: XML-based many micro-services have no schema! They are just cottage SOA.

In summary,SOA is to divide the complex business system into a small block of independent systems, each system is called a service, external to provide a set of independent APIs, and then through the API linkage to organize the complete business. In the early days of each business, usually one or several database tables completed the business, as most small businesses do. But when the complexity of the business system expands to a certain scale, it must consider how to separate each subsystem according to each other's independent service, otherwise it will mess hemp, it can not be managed at all.

This linkage, in accordance with the requirements of business processes can be a step-by-step, providing unlimited complexity. This is the case within the enterprise. Well, what about the outside? Now various cloud service vendors also have countless APIs, each of which can be viewed as a standalone service. But if these separate services are strung together, it can create a whole new set of applications. For example: There are three independent units, the first unit is the local health system, his database is a person's health insurance records, the second unit is a hospital, his database is a person in the hospital to keep all the records of visits; The third unit is the insurance company, His database holds a record of a person's insurance. Originally their system is irrelevant, through the SOA API linkage, it is convenient to according to certain conditions from the above several subsystems to obtain the data separately, organized a complete new business process. For example, if a person has been in a social insurance policy before, and no more than 5 visits last year , and no medical insurance has been purchased in the insurance company for the first three years, then the person can be provided with 500,000 health insurance, or less or refused to apply for insurance, and so on.

...... Visible,API linkage Imagination Space is unlimited, but the premise is open!

Because each API is like a single note, you can make a tune by linking it a little bit.

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

If you...... Enter Cdif ...

The linkage between SOA and CDIF-based APIs