Basic concepts and design principles of SOA

　SOA is the abbreviation for the English word "service oriented Architecture", in which there are many translations, such as "service-oriented Architecture", "service-centric architecture" and "service-oriented Architecture", where "service-oriented architecture" is more common. SOA has many definitions, but basically it can be divided into two categories: one is that SOA is primarily an architectural style, and the other is that SOA is a new set of distributed software system construction methods and environments, including running environment, programming model, architectural style and related methodology, Covers the entire lifecycle of services: modeling-development-consolidation-deployment-run-management. The latter summarizes the scope of the larger, focusing on the future development, we are more inclined to the latter, we think that SOA is a distributed software system construction methods and environment of the new stage of development.

　　1. Basic concepts of SOA

In the SOA architecture style, the service is the core abstraction, and the business is partitioned (modular) into a series of coarse-grained business services and business processes. Business services are relatively independent, self-contained, reusable, implemented by one or more distributed systems, and business processes are assembled from services. A "service" defines an interface that is related to business functions or business data, as well as contracts that constrain this interface, such as quality of service requirements, business rules, security requirements, compliance with laws and regulations, KPIs (key performance Indicator,kpi), and so on. Interfaces and contracts are defined in a neutral, standards-based manner, independent of the hardware platform, operating system, and programming language that implements the service. This allows services built on different systems to interact and understand each other in a unified and common way. In addition to this neutral feature that does not rely on specific technologies, the ability to support dynamic query, location, routing, and Mediation (mediation) through the Service Registry (Registry) plus the Enterprise service Bus, The interaction between the services is dynamic and the location is transparent. Technology and location transparency, which makes it highly decoupled between the requester and provider of the service. The benefits of this loosely coupled system are two points: one is that it adapts to the flexibility of change, and the other is that when the internal structure and implementation of a service change gradually, no other services are affected. Tight coupling means that the interface between the different components of an application is tightly connected to its function and structure, so that when a change occurs, a certain part of the adjustment can cause changes in other parts or even the entire application as a result of the various tight coupling relationships, and the system architecture is fragile.

Another important point of view from the SOA architecture is business-driven it, which is more tightly aligned with it and the business. Modeling a business based on coarse-grained business services results in a cleaner business and system view, a service-based IT system that is more flexible, easier to reuse, better (and faster) to respond to change, and service-based services that explicitly define, describe, implement, and manage the business hierarchy of coarse-grained service ( including business processes), providing better "traceability" between business models and related it implementations, reducing the gap between them and making business changes easier to deliver to it.

As a result, the main benefits of SOA can be summed up as: it can deliver business value better and faster (centric), rapid resilience (flexibility), and reuse (reusability).

From the evolutionary perspective, SOA was proposed many years ago, and now the reappearance and prevalence of SOA is a combination of several factors. On the one hand is the experience, methods and various design/architecture patterns accumulated by many years of software engineering development and practice, including OO/CBD/MDD/MDA, EAI and middleware, on the other hand, the multi-year development of Internet brings the interactive ability and standardization foundation of the Distributed system unprecedented. At the same time, companies are increasingly focusing on the components of the business model itself to support a highly flexible business strategy. However, the existing enterprise software architecture is not flexible enough to adapt to the increasingly complex enterprise integration, it is difficult to meet the needs of on-demand business, so the business alignment, business agility is the primary goal, loose coupling, support reuse of the SOA architecture approach is favored. See "Service-centric enterprise integration" for more details.

Based on our experience of dealing with clients, it is necessary to clarify a few basic questions that are often confused.

First, SOA is an architectural style, a method, rather than a concrete architecture-specific implementation technology (such as a Web service), specific architectural elements such as Enterprise Service Bus (BUS,ESB).

Often people think that as long as the use of Web Service, is SOA. This is not true, Web service is just a specific technical manifestation of service implementation. Similarly, it is not right to think of SOA as just buying some software and building an ESB, which is only part of the SOA architecture style. First, the ESB is an architectural style element that is summed up in practice, namely bus (the Fieldbus mode), and secondly, the main function of an ESB is to be responsible for connectivity and service mediation, decoupling the requester of the service and the provider of the service.

Second, the primary goal of SOA is to align it with the business, support rapid business change, and second, the flexibility of it architecture and reuse of IT assets.

The need for agility in business is the greatest driving force of SOA. On the one hand, business is increasingly demanding in this regard, on the other hand, today's it is very inflexible and difficult to adapt to the rapidly changing needs of the business, not only because it architecture is inflexible, but more importantly, there is a big gap between elements in the business model and elements of IT systems. This misalignment leads to insufficient communication between the business and IT staff, and changes in the business need to be delivered to the IT system at a significant cost. It's hard to imagine that a business person is interested in a Java object, an EJB, or a JSP page, which is too far from the business world. This alignment of business and it requires the implementation of higher-order abstractions in the IT system, the elements in the business model (services, processes, performance management), and the level of integration that meets the needs of the business (end-to-end dynamic integration of people, information, applications, and processes). Such a service-centric, end-to-end integration environment first enables business changes to be communicated at the level of business elements, making it easier and more accurate to transfer from business to it. Second, this change is isolated to the part that needs to change, not to the rest of the system. This requires that the entire IT architecture itself is loosely coupled and that changes in one service (functionality, data, process, technology environment, etc.) do not affect other services. Finally, we want these services that reflect the business elements to be relatively stable and reusable, which is important to quickly adapt to changes and reduce costs.

Thirdly, in engineering, SOA focuses on service modeling and SOA-based design principles for architectural decision-making and design.

Often meet customers ask the question: SOA is good, why good? What is the SOA approach? How is it different from past methods, such as OO/CBD? Sometimes a Java EE server is fine, why is it so complicated?

From the standpoint of modeling and design, SOA focuses more on the business level, that is, the business component is transformed into a service model through service modeling, it is the bottom of the business architecture, it is the top level of the technical architecture, the connecting link, is a flexible business model and the bridge between it, to ensure the "traceability" between the two. Down here, it is based on existing methods, such as OO/CBD. At the architectural level, SOA focuses more on how to connect multiple distributed systems (including existing systems/legacy systems) across the Enterprise (esb,adapter/connector), how to transform their functions, data into services, and how to pass service mediation mechanisms (ESB, Service Registry) ensures that services interact in a loosely coupled manner, how to assemble (integrate) services into processes, how to manage services and processes, and so on. From there, the architecture, design, and implementation of a specific application for implementing a service can be based on existing practices and methods, such as Java EE or. NET.

Sometimes, because business requirements are relatively simple, all of these things are on a Java EE application server, some elements are not so prominent, but as the scale of the system, to solve the business problems more complex, more scope, the various architectural elements of SOA will become more and more important.

A few important aspects of SOA are briefly discussed in the following sections, including: Service-oriented computing environments, programming models, architectural styles, engineering methods, and related technologies.

　　2. Evolution of computing environment and service-oriented computing environment

2.1 Computing environment

The computing environment consists of a set of computers, software platforms, and interconnected networks that process and exchange digital information, allowing the outside world to access its information resources (1). Different computing environments have different computing styles and programming models, supported by a number of technologies that are specific to the computing environment. How to divide and deploy computing power, data resources in a computing environment, how to make each part communicate with each other, how to model the problem domain conceptually, and then map to the computing environment will be affected and constrained by the computing environment. Therefore, a look at the history of the computing environment will help us understand how service-oriented computing environments evolve.

2.2 Evolution of the computing environment

The evolution of the computing environment has undergone several stages, and in the early host era, the vast majority of computing functions and components of the system were included in a single machine. In the the 1980s, with the PC boom, the computing environment changed a lot. A client/server computing environment is composed of the computing devices connected with the LAN, the computing resources and the data resources are segmented properly, and the client and the server cooperate with each other by means of network protocol, remote call or message to complete the calculation.

In order to meet the needs of higher scalability, multi-layered architectures, the diversification of computing resources and data resources, and the integration of the existing computing environment in the enterprise, especially the host and its legacy systems, are becoming more and more important. With the rapid development of middleware, the concepts of distributed objects, components and interfaces are beginning to be used to better divide the operational logic and data resources in the computing environment. The interaction between the different parts of the computing environment, and also from the original relatively low-level network protocols, remote calls and messaging mechanisms, is developed to support the interaction between distributed objects, components and interfaces, which are usually location-transparent with the support of name Services (naming service), etc. However, due to the lack of universal standardization support, it is difficult to achieve technical transparency, the system is tightly coupled.

With the development of the Internet (Internet), open and standard network protocols are universally supported, and all underlying computing platforms are beginning to support these standards and protocols, which leads to a break in the barriers of interaction between a computing environment and each computing environment. The representation and interaction of data and functions on the basis of XML, Web Services (Web Service) technology and standards, ensuring the versatility and maximum interactivity, which enables the computing environment to evolve into a completely new phase--a computing environment based on standard, open Internet technology. In such a computing environment, the various parts can adopt heterogeneous underlying technologies that use XML to describe and represent their own data and capabilities, and to use open network protocols such as HTTP to shake hands, and to interoperate and exchange data based on Web services. Here, a very important new concept is "service" (2), which is a self-contained feature that the consumer interacts with a service through a well-defined interface (contract), which is based on an open standard such as WSDL (Web Service Description Language). Objects and components weigh the components of a thing itself and relate to each other (that is, what "things" is), and the service represents what a thing does (that is, what "things" does). Web services are a technical means of implementing services, just as objects in various programming languages are the technical means of implementing objects, and EJB in Java EE is the technical means of implementing components. This standards-based, open Internet technology, service-centric computing environment, we call the "service-oriented computing environment."

2.3 Service-oriented computing environment

In a service-oriented computing environment, the system can be highly distributed and heterogeneous. It typically includes a service runtime Environment (service runtime), services integration Infrastructure, service gateways, service Gateway, services Registry and service choreography engine), etc., as shown in 1-1.

The Service Runtime Environment provides services (and service components) the ability to deploy, run and manage, support the service programming model, ensure the security and performance of the system, and so on, service bus provides service intermediary, which enables service users to access services in a transparent and transparent manner. The service registry supports the storage and access of service description information, is an important basis for the implementation of service intermediary, management services, and service assembly engine, the service is assembled into a service process, complete a business process; service gateways are used for service translation at the boundaries of different service computing environments, such as security.

The service-oriented computing environment is open and standard and is defined and supported by the Technical standard protocol stack shown in 1-2. For example, the HTTP protocol for the transport layer, the ws-cdl of the wsdl,business process layer of the Service description layer, and the Policy-related ws-policy. The chapters later in this book discuss all the standards and protocols collectively referred to as WS-*.

Figure 1-1 Components of the SOA computing environment

　　

Figure 1-2 Standard protocol stack for SOA computing environments

　　

The service-oriented computing environment provides a realistic basis for IBM's defined on-demand computing environment. The On Demand computing environment should have the following characteristics, as shown in 1-3.

Figure 1-3 Characteristics of the on-demand computing environment

　　

(1) Integration: Integrate people, processes, applications and data in a comprehensive way.

(2) Virtualization: Integrate distributed, heterogeneous physical resources (servers, storage devices, etc.) and present them as unified logical objects for use in a secure and manageable manner.

(3) Autonomic computing: like organisms, the system has the capability of advanced biological systems, including self-diagnosing and repairing problems, automatic configuration and adjustment to adapt to changes in the environment, automatic optimization of resource usage efficiencies, enhanced workload handling, and self-protection of data and information security.

(4) Open standards: The entire environment is based on open standards, ensuring the interoperability of the system.

2.4 Status of service-oriented computing environment

Different service computing environments, using different technologies and products, mainly combine IBM's products and technologies to introduce the service computing environment implemented on the Java EE platform.

The host creates a service-oriented computing environment on the host by increasing support for Internet technologies and standards. For example, the CICS 3.1 from IBM, which provides support for SOAP and Web services, allows applications on the host to be delivered as Web services for consumer use.

Over the years, key technology providers in the IT community have been working together to define and drive standards for Web services, and are highly compatible on a number of major computing platforms, including. NET,J2EE and open source platforms such as lamplinux,apache,mysql,php/perl/ Python).

IBM is based on the Java EE, providing a comprehensive and powerful service computing environment, as shown in 1-4.

Figure 1-4 The service computing environment provided by IBM

　　

In this computing environment, it is the world of service. Access Services provides the ability to access existing applications or legacy systems, transforming functionality and information from existing systems into services, and IBM provides adapters and frameworks to access different systems to help with conversions. Business App services refers to new applications implemented through the new computing platform, Java (such as IBM's WebSphere Application Server), and the functions and information that they implement are also translated into service offerings. Partner service refers to services that come from partners, and WebSphere Partner Gateway provides a variety of different security differences at the enterprise boundary. Information service is those services that are related to information (not activity), such as accessing heterogeneous data from multiple systems, aggregating, and transforming it into a uniform business data object that the business needs. A process service is a service that aggregates multiple services into a service process that corresponds to business processes, which is often a long-running process. The Interaction service is a way of bringing people's activities through human-computer interaction as part of a process service throughout the business.

In a service-oriented computing environment, the Enterprise service bus is in a very important position, it provides the intermediary of the service, decouple the service requester and the service provider, and is the core of the service computing environment. The ESB is the development of the message middleware in the past, adopting a mode of "bus" to manage and simplify the integrated topology between applications, and to support the dynamic interconnection between applications at the message, event and service level on the basis of widely accepted open standards.

The basic features and capabilities of an ESB include describing the metadata of services and the management of service registrations, the ability to pass data between service requesters and providers and transform them, and support some of the patterns summarized in practice, such as synchronous patterns, asynchronous patterns, and the ability to discover, route, match, and select, To support dynamic interaction between services, decoupling service requesters and service providers. Advanced capabilities, including security support, service quality assurance, manageability, and load balancing.

The standard-based connection service provided by the ESB translates the functions or data resources implemented in the application into services that the service requester can access in a standard manner; When the requestor requests a service, the mediation conversion process in the ESB can be as simple as nothing or complex mediation service support. Includes dynamically locating, selecting a service, message delivery, Routing and transformation, and protocol conversion. This intermediary process is automated by the ESB with knowledge about service registration management and problem domains, such as some rules of the business, and does not require the intervention of service requesters and providers to realize the technical underpinnings of the decoupling service requester and provider. This allows the service requester to not care about the location of the service provider and the specific implementation technology, the two sides in the case of maintaining the same interface, the individual can evolve independently.

As a result, the ESB employs a bus-structured model to simplify the integration topology between applications, providing a standard-based, universal connectivity service through a practice-driven pattern that allows the service requesters and service providers to interact in a loosely coupled, dynamic manner, making the SOA solution at different levels a loosely coupled, Flexible architecture.

It is important to note that an ESB is an architectural pattern that cannot be simply equated to a particular technology or product, but implementing an ESB does require the support of various products at runtime and tooling. IBM has good product support, with runtime support including WebSphere ESB and WebSphere Message Broker, and tools that support WebSphere integration Developer, Enables users to perform related development tasks in a graphical manner, such as publishing services, using various modes, transforming messages, and defining routes.

2.5 Service-oriented programming Model: Service Component Architecture (SCA) and Service Data Objects (SDO)

To facilitate the development of service-oriented applications, IT companies joined together in November 2005 to release the Service component architecture (Component Architecture) and Service data Object specification, which includes IBM, Bea,oracle,sap and so on.

SCA's goal is to greatly simplify the development of services, the direct adoption of Web services and XML development services, so that programmers work on the underlying technology, the need to deal with a variety of heterogeneous environment specific implementation details. SCA defines and regulates technology neutrality and transparent service components, service and service invocation and assembly, while SDO defines and regulates the data in the service world, which has a clearly defined information model, independent of the data source and the specific data access technology, Makes it easier and more efficient for services to access data and exchange data between services.

Many companies have supported SCA/SDO on the Java EE platform and have also provided C + + versions. IBM WebSphere Process Server 6 implements the SCA/SDO specification and provides support for the latest SOA programming model, which has been widely used in many practices.

3. Evolution of software architecture and design principles of service-oriented (SOA)

Software development has always been a difficult task, because the problems we are dealing with are becoming more and more complex, and the most important means for people to deal with this complexity is abstraction. Looking back on history, our level of abstraction is becoming more and more high, reflected in all aspects, from programming languages, platforms, development processes, tools to patterns. In particular, patterns are found in software systems that are structurally well designed, whether they are structural paradigms that are stable at the micro level (objects, components), or architectural patterns that appear at a macro level. What abstractions are used to model problem domains? How do you define collaboration and structural relationships between components? How do you define the structure and behavior of the system that you see from the outside world? What are the design principles that guide our architectural decisions? What are the best practices and patterns that can be used for reference? All these, form different design styles and architectural paradigms ( Architecture Paradigm).

Typically, an architectural paradigm, including design principles, comes from the architectural specifications, constituent elements, and relationships of the practice, and how they are identified, described, and controlled throughout the development life cycle. Architecture has evolved from a single client/server model in the past to a variety of distributed computing models in three-tier and multi-tiered architectures. Today, people begin to talk about and practice service-oriented, more distributed architectural paradigms.

In terms of abstraction, SOA increases the elements of service, process and so on based on the original method. These abstract means are shown in relation to 1-5.

How can we use these abstractions to transform a business requirement into a process, service, and further modeling as a service component, and then implement it in the context of a specific implementation, using the functionality and data resources of the existing system? 1-6 shows the SOA architecture concept model summarized by IBM.

The SOA architecture inherits various principles from object and component design, such as encapsulation, self-containment, and so on. Design principles that guarantee the flexibility, loose coupling, and reusability of services are equally important to the SOA architecture.

Structurally, service bus is one of the architectural patterns of SOA.

For services, some of the common and discussed design principles are as follows:

(1) No status. To prevent service requesters from relying on the status of the service provider.

(2) Single instance. Avoid functional redundancy.

Figure 1-5 An important abstraction in SOA

　　

Figure 1-6 Conceptual architecture pattern for SOA

　　

(3) a clearly defined interface. The interface of a service is defined by WSDL and is used to indicate the line between the public interface of the service and its internal dedicated implementation. The ws-policy is used to describe the service specification, which is used to define the message format that is exchanged (that is, the public data of the service). The user relies on the service specification to invoke the service, so the service definition must be stable for a long time, once published, not arbitrarily changed, the definition of the service should be as clear as possible, reduce the user's inappropriate use, do not let the user see the private data inside the service.

(4) Self-contained and modular. Services encapsulate those activities and components that are stable and recurring in the business, and the functional entities that implement the services are completely autonomous, deploying independently, versioning, self-managing, and recovering.

(5) coarse grain size. The number of services should not be too large, relying on message interaction instead of remote procedure call (RPC), usually with a larger message volume, but the frequency of interactions between services is low.

(6) loose coupling between services. Service users see the interface of the service, its location, implementation technology, the current state and so on is not visible to the user, service private data is not visible to service users.

(7) Ability to reuse. The service should be reusable.

(8) Interoperability, compliance, and policy statements. In order to ensure the comprehensive and clear service specification, the strategy becomes an increasingly important aspect. This can be technology-related content, such as a security requirement for a service, or a business-related semantic aspect, such as the cost to meet or a service-level requirement, which is important for a service to interact with. Ws-policy is used to define configurable interoperability semantics to describe the expectations of a particular service and control its behavior. At design time, policy statements should be used to ensure complete and unambiguous service expectations and semantic compatibility.

　　4. Evolution of software engineering and service-oriented architecture

Software engineering methods and processes accompany with the continuous development of the practice. After the software crisis, from the waterfall model, prototype method, such as the process, document-intensive, control more methods, gradually developed to lightweight, agile and iterative methods. These methods are more humane and avoid stifling people's initiative and creativity because of the excessive process. These approaches emphasize the rapid delivery of software that is valuable to customers, direct communication, continuous integration, and continuous quality assurance.

A common intersection of SOA and current software engineering processes is business value driven (centric), which emphasizes speed. SOA starts with software flexibility and reusability, while agile processes are based on software delivery efficiency.

The architectural nature of SOA makes agile processes well suited to the implementation of SOA projects. In the SOA architecture, the independence of services enables each service to be developed, tested, and integrated independently. An enterprise's IT system, if it is a SOA-based computing environment, the environment is a service ecosystem, and each development of a service, can be deployed independently, as part of this ecosystem. This is a good way to support continuous integration, continuous quality assurance, and a good way to make the service immediately generate business value, rather than hardship and other services in place. The features of the service make the agile process and the SOA architecture a good combination of the two to complement each other. With our practice of working with different clients, we have fully realized the benefits of both the risk control in the implementation process and the adaptability of changing business requirements. For example, we have moved from the waterfall process to the iterative development process in Cosco, adopting the principle of agile approach.

In Korea, our team is from IBM China, IBM Korea and South Korea customers own engineers, branch offices in Seoul and Beijing two places, how can these engineers work together to quickly deliver high-quality systems without involving each other? For engineers in Beijing, Beijing's team is unable to replicate the customer's existing system in Seoul, How do I test my own development services? Through service modeling, the system is decomposed into several independent services, and we hand over to the players in Seoul the services that we have to reuse the existing systems, the rest to the players in Beijing, and require each service developer to provide a simple "pseudo" implementation (Mock service). Initially, these simple implementations were deployed in test environments in Beijing and Seoul, and the service development teams began to independently develop their own services, while process developers began to develop their processes at the same time, but the service was based on those simple implementations, But these simple implementations are sufficient to support meaningful unit and integration testing. Then, once a service is implemented, it is deployed to the actual environment, and the request to the service is routed to the real implementation by adjusting the service mediation configuration of the ESB. Once the real implementation is problematic, you can also switch back to a simple implementation to avoid impacting the unit and integration testing of other services, processes. This flexibility brings a ready-to-use, ready-to-deploy, ready-to-integrate and tested process that is advantageous for agile processes.

　　5. SOA Technology Overview

This section discusses the key technologies and standards used in the current SOA architecture.

5.1 Main components of SOA

In the previous discussion of the computing environment, we have mentioned that the main components of the SOA computing environment are the service runtime environment, the service bus, the service registry, the service gateway, and the process engine. Typically, it also includes service management, Business Activity Monitoring (monitoring), and business performance management (performance MANAGEMENT,BPM). In addition, we need tools to support service modeling, development, and orchestration services. In terms of analysis and design, we need service-based analysis, design methodologies, which we typically call service modeling, including service identification, definition, and implementation strategies, and the output is a service model.

5.2 SOA key technologies and standards

Web services serve as the primary means of implementing services in an SOA. We first understand the standards related to Web service, most of which are prefixed with "ws-" as the name, so collectively referred to as WS-*. The most basic protocols for Web services include UDDI,WSDL and soap, through which we can provide direct and simple Web service support, as shown in 1-7.

But the basic protocol does not guarantee the security and reliability required for enterprise computing, so we need to increase this protocol, such as Ws-security,ws-reliability and ws-reliablemessaging, for complex business scenarios, We need languages like Ws-bpel and WS-CDL to orchestrate multiple services into business processes, and to manage service protocols such as WS-MANAGEABILITY,WSDM. Standards related to Web services are rapidly evolving. Currently in the SOA product and practice, in addition to the basic protocol, the more important also includes Bpel,ws-security,ws-policy and SCA/SDO. As shown in table 1-1, a basic summary is given, and the following chapters describe important technologies and standards.

Figure 1-7 Basic Web Services Protocol

　　

Table 1-1 Current Web service protocol stacks

　　

5.3 The status of SOA technology support in industry

At present, the Web standards and technology in the evolution of different technical environment support is different, but the above mentioned basic core protocol, are very good support. The degree of acceptance and support for Web service protocols is shown in 1-8.

Figure 1-8 Acceptance of the current Web service

　　

　　Summary

This article introduces the basic concepts of SOA and clarifies some of the issues that are easily confused, then discusses some important aspects of SOA, including service-oriented computing environment, programming model, architectural style, engineering method, etc. It also provides a very brief overview of SOA support in the industry, and for more details, see the reference links attached to each section, which provide readers with very good information and documentation to understand the development details of SOA-related technologies and standards. Through table 1-2, readers can also learn about the involvement of industry, including manufacturers and standardization organizations.

Basic concepts and design principles of SOA