The past and future generations of soa bpel esb: -- Author: Lu Jianwei

Past and future generations of SOA BPEL ESB

I am not selling middleware, so I do not have to advocate the concept and principle of SOA.
I am not preparing to write an SOA book, so I don't have to chew on it when I write my blog.

This article involves SOA, SCA, SDO, workflow, BPEL, ESB, message middleware, WebService, EAI, analysis and design methods, object-oriented, and many components-oriented technologies, you will still confuse SOA = WebService = EAI. BPEL = workflow. ESB = message-oriented middleware. But these obfuscation is all wrong. You need to understand their differences in the following reading. If you don't have the patience to understand the differences and future of these technologies, you can read the last section, which is a summary. You can directly understand the correct results without understanding the process. But it may cause you to only know what is correct, but you do not understand why it is correct. If you want this kind of result, it's up to you.

SOA is hard because companies that lead the influence of SOA and market products have put a lot of things into SOA to get a package of solutions.
This solution ranges from the solution planning consulting method of the SOA project to the project management method (such as RUP, project role responsibility Process Evaluation) to the business description method (such as UML) to middleware to industry standards (such as WebService, soap, SCA, SDO) to System Integration diagnostics to system integration interface design (such as how to design service-oriented interfaces) business Process Integration to System Integration (such as BPEL) is often involved by industry workflows and basic business platforms. As a foreign project involves system integration, it involves legacy systems. What kinds of systems such as CORBA, COBOL, PL, sap, and Java are even more confusing for domestic programmers.

Not only are terms, technical standards, and product names in many fields confusing domestic programmers, but it technology has been developing for a short period of time, and there are not many legacy systems. In addition, most domestic programmers are still young, it is not clear about the past technological developments and the generation and application history of legacy systems. So the various factors are combined, so that programmers are discouraged. CIOs of enterprises are not clear about how to use these products. They must be very expensive and have a long implementation cycle, I have heard that the industry advocates that SOA is conducive to system integration and SOA, so that your IT and business can be flexibly on demand, however, the industry has never come up with easy-to-understand and convincing cases to illustrate how to flexibly respond to demands and integrate systems. As a result, CIOs are even more confused.

I think of Liu Ren's speech at the 2008csdn Technology Conference: Tell the truth without telling a lie; tell the truth without reason, and tell the story.

I will share with you what I have experienced.

Last year, I was engaged in a large and medium-sized project with a project cycle of six months. Of course, there are still two old acquaintances, IBM and SAP, who often struggle and work together.

A project is a national system integration of large state-owned enterprises. software from c/s to B/S must be integrated in a data center and accessible in a network portal, A dedicated analysis room also uses data center data for business intelligence analysis.

Of course, WebService, XML, message-oriented middleware, bepl, and ESB are indispensable.

In the past, the integration of Lan C/S management software systems was usually through mutual reading of their databases. However, this is not the case in formal projects. Why. Because you need to define a special database user to read and modify the fields of a table, it is not difficult to prevent. You do not know which system is responsible for disrupting the data. If you only integrate data exchange between two systems and read and write data from several fields in a few tables, you think there is nothing left to do with it, if all seven or eight systems need to be integrated, read and written to each other, and deeply associated, the world will be messy. You may often lament how CIOs have no eyes and have used different products of different companies. Now, it is. In fact, it cannot be said that many times the launch of a project is influenced by the time, location, people, and various factors, that is, the current situation you see. If you are a CIO, it is estimated that your current situation is not much better over the years. This is how enterprises develop. Although you may complain about the company's management and strategy and the boss's decisions when you are at a party, you may not be better than your boss. This is the case. The status quo has been formed, and history cannot go backwards. However, we still need to move forward in the future. This is not the case for enterprises. Enterprises keep moving forward in constant dilemmas and restrictions, depending on who can grasp the balance and resource scheduling, and insist on making good decisions.

In the past, I met a project that integrated the LAN c/s management software system. Someone wrote a DLL. Unfortunately, the DLL is written by the damn Pb. We will give them the DLL written by Delphi. We all know that Pb is a pseudo-compiled code, and the code is in the script form, while Delphi is binary and structured OO programming form. Therefore, the data memory representation and format do not match the data type. It cannot be changed to a string. Because of Delphi's string, it is actually pointer-type. It is hard to solve the problem of data type and the performance of batch data transmission. A dll function, I want to pass a database record to the other party, how to spell this string. At that time, I wanted to define N parameters. Finally, because the fields required by the other party were constantly changing, and the last interface was changed, the N parameter schemes were deprecated and changed to a record. Each field of the record is separated by special characters, and then spelled together to form a general string, and the other side is split for processing. This is still so troublesome for a record. If n pieces of data are modified by a dataset, n interface functions must be called, which is too slow to process. In addition, there are also obstacles to data transactions between the two parties. In addition, as we constantly change the interface to upgrade the DLL, The dll version black hole also makes us complain.

This is integration. This is not a battle between the two sides due to inconsistent interests. It delays the interface, provides error information and interfaces, and provides limited information. So that the Project Integration cycle is abnormal for a long time, the middle is filled with variables. As a result, enterprise CIOs have a headache when talking about system integration.

Therefore, WebService, XML, message-oriented middleware, bepl, and ESB were on the stage.

Let's also stop defining N parameters, and do not spell strings, nor do the DLL hard-coded and bound to each other, and do not bother to process data transactions.

XML is used to batch transmit data to us. The data is formatted. The API is also a pb dll. I am a Delphi DLL. We are all uniform data types and interface calling methods, and they are all WebServices. Let's stop binding them, and send them to the ESB. Let the ESB handle transactions and message data routing. We should not hard-code each other. bepl's XML format describes the business interface to call the integrated orchestration language for help, so that the ESB engine can drive the execution of bepl.

ESB is a bit like message-oriented middleware, used for secure routing of message data and transactions. ESB is also a bit like component middleware. It provides component registration, component security, component version, and Component Deployment functions (I suspect many functions are provided after the component server function is enhanced, instead of what the ESB provides ). However, the most unique feature of ESB is that it provides the monitoring and management of the parsing and execution of BPEL. The BPEL designer provides the orchestration of BPEL, while the ESB provides the execution of scripts.

Integration saves a lot of trouble.

But have you noticed one thing? I did not mention SOA in this integration. It's really strange that there is no such word as SOA in the case. So How can international giants advocate their SOA through such integration projects. Does webservvice + ESB + BPEL mean SOA? Then, isn't the system integration and EAI we used to implement soa n years ago? Haha.

It seems that this is not SOA. We need to analyze SOA from another perspective.

SOA, full Chinese writing is a service-oriented architecture. The definition of this name makes us very familiar.

Service-oriented ??? We have heard of component-oriented, object-oriented, and function-oriented. Is it related to these sources?

Architecture? We have heard of the architecture of EJB, COM +, and CORBA. Is it similar to these architectures?

Service-Oriented Architecture (SOA) is a component model that describes different functional units (called services) of an application) use the well-defined interfaces and contracts between these services.

Interfaces are defined in a neutral way. They should be independent of the hardware platform, operating system, and programming language that implements services. This allows services built in various such systems to interact in a unified and universal manner.

This is a complete definition:
1 is a component model
2. Different functional units are called services.
3. Services are linked through interfaces and conventions.
4. The interface is neutral.

This definition is very false.

(?? This is exactly what I said when I learned com many years ago?

I found an article on another website that says:

The main differences between SCA service components and traditional components are:

1. service components are often coarse-grained, while traditional components are mostly fine-grained. (No. In the past, we used to do Com and also had process set components, which were coarse-grained)

2. the interfaces of service components are standard, mainly WSDL interfaces, and traditional components often appear in the form of specific APIs. (No, it's just that the interface implementation technology is different. Is there such a difference ?)

3. The implementation of service components has nothing to do with the language, while traditional components are often bound to a specific language. (No, many languages can implement COM)

4. Service components can provide QoS services through component containers, while traditional components are directly controlled by program code. (No, traditional components are also provided by component containers)

)

Although it has been repeatedly claimed that WebService (XML/soap/UDDI/WSDL) is not the only interface-neutral descriptive method of SOA. But in fact, WebService is now the most mature and most systematic method to obtain the neutral description of interfaces supported by industry vendors. Therefore, no matter what industry vendors say, WebService is not the only method, but it is already default. The rumor of the vendor is that some legacy systems do not have the ability to transform WebService, and WebService is not supported. If this rumor is left blank, the list will be lost. Many foreign systems are reluctant to throw their teeth. Therefore, foreign countries envy China very much. First-hand technology and standards are the most advanced. There is no historical burden, no detours, and integration of costs and risks and cycles will be much better.

SOA is a component model. We know that both COM + and EJB are component models. Components include attributes, methods, and events. The component runs in the component container. The component container ensures that components are created, concurrently, pooled, logged, and destroyed.

Components are originated from objects. Let's take a look at the component models implemented in various languages. The implementations are all application object models. The object has data and methods and no events. Data has no read/write restrictions. This is a very obvious difference between components and objects.

We used to program functions. At the same time, we wrote too much program code without a function in the flow of water. (now I think it's naive. It's just a mess, but now I can still see this type of code During code review. Its tracking and error correction, quality assurance, change reduction and expansion, reading comprehension are not consistent, and how can it be commercialized ).

However, functions cannot express the relationship between functions. You have to put it in different source code files to represent a logical cluster. However, this representation method is very bad. The data and methods are still not separated, and the visibility level is not blocked. Therefore, we must move toward object-oriented. In fact, we do not analyze the business, map the business to an object as the industry theory does, and then design the object. At the beginning, inheritance and polymorphism were not considered to solve the problem of code visibility. There are no very professional design objects to analyze. But it is really something that people gather together in groups and form things. When we really understand the OO theory and look back at our code, it is really in line with the OO theory. I am amazed at the fact that many programmers who have not been familiar with this technology have forced themselves to write oo code for OO and OO theories, and finally the surface form of OO, but the idea is a huge flow of water, I cannot even read the function process, and I have a lot of different ideas. We recommend that you use the Function Orientation first, and then naturally transition to the object orientation.

Object-oriented problems cannot be solved. There is no event or attribute. Therefore, it is generated for components. However, the source code, attributes, and events are carefully analyzed through the object-oriented method. For example, an attribute is usually composed of getxxx and setxxx. An event is a special attribute.

Everything is undertaken. Naturally, the transition is from process-oriented to object-oriented and then component-oriented.

For components, we encountered another problem. These problems are caused by our natural understanding of habits.

Many people analyze the business. No matter whether you use UML or the organization structure-process-assessment method, you must always have a hard ing during software design. It is to map the reality into a class, And to film it into a component. However, this ing is not in line with the habit of thinking naturally. You need to change one idea, and the two ideas of analysis and design are always screwed together.

We don't want to unscrew it any more. We just want to put it bluntly: I want to finish this thing. Now that I have so much information, I enter it and you will output the computing results I need. OK, that's simple. I don't want to map any more classes or components.

This is a natural habit of human thinking. Our industry's predecessors and old experts go around and research and published N-plus theories and methods. However, in the end, we still have the scientific and rational analysis habits that let us go with nature. Again. However, this regression has been sublimated, and we will no longer implement it with simple interfaces. Under our service interface, we are free to apply the development implementation methods we are good. We no longer need to talk about class ing with customers, and customers no longer need to talk about business processes with us. If we are unified, we want to do this: I want to finish this task. Now that I have so much information, I enter it and you will output the computing results I need. OK, that's simple.

It is impossible for customers to learn UML. In the past, it was just a theoretical ideal for us and our customers to unify the process management and UML transaction description methods of RUP.

SOA is not as simple as upgrading from component-oriented to service-oriented. It is a revolution in our software analysis methods, software design methods, and software development methods. It is the industry's reflection on these theories and products in the past. The industry's abstract approach to the world has changed.

SOA needs to associate different functional units (called services) of applications with well-defined interfaces and contracts between these services. But how can this problem be solved. High Cohesion and low coupling are our consistent principles. Like in the past, the DLL method we used to open to each other is not suitable at all. It is hard-coded into our own system. Once the interface changes, it must be modified. Fortunately, the industry has found a workflow that can drive business processes. So, the heart rushed with joy.

It is only necessary to find that it is not correct. The world of workflow specifications has long been fixed. When a workflow is generated, there is no SoA yet. The business process connection required by SOA is similar to the workflow principle, but it is not the most suitable connection for software services. As a result, the industry has joined forces to develop the business process processing language (BPEL. However, some workflow manufacturers are also afraid of being behind the times, so they say they are already SOA. As a result, Li Qiang and Li Qiang in the industry have a bunch. Each has its own interests and each singing tone.

The world view of SOA also needs to be implemented into an achievable framework. So SCA and SDO appeared. SCA is the framework specification for implementing SOA, while SDO is the data structure specification and data access principle specification. These specifications can be implemented using existing development languages and technical frameworks. Therefore, for existing systems, there is no need to think that the existing system is lagging behind and does not conform to SOA. Therefore, a new set of SOA software is required.

However, I roughly read the SCA specification, especially similar to the component model system I used to be familiar. SCA provides service definition and service wire based on the component model. The component model provides individual specifications, while SCA not only provides individuals, but also provides individual connection specifications. The component model familiarized me with the separation of interfaces and implementations, familiarized me with container runtime protection, and familiarized me with metadata management. People who have not passed the component-oriented era will not feel the necessity of SOA.

We used component models to develop application software. The purpose is to imagine that these components are independent individuals. Then we used a script to put these components together (in the past, I thought of a VBA script, then there is a Javascript script, followed by an ASP script, followed by a focus on the workflow, all of which are not satisfied, and finally the bepl is visible ). Today, SCA, SDO, bepl, and ESB provide a feasible system model for our years of vision. We need such a flexible combination of application software. We do not need an aircraft carrier software with thousands of parameter configurations (such as sap r/3 ).

Only by understanding the past and future generations of SOA, BPEL, and ESB can we look at these technologies in a peaceful manner and those related to them, so that we can learn and use them in a targeted manner, it is helpful for us to quickly adapt to changes in customer needs.

Last sentence:

For my personal experience, I have experienced product development history based on three architectures: process-oriented, object-oriented, and component-oriented. We have been trying to solve the problem of flexible combination of software components, I have been studying technology to solve problems, rather than learning to catch up with the trend. I personally think that the architecture of SOA is an extension of the component-oriented idea of our past applications. Then we put the WebService shell on. We used to develop COM +, in order to make cross-firewall effort to connect to CORBA in a heterogeneous manner. SOA also integrates the flexible business-based BPEL idea and the Technical Idea of middleware message bus WebService governance. SOA integrates so many architectural ideas and enterprise product technologies, the fundamental goal is to make our it more flexible. In the past, components were designed for this fundamental goal. SOA achieves it flexibility through business-oriented analysis methods + WebService neutral technology + BPEL script business orchestration + ESB service governance bus middleware.

SOA is service-oriented, and OO is object-oriented. That's simple, a problem field. SOA is neither an EAI nor a method of system integration. It is the propaganda of some companies in the industry to achieve their own interests, confusing everyone's audio and video. No one mentioned how to learn to integrate these systems. When it comes to service-oriented, it involves system integration? Fooled? In the past, I used enterprise integration to read databases, then DLL, and then WebService, but did not use SOA.

In the past, business design used one way of thinking. Software design used another way of thinking. SOA was the same. The problem must be viewed from the business perspective, but not from the process side, but from the class diagram and sequence diagram.

Here is an example.

There is a business where users select their desired models on the website, and click the calculation to show the total cost of purchasing the car.

This function is a software service. SAAS, software as a service.

The business designer designs the business. The functional designer defines a software service interface, which may be calctotalworkflow (cartype: XML ).

The data entered by the user is processed by the programmer program into SDO input, the service interface is called, and the total cost is returned. But how is the interface computed? What OO technology or component technology is used, or the Code of a large stream account is your programmer's own business. Business designers and functional designers have a unified understanding.

This is the relationship between business design, functional design, and functional development.

With SCA and SDO, the concept of SOA is much more practical, otherwise it is easy to confuse with the previous components and the WebService SOA advocated by Microsoft.

Summary:

SCA is the Implementation specification of SOA, otherwise SOA is a concept.
BPEL is used to orchestrate and connect various services. It is not used for workflow review and approval. There are two purposes at all. Do not confuse them. It is an incorrect idea to implement a workflow using BPEL or a workflow to implement it.
An ESB runs a service and drives it.
SDO is designed to standardize the format of data transmitted between interfaces and data operation rules. Otherwise, the XML you transmit will be compiled by yourself.
SCA and SDO are developed by the osoa organization.

However, Microsoft also advocates its own SOA, but there is no specific theory (Microsoft never claims its own theory, although Microsoft has made many patents and papers ), microsoft has specific WCF and Microsoft's WebService implementation models as the comparison of SCA, as well as LINQ and ADO. net as a comparison of SDO.
Because Microsoft's SOA service components do not comply with the SCA/SDO specifications, it is easy to integrate with the IBM camp in Microsoft's system. Because we often use Visual Studio Tools to develop WebService, The automatically generated framework does not comply with the SCA/SDO standard.

If you want me to describe what I use and who is equal to who I use SOA. I can only use SOA = WebService + SCA + SDO + bepl + ESB for brute force expression. If you think that SCA + SDO is only a standard set by IBM, sun, Bea, and not an SOA standard in the industry, if you think bepl belongs to the category of business process reorganization rather than the SOA model, you can attach people to SOA = WebService. This recognition is similar to removing windows, office, Visual Studio, and sqlserver from Microsoft. Such Microsoft is still a Microsoft Company. But is it true that it is still Microsoft? Just like a full concept of human beings, you have to turn people into heads + hands + feet +... it is equivalent to a person. This rough and simple definition and understanding is obviously incorrect.