Dip the veil of SOA
brief introduction
SOA is English service-oriented architecture, an abbreviation for service architecture. This vocabulary has frequently occurred in various technical journals in the last or two years. But I have always no clear answer for SOA; what is the characteristics of SOA? Suitable for solving what problems? What is the difference and connection between other technologies? What is the relationship between Web Service and SOA? What is the effect of SOA does the software architecture design? This article will try to give SOA definitions according to the author's own understanding; sum up the three basic features of the SOA; then explain these features as an example of HTTP protocol; final brief description SOA pair The software architecture design may be affected in the future.
SOA definition
The following is a definition of author to SOA: SOA refers to a software system architecture that implements a specific task independent function entity by connecting to a specific task. From this definition I hope to express the following two points:
1) Software System Architecture: SOA is not a language, nor a specific technology but a software system architecture. It tries to give an architecture recommended in a particular environment. From this perspective, it is more Like a pattern (Pattern). Therefore, it is complementary rather than mutually exclusive, such as object-oriented technology, such as object-oriented technology. They face different application scenarios, which are used to meet different specific needs.
2) The range of use of SOA: Demand decisions simultaneously restrict function. SOA is not a Baby's Wanling Dan, its most important application is to solve business integration problems between different commercial applications in the Internet environment. Below we will discuss the various features of the Internet how to determine the features of SOA. Here we only need to simply review the Internet environment to distinguish several features of the Intranet environment:
a) A large number of heterogeneous systems coexist, the computer hardware is different, the operating system is different, the programming language is also different;
b) A large number, frequent data transmission is still slow and unstable;
c) Version upgrade cannot be completed, we can't know which machines on the Internet use a service directly or indirectly.
Based on the above premise, let us take a look at the basic characteristics of SOA.
Three basic characteristics of SOA
1 independent functional entity
In the loose environment such as Internet, any access request is possible to errors, so anything that attempts to control through the Internet will face a serious stability issue. SOA is very emphasizing the complete independent ability of the functional entities that provide services in the architecture. Traditional component technology, such as .NET Remoting, EJB, COM or CORBA, there is a host (Host or Server) to store and manage these functional entities; the life of these components is also over when these hosts run. This will affect other application services running on the host when there is a problem in the host itself or other functional part.
The SOA architecture emphasizes entity self-management and recovery. Common techniques for self-recovery technologies, such as transaction, Message Queue, redundant deployment, and cluster systems, are critical in SOA.
2 big data low frequency access
For .NET Remoting, EJB, or XML-RPC these traditional distributed computing models, their service provides through function calls, and a function is often required to call back to the client and servers. Can complete it. In an intranet environment, these causations can be ignored by the response speed and stability of the system, but these factors are often a key determinant that determines whether the entire system can work properly in the Internet environment. Therefore, the SOA system is recommended to exchange information in a single way. 3 messaging based on text
Since the existence of a large number of heterogeneous systems in the Internet determines that the SOA system must adopt a text-based message transfer method. In COM, CORBA these traditional component models, from the server side to the client is a binary encoded object, perform some functions by calling this object by calling this object; but in the Internet environment, different languages, different The platform is different from the data, or even some basic data types, which gives a big difficult to pass objects between different services. Since the text-based message itself does not contain any processing logic and data types, the service is only transmitted, and the processing of data depends on the receiving end can help bypass the large mud pit of the compatibility.
In addition, for a service, the biggest difference between Internet and LAN is extremely difficult to manage version management on the Internet, and the upgrade mode of traditional software is almost unable to perform in this loose distributed environment. With text-based messaging mode, the data processing end can only select the part of the data you understand, and ignore other data, which is ideally compatible.
HTTP protocol: a typical SOA implementation
Each new technique is developed on the basis of some old technologies. As XML's fundamental thinking is like the early marker language that has emerged in the 1960s, although SOA has appeared these two years, the concept it expressed should be said that there is a wide application in the network of distributed system structures in the network. . For example, our most familiar HTTP protocol is a very typical SOA architecture design. The work process of the HTTP protocol is simple and described below:
1) Client, usually through the browser, send a request to the server side in text, request a web page;
2) After receiving this request, the server side is processed according to the request content and returns a text that conforms to the HTML syntax;
3) The client receives the server-side response text that calls the local program, which is usually the browser, showing the content returned by the HTML text.
Let's take a look at how the HTTP protocol satisfies the features of SOA:
* Separate functional entity: The web server as the server is absolutely not changed because of the change of the client, it always has a very stable operation, responding to the external request, manages its resources and data. Here a very good example is the processing of the web server to the cache. Many web servers can cache data in order to improve performance, but cache data, refresh data, which is completely unrelated to the client. The server is independently completed, which is not affected by the client.
* Big Data Quantity Low Frequency Access: For an HTTP request, the boundaries accessed between the client and the server are very simple: it is a request, a response, no other information round trip. Regardless of the information other than the text, for the client, the request is just simply telling the web page of the web page it needs; as in order to generate this web page, whether the server is required Accessing the database, performing a servlet or other CGI program, is completely transparent to the client.
* Based on the text: The best-compatibility system so far may be most of the web applications supported by the HTTP protocol, we can use IE to view the Internet with IE on a Linux Apache server under the Windows platform. Automatically generate Web page. The key here is that all content is passed in a formatted text, regardless of how the Perl script is executed, as long as its output is a web page that complies with the HTML specification, it can be interpreted by the client's browser. Since different operating systems, the same HTML is followed, so that the consistent user interface can still be seen under different operating systems. We have basically described SOA as a software architecture. Let's take a look at the relationship between Web Service and SOA.
SOA with Web Service
Web Service is the collection of some technologies that are best suited to implement SOA, in fact, the recent popularity of SOA is largely reached to the popularity and application of Web Service standards, providing a foundation for a wide range of implementation SOA architecture. Let's take a look at how the various protocols in Web Service work to meet each other to meet the features required for SOA:
* Separate functional entities: Find through the UDDI directory, we can dynamically change a service provider without affecting the application configuration of the client. All access is performed through SOAP access, as long as the WSDL interface is well packaged, the outside client is at all, there is no way to directly access the server's data.
* Low frequency access: By using WSDL and text-based SOAP requests, we can implement interfaces that can receive large amounts of data at once. Here, it is necessary to focus on the SOAP request sub-text method and remote call (RPC), as already mentioned above, SOAP requests with remote calling methods do not meet this requirements. But unfortunately, the existing SOAP requests are still remote calls (RPC) methods, on some platforms, such as IBM WebSphere's earlier versions, and even unable to provide SOAP support for text.
* Based on the text: Web Service All communication is performed by SOAP, while SOAP is based on XML, and different versions can be used to distinguish and distinguish between different DTDs or XML Schema. Therefore, we can easily implement version control targets for different versions.
SOA effect on software architecture design
Whether your current system involves Internet-based business integration, SOA recommended architecture is a great help to improve your system's scalability, the following is a change in software architecture after introducing SOA in the system:
* Using a text-based SOAP call, get rid of information-independent information such as the function parameter type that appears in remote calls, ensuring that all SOAP passes is meaningful business data. Relying on Schema, not the class definitions explain these data.
* Traditional three-layer web applications will be possible to become four-layer structure: the commercial logic layer in the conventional sense will be further divided into a client logic layer that stores each session information and a SOA layer that is not related to the status of Sateless.
Huang Qichun (from EVER2004.BLOGDRIVER.com) July 19, 2005
