Service-Oriented Architecture

A service-oriented architecture (service-oriented Architecture,soa) is a component model that links the different functional units of an application, called services, through well-defined interfaces and contracts between these services. Interfaces are defined in a neutral manner and should be independent of the hardware platform, operating system, and programming language that implements the service. This allows services built on a variety of such systems to interact in a uniform and common way.

The characteristics of this neutral interface definition (not enforced to a particular implementation) are called loose coupling between services. The benefits of loosely coupled systems are two points, one is its flexibility, and the other is that it can continue to exist when the internal structure and implementation of each service that comprise the entire application change gradually. Tight coupling, on the other hand, means that the interfaces between the different components of the application are tightly connected to their functions and structures, so they are vulnerable when some form of change is required for some or the entire application.

The need for loosely coupled systems stems from the need for business applications to become more flexible based on the needs of the business, to adapt to changing environments, such as frequently changing policies, business levels, business priorities, partnerships, industry status, and other business-related factors, these factors can even affect the nature of the business. We call business that is flexible to adapt to environmental change as on-demand (on demand) business, in an on-demand business, as soon as needed, you can make the necessary changes to the way you complete or perform the task.

Although a service-oriented architecture is not a novelty, it is an alternative model for more traditional object-oriented models, and the object-oriented model is tightly coupled and has existed for more than 20 of years. Although an soa-based system does not rule out the use of object-oriented design to build a single service, its overall design is service-oriented. Because it takes into account the objects in the system, SOA is object-based, but as a whole it is not object-oriented. The difference is in the interface itself. A typical example of an SOA system prototype is the generic Object Request Broker Architecture (Common object requests broker Architecture,corba), which has been in use for a long time, with a defined concept similar to that of SOA.

However, today's SOA is different because it relies on some update progress, based on Extensible Markup Language (extensible Markup language,xml). By using an xml-based language called the Web Service Description Language (Web Services Definition language,wsdl) to describe the interface, the service has been moved to a more dynamic and flexible interface system than the previous CORBA The interface Description Language (Interface Definition language,idl) in is comparable.

WEB services are not the only way to implement SOA. The previous CORBA is another way to have a message-oriented middleware (message-oriented middleware) system, such as IBM's MQseries. But to build the architecture model, you need more than just a service description. You need to define how the entire application executes its workflows between services. In particular, you need to find the transition point between the operation of the business and the operation of the software used in the business. Therefore, SOA should be able to associate business processes with their technical processes and map the relationship between the two. For example, payment to a vendor is a business process, and updating your part database to include new supplies is a technical process. Thus, workflows can also play an important role in the design of SOA.

In addition, dynamic business workflows can include not only operations between departments, but also operations with external partners that are not controlled by you. Therefore, in order to be more efficient, you need to define a strategy for how to know the relationship between services, which often takes the form of service-level agreements and operational policies.

Finally, all of this must be in a trusting and reliable environment, to execute the process in accordance with the agreed terms as expected. Therefore, security, trust, and reliable messaging should play an important role in any SOA.