Remove the veil of SOA

SOA Definition

The following is a definition given by the author to SOA: SOA refers to the need for business integration in the Internet environment, A software system architecture implemented by connecting independent functional entities that can complete specific tasks. In this definition, the premise I want to express is as follows:

1) Software System Architecture: SOA is neither a language nor a specific technology, but a software system architecture. It attempts to provide a recommended architecture in a specific environment, from this perspective, it is more like a pattern ). Therefore, it is complementary to many existing software technologies, such as object-oriented technology, rather than mutex. They are designed for different application scenarios to meet different requirements.

2) scope of use of SOA: The requirement determines and limits functions. SOA is not a panacea. Its main application is to solve the business integration problem between different commercial applications in the Internet environment. Next we will discuss in detail how the characteristics of the Internet determine the characteristics of SOA. Here we just need to briefly review the characteristics of the Internet environment that are different from the Intranet environment:

A) A large number of heterogeneous systems coexist. Computer Hardware works in different ways, operating systems and programming languages;

B) massive and frequent data transmission is still slow and unstable;

C) The version upgrade cannot be completed, and we cannot know which machines on the Internet directly or indirectly use a service.

Based on the above premise, let's take a look at the basic features of SOA.

Three basic features of SOA

1. independent functional entities

In a loose environment like the Internet, any access request may fail. Therefore, any structure that attempts to control over the Internet may face serious stability problems. SOA emphasizes the completely independent capabilities of functional entities that provide services in the architecture. Traditional component technologies, such. net remoting, EJB, COM, or CORBA all require a host (host or server) to store and manage these functional entities; the lifetime of these components also ends when the running of these hosts ends. In this way, other application services running on the host will be affected when the host itself or other functions are faulty.

The SOA architecture emphasizes entity self-management and recovery capabilities. Common technologies used for self-recovery, such as transaction, message queue, redundant deployment, and cluster) it plays a vital role in SOA.

2. Low-frequency access to large data volumes

For. net remoting, EJB, or XML-RPC for these traditional distributed computing models, their service is provided through the function call method, to complete a function, you must call the function many times back and forth between the client and the server. In an Intranet environment, the impact of these calls on the system's response speed and stability is negligible, however, in the Internet environment, these factors are often a key factor that determines whether the entire system can work normally. Therefore, it is recommended that the SOA system exchange information with large data volumes at one time.

3. text-based message transmission

The existence of a large number of heterogeneous systems in the Internet determines that SOA systems must adopt text-based instead of binary message transmission methods. In traditional component models such as COM and CORBA, a binary-encoded object is uploaded from the server to the client, and some functions are completed by calling the method of this object on the client; however, in the Internet environment, different languages and platforms have different definitions of data and even some basic data types, which makes it very difficult to transmit objects between different services. Because text-based messages do not contain any processing logic or data type, only text is transmitted between services, data processing relies on the acceptor to bypass the compatibility challenge.

In addition, for a service, the biggest difference between the Internet and LAN is that version management on the internet is extremely difficult, traditional software upgrades are almost impossible in this loose distributed environment. The text-based message transmission method is used. The data processing end can only process the part of the data that you understand and ignore other data to achieve ideal compatibility.

HTTP protocol: a typical SOA Implementation

Every new technology is developed on the basis of some old technologies. Just as the fundamental idea of XML comes from the early labeled language that emerged in 1960s, although SOA has only appeared in the past two years, however, the concept it expresses should be said that the distributed system structure of the network has been widely used soon. For example, the most familiar HTTP protocol is a very typical SOA architecture design. The HTTP protocol is described as follows:

1) The client usually sends a request to the server in text form through a browser to request a Web page;

2) After receiving the request, the server processes the request based on the content of the request and returns a text conforming to the HTML syntax;

3) After receiving the response text from the server, the client calls a local program, usually in a browser, to display the returned HTML text.

Next let's take a look at how HTTP meets the characteristics of SOA:

* Independent functional entities: as a web server on the server side, it will never change because of changes in the client status. It always runs very stably according to its internal logic and responds to external requests, manage your own resources and data. A good example here is how the Web server processes the cache. Many Web servers cache data more or less to improve performance, however, operations that are completely unrelated to the client, such as cache data and refresh data, are completely completed independently by the server, and are not affected by the client.

* Low-frequency access to large data volumes: For an HTTP request, the access boundary between the client and the server is very simple: a request, a response, and no other information. No matter what information the client sends in addition to text, the client simply sends a request to the Web server where it needs the web page; to generate this webpage, whether the server needs to access the database or execute servlet or other CGI programs is completely transparent to the client.

* Text-based message transmission: the most compatible system so far may be most web applications supported by HTTP, on Windows, we can use IE to view a Web page automatically generated by Perl scripts on a Linux + Apache server on the Internet. The key here is that all content is transmitted in formatted text. No matter how the Perl script is executed, you only need its output to conform to HTML specifications, it can be explained by the client browser. However, since different operating systems follow the same specifications for the same HTML interpretation, the same user interface can still be seen in different operating systems.

The above section describes the features of SOA as a software architecture. Let's take a look at the relationship between Web Service and SOA.

SOA and Web Service

Web Service is a collection of technologies that are most suitable for implementing SOA, in fact, the recent popularity of SOA is largely due to the maturity of web service standards and the popularity of applications, which provides the foundation for the wide implementation of SOA architecture. Let's take a look at how various protocols in Web service work with each other to meet the characteristics required by SOA:

* Independent functional entities: by searching the UDDI directory, We can dynamically change the provider of a service without affecting the application configuration of the client. All accesses are implemented through soap. As long as the WSDL interface is well encapsulated, the external client cannot directly access the data on the server.

* Low-frequency access to large data volumes: Using WSDL and literal-based SOAP requests, we can implement interfaces that can receive large amounts of data at one time. It is important to note that SOAP requests are divided into text and Remote Call (RPC) methods. As mentioned above, SOAP requests using remote call methods do not meet this requirement. Unfortunately, most of the existing SOAP requests still use the Remote Call (RPC) method. On some platforms, such as earlier versions of IBM WebSphere, no text soap support is provided.

* Text-based message transmission: All Web Services communicate through soap, while soap is based on XML, different versions can be identified and differentiated using different DTD or XML schema. Therefore, we only need to provide different processing for different versions to easily achieve version control goals.

Impact of SOA on Software Architecture Design

Whether your current system involves Internet-based business integration or not, the architecture recommended by SOA is of great help to improve the scalability of your system, the following are the changes that need to be made in the software architecture after SOA is introduced in the system:

* Use text-based soap calls to get rid of data-independent information such as the function parameter types in remote calls, and ensure that all soap messages pass meaningful commercial data. The data is interpreted based on the schema instead of the class definition.

* The traditional three-layer Web application may become a four-layer structure: in the traditional sense, the business logic layer will be further divided into the storage of each session) the customer logic layer of the information and the SOA layer unrelated to the State.