The concept of SOA

Service-Oriented Architecture (service-oriented Architecture,soa) is a component model that links different functional units (called services) of an application through well-defined interfaces and contracts between these services. Interfaces are defined in a neutral way, 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 unified and common way.

This characteristic of a neutral interface definition (without forcing binding to a particular implementation) is known as loose coupling between services. The benefits of a loosely coupled system 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 makes up the entire application gradually changes. Tight coupling, on the other hand, means that interfaces between different components of an application are tightly connected to their functions and structures, so they become vulnerable when some form of change is needed for some or the entire application.

The need for loosely coupled systems stems from the need for business applications to become more flexible to meet changing environments, such as frequently changing policies, business levels, business priorities, partnerships, industry status, and other business-related factors that can even affect the nature of the business. We call business as on-demand (on demand) flexibility to adapt to environmental changes and, if needed, make the necessary changes in the way that tasks are completed or executed in an on-demand business.

Although the service-oriented architecture is not a novelty, it is an alternative model of a more traditional object-oriented model, and the object-oriented model is tightly coupled and has existed for more than 20 of years. Although SOA-based systems do not exclude the use of object-oriented design to build individual services, their overall design is service-oriented. Since it takes into account the objects within 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 a common Object Request Broker Architecture (Common object requests broker Architecture,corba), which has been in use for a long time, and its definition is similar to SOA.

However, today's SOA is different because it relies on some of the newer developments that are based on the Extensible Markup Language (extensible Markup language,xml). By using XML-based languages (called Web Service Definition language,wsdl) to describe interfaces, services have moved to more dynamic and flexible interface systems, not previously CORBA The interface Description Language (Interface Definition language,idl) is comparable in the.

WEB services are not the only way to implement SOA. The CORBA described earlier is another way to have a message-oriented middleware (message-oriented middleware) system, such as IBM's MQseries. But in order to build an architectural model, what you need is not just a service description. You need to define how the entire application executes its workflow between services. In particular, you need to find the transition point between the operations of the business and the operation of the software used in the business. Therefore, SOA should be able to relate business processes to their technical processes and map the relationship between them. For example, the operation to pay a vendor is a business process, and updating your part database to include a new supply of goods is a technical process. As a result, workflows can also play an important role in the design of SOA.

In addition, dynamic business workflows can include operations between departments, and even external partners that are not controlled by you. Therefore, to improve efficiency, you need to define strategies for how the relationships between services should be learned, which often take the form of service-level contracts 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.

What can I do with a service-oriented architecture?
The need for SOA stems from the need to make business IT systems more flexible to adapt to changes in the business. By allowing strongly defined relationships and a specific implementation that is still flexible, IT systems can take advantage of the capabilities of existing systems and prepare to make changes in the future to meet the need for interaction between them.

Here is a concrete example. A clothing retail organization has 500 international chains, and they often need to change their designs to catch up with fashion trends. This may mean that you need to change not only the style and color, but even the fabric, the manufacturer, and the deliverable product. If the system between the retailer and the manufacturer is incompatible, then the replacement from one vendor to another may be a very complex software process. By leveraging the operational flexibility of the WSDL interface, each company can keep its existing systems current, rather than simply matching the WSDL interfaces and developing new service-level contracts so that it does not have to completely refactor their software systems. This is the level of business change, that is to say, they change the partners, and all business operations are basically unchanged. Here, the business interface can be changed a little, but internal operations do not need to be changed, only to be able to work with external partners.

Another form of internal change, in which retail organizations now decide to lease some of the stores in chain retailers to small shops that specialize in popular clothing, can be seen as a business model using store-in-Shop (Store-in-store). Here, while most of the company's business operations remain the same, they now need new internal software to handle such rental arrangements. While internal software systems can withstand full overhaul, they need to do so without having a big impact on the interaction with existing supplier systems. In this case, the SOA model remains intact and the internal implementation has changed. While new aspects can be added to the SOA model to incorporate the responsibilities of the new leasing arrangement, the normal retail management system continues as usual.

To continue the concept of internal change, IT managers may find that the new configuration of the software can also be used in another way, such as renting a place to paste posters for advertising purposes. Here, new business proposals are derived from the reuse of flexible SOA models in new designs. This is a new outcome from the SOA model and a new opportunity that might not have been possible in the past.

Vertical change is also possible, in which retailers are completely transformed from selling their own clothing to renting places exclusively through shop-in-store models. If the vertical change is entirely from the bottom, there will be a significant change in the structure of the SOA model, along with new systems, software, processes, and relationships that can change. In this case, the benefit of the SOA model is that it considers issues from the perspective of business operations and processes rather than from the perspective of applications and programs, which enables business management to clearly determine what needs to be added, modified, or deleted, based on the operations of the business. Software systems can then be constructed to fit the business process, rather than the other ways that are often seen on many existing software platforms.

As you can see here, change and the ability of the SOA system to adapt to change are the most important parts. For developers, such changes can occur both within the scope of their work and beyond the scope of their work, depending on whether there is a change that requires knowing how the interfaces are defined and how they interact with each other. Unlike developers, the architect's role is to cause big changes to the SOA model. This division of labor, which allows developers to focus on creating functional units as service definitions, allows architects and modelers to focus on how to properly organize these units together, which has been around for more than 10 of years, usually in the Unified Modeling Language (Universal Modeling Language, UML), and is described as a model-driven architecture (Model-driven Architecture,mda).

The concept of SOA