Microsoft's SOA in the Real World notes 03-Chapter 1
SOA
Myth and factBefore learning more about SOA, it is very important to understand some SOA-related myths. The following table lists some of the top myths and facts around SOA to help reveal these myths.
| Myth |
Fact |
| SOA is a technology. |
SOA is a design philosophy independent of any manufacturer, product, Technology, and Industry trend. No vendor can provide a complete one-stop SOA because the SOA requirements of different organizations are different. Purchasing an SOA infrastructure from a single vendor will lead to a failure in the SOA investment goal. |
| SOA requires Web Services. |
SOA can be implemented through web services, but implementing SOA does not necessarily require web services. |
| SOA is completely new and revolutionary. |
EDI, CORBA, and DCOM are conceptual examples of service-oriented (so. |
| SOA ensures the consistency between business and IT. |
SOA is not a methodology. |
| SOA reference architecture can reduce implementation risks. |
SOA is like a snowflake-no two pieces are the same. An SOA reference architecture may not provide organizations with the best solutions. |
| SOA requires comprehensive updates in technology and business processes. |
SOA should be incremental and built on current investment. |
| We need to build SOA. |
SOA is a way, not an endpoint. |
The practice of focusing on delivery solutions is not SOA. SOA is a way to deliver solutions, not the ultimate goal.
SOA
EvolutionSo is the result of the natural evolution of the current development model. In 1980s, it was an object-oriented model, and in 1990s it entered a component-based development model. Now it is a service-oriented (SO) model ). The advantages of component-based development (self-describing, encapsulation, dynamic discovery and loading) are retained for services, but the object-based Remote Call method is abandoned to transfer messages between services. A style not only describes the structure of a message, but also describes a behavior contract. It defines an acceptable message exchange mode and a policy to define the semantics of a service. This improves interoperability and provides adaptability, because messages can be transmitted from one service to another without considering how the service processes messages. Service-oriented service provides an evolutionary method for creating distributed software, which facilitates loose coupling integration and easy change. With the emergence of WS-* Web Services, and the support of mainstream development tools and the interoperation in a wide range of industries, service-oriented software development becomes feasible. Although the most common implementation uses industrial standard web services, services are independent of technologies and their architecture models and can be used to connect legacy systems. Unfortunately, the benefits of service-oriented services and SOA have become increasingly unclear due to excessive publicity and confusion around these terms. With the increasing awareness and excitement of SOA, the clear boundaries for defining services have become blurred. However, as long as they are used for the right purpose, so can indeed provide some specific benefits. The following are three important aspects related to so: 1. So is evolved. The principle of service-oriented development is based on decades of experience in developing distributed applications. So incorporates concepts such as self-describing applications, explicit encapsulation, and dynamic loading of runtime functions-these principles were initially introduced by object-oriented and component-based development in 1980s and 1990s. So changes are a metaphor for developers to get these benefits. Instead of using method calls on Object references, service-oriented conversion creates sessions through message transmission-a proven metaphor that can be applied to the integration of Scalable Distributed Software. 2. So is not a product or technology. It is a set of Architecture Principles independent of any product. Just as development concepts such as polymorphism and encapsulation are independent of technology, so is also true. In recent years, Web services have provided a lot of convenience for the development of service-oriented applications, but these applications do not necessarily need web services. 3. So is progressive. Finally, service-oriented can also be a gradual process, which can usually be completed internally. Customers should not be asked to dramatically restructure their businesses to achieve service-oriented benefits. On the contrary, customers should be able to effectively use existing IT assets. The existing technologies and skills can be used to achieve service-oriented development goals. The basic building block for the service-oriented architecture is a service. A service is a program that can interact with each other through a well-defined message exchange. The service must be designed with availability and stability. The created service needs to be maintained for a long time, and the configuration and combination of the service can be changed. Agility is often referred to as the biggest benefit of SOA-organizations that implement business processes on loosely coupled infrastructure have a higher degree of openness to changes, those that are restricted under a single application, it also takes several weeks to make the smallest changes. Loosely coupled systems lead to loosely coupled business processes, because business processes are no longer limited by infrastructure. Services and their interfaces must be stable so that they can be reconfigured or combined to meet the changed business needs. Services can maintain stability through standard interfaces and well-defined messages-for example, using soap and XML styles as message definitions. Services designed to execute simple and fine-grained functions only require limited knowledge about how messages are transmitted and restored, these services may be reused in a larger SOA infrastructure. Service-oriented services do not need to be re-installed from scratch. According to the four principles (see below), existing IT assets can be reused by encapsulating them into modular services that can be inserted into any business process of design. The purpose is as follows:
- Connect to an existing system-hierarchical business process management, collaborative workflows, and reports on existing IT assets.
- Get more value from existing systems-reuse existing applications in new ways.
- Scale and optimize existing systems-create it support for new cross-functional business processes that go beyond the functional boundaries of existing applications.
A key benefit of service-oriented architecture is loose coupling. No discussion of web services seems complete without some reference to the advantages of looser coupling of endpoints (applications) facilitated by the use of web service protocols. the principle is to use a resource only through its published services, rather than directly pointing to the implementation behind it. In this way, the changes made by the service provider to the implementation will not affect the service consumers. By maintaining a consistent interface, the service consumer can select an alternative instance (for example, replacing the service provider) of the same service class without modifying the calling program, it is also separated from the release of the new instance. When using Web Services (even if both parties prefer to use the same web service protocol), service consumers and providers do not need to use the same implementation technology, interface technology, and integration technology.
