With IBM, Microsoft's world-class large manufacturers, SOA (Service Oriented Architecture) has become one of the core concepts in enterprise applications. One of my students in IBM as a SOA architecture, and I also chatted with him in the first two days. From the attitude of their IBM, SOA is nothing more than the concept of a Profitable enabled after the EJB era. Nowadays, software vendors have become more and more difficult. Many vendors want to transform to the service, becoming the so-called IT Service Provider. This is a service oriented in a commercial architecture, and the technical SOA seems to have some of the relationships. IBM strongly hopes to increase the service concept in SOA to Business Layer, I hope to provide one-stop packaging service at hierarchy beyond BPM (Business Process Management). But it is clear that this service is not a SOA's propaganda, there are some sneak exchange concepts. Pack all the reasons for users to pay by MDA (Model Driven Architecture), packaged into a separate concept of Package is really a viable business strategy, but only relative to user fragile technical understanding, This SOA is really unbearable. The SOA that most users can understand is just synonymous with Integration, which is not distinguished from EAI (Enterprise Application Integration). At present, the popularity of Java technology has made the differences in various manufacturers have become very small. IBM these giant manufacturers advocate their advantages in heterogeneous system integration. Of course, it is difficult to add some materials in this process. Although there is too much business factor in this concept, it is not a simple fantasy. From the technical point of view, SOA has a key feature: 1. Standalone. The so-called service, it is different from the component of the component, first in the service is operated independently of the caller. Accessing Service interface is relatively narrow, we only need to know how service meets our functional needs without having to manage its life cycle, and do not need to keep the details that maintain the Service Run. Details. That is, we need to be limited to the functional interface for the service interface. If it doesn't matter, it is necessary to set it. Various services interacts at this level of function interface, and the entire picture is simplified. One of the most common examples is the database server, the calling program only knows how to access data accesses through the SQL language, and there is a database administrator to deal with various configuration management issues. As a result, this can be seen as an extension of the Singleton mode. In fact, the Bean managed by the Spring container can be considered to be a caller independent of the bean, so the container such as Spring can be a natural access point of the SOA architecture. 2. Asynchronous. Intrinsic asynchronous properties are the key to SOA tolerant real business intelligence. Imagine that we need to evaluate the user's credit, it corresponds to the function EvaluateCustomercredit (Customer). In the simplest case, we only need to perform arithmetic operations directly according to some of the user. If the assessment rules are very complicated, we may give up hard coding, and introduce this artificial intelligence of rule engines. In more complex situations, we may not be able to abstract the rules expressed in mathematical ways, but must rely on business personnel's manual processing (true intelligence). At this point, the system may need to pop up a page, waiting for the business to make judgments, and the approval process is required to determine the final assessment for user credit.
For computer systems, these are long processes, which are unable to accommodate synchronous calls. Also a function call, only asynchronous features can be included in the minimum business intelligence to introduce the most complex processing process in the smallest program structure unit of the function. Now SOA promotion is often concentrated on mutual calls between machines, emphasizing a inclusiveness between heterogeneous systems, but in fact, the content that can be carried by the asynchronous feature is far more than the machine world itself. Of course, synchronous call mode is also a natural component of the SOA architecture, just like Email, you need to do it. 3. Based on the message (Message Based). Messaging-based call mode is an intrinsic requirement of distributed systems. The message is a data, it is not a remote object pointer. Distributed Object This proxy-StUB-based program has an intrinsic request is a remote state synchronization (state consistency), and the distributed system is constructed of many independent state space (process space), this intrinsic uncoordinated It is a key reason that is difficult to achieve scalability in distributed object schemes. The difference between SOA and EBI (EVENT-based Integration) is primarily that EBI is often a PUSH mode, and the message source will be sent to the registered message consumer push message, while SOA is often a call of PULL. These two ways have a thousand autumn, in the case of large Scale, the scalability of the PULL mode is better. But two modes are essential in enterprise applications, and these concepts will be fused soon. 4. Plain text protocol metadata (Plaintext Meta). The SOA architecture is a very critical technique based on a plain text protocol. When needed to span many hardware platforms and software systems, various binary RPC programs always have problems that are difficult to completely solve. With the structure transparency of plain text, the self-description characteristics of metadata, we want to achieve a semantic transparency such that all intermediate layers can be passed through a general manner, and understand the part thereof. Unlike the traditional mode in OOP (Object Oriented Programming), the SOA architecture emphasizes the separation of structures and content, not the coupling and encapsulation of data and behavior. On the surface, it looks in SOA. The call mode seems to be the regression of Procedure, but in fact it is deeply different. After binding to metadata, the message (information) transmitted between the system is not completely passive, but has some SMART characteristic. When the data can be incorporated with more changes, the structure of the process can be simplified. In fact, in the SOA architecture, we recommend a Uniform Interface, which is only through a common interface, and information can pass through a relatively low price spatial boundary. Based on universal interface, we resembled the simplicity of the world, while Pipe-And-Filter has a new space in the UNIX system. Speaking of the meta-language of plain text, XML is undoubtedly the most powerful candidate of this concept. As a semi-structured text, XML is naturally a channel shared by human machine. However, as the application is in-depth, when more and more XML design become incompetent, we also feel some traces of XML abuse. The W3C's Web Service protocol stack provides a very critical idea and has been a long time as a standardized implementation, but its achievement and the cumbersome and lengthy gradually caused the developer's dissatisfaction. Although SOAP is known as SIMPLE Object Access Protocol, it is difficult to put it and Simple this word.
Perhaps the future of the Web Service is like EJB, which is gradually replaced by a plan for more Pragman. In the SOA architecture, loose couple is an effect as achieved after a combination of Late Binding (Discovery), Standalone, and Message Based, which is a good pavement for external flexible processes. Http://www.xml.com/pub/a/ws/2003/09/30/soa.htmlhttp://canonical.blogdriver.com/canonical/809426.html
