Principles of service-oriented architecture (SOA)

Distributed computing regards distributed software resources on the network as various services. Service-oriented architecture is a good solution. However, this architecture is not a new idea. The architecture is similar to that of DCOM. However, these past service-oriented architectures have been plagued by some difficulties: first, they are tightly coupled, this means that both ends of the distributed computing connection must follow the same API constraints. For example, if the code of a COM object has been changed, the code accessing this object must also be changed accordingly. Second, these service-oriented architectures are constrained by vendors. Microsoft controls DCOM. It is not necessary to say that CORBA is just a disguised standardization effort. In fact, to implement a CORBA architecture, it is often done by a vendor to implement the specifications.
Web services is an effort to improve the disadvantages of DCOM and CORBA. The difference between the service-oriented architecture of Web services today and the past is that they are standards-based and loosely coupled. Widely accepted standards (such as XML and SOAP) provide interoperability between solutions of different vendors. Loose coupling isolates participants in distributed computing, and changes made by one party on both sides of the interaction will not affect the other. The combination of the two means that the company can implement some Web services without having to have any knowledge of the clients using these Web services. We refer to this standard, loosely coupled service-oriented architecture as SOA.
The strength and flexibility of SOA will bring great benefits to enterprises. If an organization abstracts its IT architecture and expresses its functions in the form of coarse-grained services, each of which clearly represents its business value, customers of these services (either inside the company or a business partner of the company) can obtain these services without considering the specific technologies implemented in the background. Furthermore, if customers can discover and bind available services, the IT systems behind these services can provide greater flexibility. However, to achieve a strong and flexible architecture, a new method is required, which is a daunting task. Enterprise architecture designers must be "service-oriented architecture designers", not only understanding SOA, but also understanding SOA practices. The differences between architecture practices and the final architectural results are extremely subtle and critical. This article will discuss the practice of SOA, that is, what architecture-oriented designers must do when building SOA.
Principles of SOA
To meet this business agility, SOA practices must follow the following principles:
* Service-driven services and service-driven technologies
In essence, services are in the middle of business and technology at the abstract level. Service-oriented architecture designers must understand the dynamic relationship between business needs and services that can be provided, and understand the relationship between services and underlying technologies that provide these services.
* Business Agility is a basic business requirement.
SOA considers the next abstraction layer: the ability to respond to changing needs is a new "meta requirement", rather than a fixed business requirement. From the hardware system, the entire architecture must meet the agile business needs, because any bottleneck in SOA will affect the flexibility of the entire IT environment.