Microsoft's SOA in the Real World notes 04-Chapter 1
Why follow
SOA?Service-Oriented Architecture is crucial to some stakeholders:
- For developers and solution architects, service-oriented is a way to create dynamic and collaborative applications. By providing the ability to select a service function provider during runtime, the service-oriented service allows applications to handle content, context of specific processes, and perfectly merge new service providers at any time.
- For IT managers, service-oriented provides an effective way to integrate data from different enterprises. By providing a model that integrates information and business logic in multiple systems into a single interface, service-oriented systems allow different and redundant systems to be released through a unified and continuous set of interfaces.
- For CIOs, service-oriented provides a method that includes existing IT investment without the need to deploy new applications. By encapsulating business applications into functional-based interfaces, the service model provides controlled access to key applications, and provides opportunities to continuously improve the implementation of those interfaces. The service-oriented architecture can protect investment from the changing flow.
- For business analysis experts, service-oriented is a way to better combine information technology investment and business strategies. By ing employees, external function providers, and automated systems to a single model, analysis experts can better understand the investment trade-offs between personnel, systems, and resources.
- For Microsoft, service-oriented is a prerequisite for creating applications that fully utilize the network. Such applications connect executors and systems to facilitate business processes.
The architecture concepts related to SOA make loose coupling possible. Loose coupling is the basic principle behind SOA, which enables us to summarize the benefits of SOA into one word: agility. The traditional application architecture evolved from a host application to a client server architecture, and then to a multi-layer Web application, the application still maintains a large degree of tight coupling. In other words, every subsystem that makes up a larger system not only needs to understand its peripheral subsystems logically, in addition, it is physically bound to those subsystems at both compilation and runtime. Replacing the key part of the system functionality to respond to changes in the business model or deploying an application as an independent business country is simple, but impossible. In a service-oriented architecture, application functions are provided through a set of services. These services are independent of each other and encapsulate the business logic and related data. A service interacts with each other through a message. A message includes a service format style, a contract defining the exchanged content, and a policy on how to exchange the content. During the lifetime of an Application Service, you cannot control who and where to use these services. This is one of the key differences between SOA and traditional application architectures. Traditional applications are designed to interact with people. Application manufacturers provide user interfaces and backend business components and data storage. Because the good engineering principles have well separated the business components and user interfaces, the only user of business logic is the user interface that is delivered with the entire application. These user interfaces and business components are delivered and managed by a single entity. In service orientation, the service functions exposed by the service can be used by users outside the application system. These users may be other services (encapsulated business processes), or other types of user interfaces provided by the application itself. Therefore, the contracts of these services must remain unchanged once released, because there is no way to know who is using them or when they are being used. In addition to providing services and using their own services, applications themselves also have the flexibility to adopt new services after deployment. The availability and stability of these services have thus become a key factor.
