Advanced skills in system architecture design · Service-oriented architecture design theory and practice

Click to enter the series of articles directory

1. Related concepts of SOA

1.1Definition of SOA

From the definition of the basic principles of software, it can be considered that SOA is a component model that connects different functional units of an application (called services) through well-defined interfaces and contracts between these services. The interface is defined in a neutral way and should be independent of the hardware platform, operating system and programming language on which the service is implemented. This allows services built into a variety of such systems to interact in a unified and common way.

1.2 Business process and business process execution language

Business process and business process execution language (Business Process Execution Language, BPEL) . Business process refers to a process or a series of actions performed to achieve a certain business purpose. Using BPEL, users can implement service-oriented architecture from top to bottom by composing, orchestrating, and coordinating Web services. BPEL is currently used to integrate existing Web Services and organize the existing Web Services into a new Web Service according to the required business processes. On this basis, a Service is formed that is the same as a single Service from the outside world.

2. Development History of SOA

(1) Embryonic stage : This widespread use of XML allows organizations to define the metadata of documents, enable electronic data exchange within and between enterprises, and specifies the format and structure of data exchange between services and within services.

(2) Standardization stage : International standards and specifications - Simple Object Access Protocol (SOAP), Web Service Description Language (Web Service Description, UDDI).

(3) Mature stage : 3 heavyweight specifications - SCA, SDO, WS-Policy. SCA and SDO form the basis of the SOA programming model, and WS-Policy establishes the specifications for secure interactions between SOA components.

3. The difference between SOA and microservices

(1) Microservices are more sophisticated than SOA. Microservices exist more as independent processes and have no influence on each other.

(2) The interface method provided by microservices is more universal, such as HTTP RESTful method, which can be called by various terminals regardless of language and platform restrictions.

(3) Microservices are more inclined to a distributed and decentralized deployment method, which is more suitable in Internet business scenarios.

As follows, a comparison chart between SOA architecture and microservice architecture:

3. SOA reference architecture

IBM's Websphere business integration reference architecture is a typical service-centered enterprise integration architecture, which can be divided into six categories :

(1) Business Logic Service.
(2) Control Service.
(3) Connectivity Service.
(4) Business Innovation and Optimization Service.
(5) Development Service.
(6) IT Service Management.

4. Main protocol specifications of SOA

As follows, based on Web service protocol:

(1) UDDI protocol : unified description, discovery and integration protocol. Contains a standard specification for service description and discovery, which enables business entities to discover each other; defines how they interact on the Internet and share information in a global registration architecture.

(2) Web Service Description Language (WSDL) : WSDL is an XML language used to describe Web services and explain how to communicate with Web services. Describes 3 basic attributes of Web services:

• What the service does - the operations (methods) provided by the service.
• How to access the service - the data format and necessary protocols for interacting with the service.
• Where the service is located - a protocol-related address, such as a URL.
  The following is the basic structural framework of the document:
  

(3) SOAP protocol : SOAP is a simple protocol for exchanging information in a decentralized or distributed environment. It is an XML-based protocol.
(4) REST specification : In order to allow different software or applications to transfer information to each other in any network environment. Microservices are exposed to callers in the form of REST API. RESTful is the form of REST. It is a general term for a type of architectural design or application that follows REST design ideas while satisfying design constraints. This type can be called RESTful, which can be understood as resource expressive state transfer:

• Resources : All transactions exposed to clients on the Internet can be regarded as a resource.
• Representation : Representation is used in REST to describe the status of resources at a certain time in the Web.
• State transfer : divided into two types,
  application state - a snapshot of user request session-related information within a certain period of time, saved on the client.
  Resource status - saved on the server, is a snapshot of the resource request representation at a certain time.
• Hyperlinks : Make connections to other resources by embedding links in your pages.

5. SOA design standard requirements

(1) Document standardization .
SOA services have platform-independent self-describing XML documents. Web Services Description Language is a standard language for describing services.

(2) Communication protocol standards .
SOA services communicate using messages, which are typically defined using XML Schema (also known as XML Schema Definition, XSD).
(3) Unified registration and integration of applications .
Within an enterprise, SOA services are maintained through a registry that plays the role of Director Listing. The application looks for and calls a service in the Registry. Unified description, definition and integration are the standards for service registration.
(4) Quality of service (Qos) . mainly include:

• Reliability : transmission characteristics when transmitting documents between service consumers and service providers (and only transmit once, transmit at most once, repeat message filtering, guaranteed message delivery)
• Security : Web service security specifications are used to ensure the security of messages.
• Policies : Service providers sometimes require service consumers to communicate with a certain policy. For example, a service provider may require consumers to provide a Kerberos security token to obtain a certain service.
• Control : In SOA, processes are created using a discrete set of services. BPEL4WS or WSBPEL (Web Service Business Process Execution Language) is the language used to control these services.
• Management : There must be a unified management system for all services running in multiple environments so that system administrators can manage them effectively. Any service implemented based on WSDM can be managed by a WSDM-companyliant management solution.

6. The role and design principles of SOA

(1) The main function of SOA: breaking information islands and converting applications and resources into services. And turn these services into standard services to form resource sharing.
(2) The design principles of SOA mainly include:

• Stateless .
  To avoid the service requester being dependent on the service provider's state.
• Single instance .
  Use a highly cohesive implementation method to avoid functional redundancy.
• Well-defined interface .
  The interface of a service is defined by WSDL, which is used to indicate the boundary between the public interface of the service and its internal private implementation.
• Self-contained and modular .
  Services encapsulate those activities and components that are stable and recurring in business. The functional entities that implement services are completely independent and can be deployed, versioned, self-managed and restored independently.
• Coarse grained .
  The number of services should not be too large and rely on message interaction rather than Remote Procedure Call (RPC). Usually the message volume is large, but the frequency of interaction between services is low.
• Loose coupling between services .
  What service users see is the interface of the service. Its location, implementation technology, and current status are not visible to users. Service private data is not visible to service users.
• Interoperability, Compatibility, and Policy Statements .
  In order to ensure that the service specification is comprehensive and clear, policies are used to define configurable interoperability semantics to describe the expectations of specific services and control their behavior. Leverage policy statements to ensure completeness and clarity regarding service expectations and semantic compatibility.

7. SOA design patterns

7.1 Service registry mode

The service registry supports the development, publication, and management of service contracts, policies, and metadata that drive SOA governance.
(1) Service registration : Application developers, also called service providers, publish their functions to the registry.
(2) Service location : That is, developers of service applications help them query registration services and find services that meet their own requirements.
(3) Service binding : The consumer of the service uses the retrieved service contract to develop code. The developed code is bound to the registered service, calls the registered service, and interacts with them.

7.2 Enterprise Service Bus Model (EBS)

The enterprise service bus model provides a standard software underlying architecture. Various program components can be "inserted" into the platform as service units and can interact with each other in a standard message communication method . Its core functions are as follows:

(1) Message routing and addressing services that provide location transparency. Program components do not need to pay attention to each other's routing and addressing.
(2) Provide management functions for service registration and naming.
(3) Support multiple messaging specifications (such as request/response, publish and subscribe).
(4) Supports a variety of widely used transmission protocols.
(5) Support multiple data formats and their mutual conversion.
(6) Provide logging and monitoring functions.

As shown below, EBS diagram :

7.3 Microservice model

Microservices Architecture Breaking a large single application or service into multiple microservices allows you to scale individual components rather than the entire application stack to meet service level agreements. The microservice architecture splits services around business areas. Each service can be developed, managed and iterated independently. They communicate with each other using a unified interface, realizing deployment, management and service functions in dispersed components, making product delivery easier. It becomes simpler to effectively split applications and achieve agile development and deployment. The characteristics of the microservice model are as follows:
(1) Decoupling of complex applications : The microservice architecture decomposes a single module application into multiple microservices while keeping the overall functionality unchanged.
(2) Independent : Microservices are developed, tested and deployed independently in the system software life cycle.
(3) Flexible technology selection : The technology selection of system applications under the microservice architecture is decentralized. Each development team can choose the appropriate system architecture and technology based on the business needs of its own application.
(4) Fault tolerance : Each microservice is independent of each other, faults will be isolated in a single service, and other microservices in the system can achieve application layer fault tolerance through mechanisms such as retry and smooth degradation, thereby improving the fault tolerance of system applications.
(5) Loose coupling and easy expansion : Each service in the microservice architecture is loosely coupled and can be independently expanded according to actual needs, reflecting the flexibility of the microservice architecture. The schematic diagram of monolithic application architecture and microservice architecture is as follows:

7.4 Microservice architecture model solution

The microservice architecture model solution mainly includes:
(1) Aggregator microservice : The aggregator acts as a process commander and calls multiple microservices to implement the functions required by system applications.
(2) Chained microservices : After the client or server receives a request, nested recursive calls between multiple services will occur and a processed response will be returned.
(3) Data sharing microservices : This model is suitable for the transition stage from monolithic architecture to microservice architecture. Strong coupling relationships are allowed between services, such as multiple microservices sharing cache and database storage.
(4) Asynchronous messaging microservices : For some business logic that does not need to run in a synchronous manner, message queues can be used instead of REST to implement requests and responses to speed up the response speed of service calls.

As follows, monolithic architecture and microservice architecture:

7.5 Problems and challenges faced by microservice architecture

(1) Service discovery and service call chain tracking become difficult.
(2) It is difficult to achieve strong consistency in traditional databases and instead pursues eventual consistency.

8. Issues that should be paid attention to when building SOA architecture

(1) Integration requirements in the original system architecture include: application integration requirements, terminal user interface integration requirements, process integration requirements, and existing system information integration requirements.

(2) The control of service granularity and the design of stateless services are expressed as follows:

• Service granularity control : It is recommended to use coarse-grained interfaces for services that will be exposed outside the entire system, while relatively fine-grained service interfaces are usually used within the enterprise system architecture.
• Design of stateless services : Specific services in the SOA system architecture should be independent, self-contained requests. When implementing these services, the state of the previous request is not required, which means that the services should not depend on the context of other services. And state, that is, services in SOA architecture should be stateless services.

9. SOA implementation process

(1) Select SOA solutions mainly from the following three aspects:

• Try to choose a plan that allows for overall planning.
• When choosing, fully consider the needs of the company itself.
• Conduct inspections from technical aspects such as platform and implementation.

(2) Business process analysis mainly focuses on:

• Establish service model :
  top-down decomposition method, business goal analysis method, bottom-up analysis method.
• Establish business processes :
  establish business objects (business objects such as entities, processes, events, etc.), establish service interfaces, and establish service processes.

Click to enter the series of articles directory