Overview of Service-Oriented Architecture

Overview of Service-Oriented Architecture

Author/itso, Raleigh Center

This article briefly describes the development of the service-oriented architecture. Then, I explored the relationship between component-oriented development and service-oriented architecture, and explained how to use components as the infrastructure for implementing services.

Commercial driving force of new methods
Although IT managers have been faced with difficulties in cutting costs and maximizing the use of existing technologies, they must continue to work hard to better serve customers, quickly respond to the company's strategic focus and win greater competitiveness.
Under all these pressures, there are two basic themes: heterogeneity and change. Nowadays, most enterprises have a variety of systems, applications, and architectures of different periods and technologies. Integrating products from multiple vendors across different platforms is like a nightmare. However, we cannot simply use a vendor's product because it is so difficult to change the application suite and support infrastructure.
In today's IT managers, change is the second topic. Globalization and e-commerce have accelerated the pace of change. Globalization brings about fierce competition, shortening the product cycle, and every company wants to win over its competitors. Driven by competing products and a large amount of product information that can be obtained from the Internet, the customer needs to change more quickly. As a result, competition in improving products and services is further intensified.
In order to meet the increasing demands of customers, technical improvements are constantly accelerating. Enterprises must quickly adapt to such changes, otherwise they will not survive, let alone success in this turbulent and competitive environment, and IT infrastructure must support enterprises to improve their adaptability.
Therefore, enterprises and organizations are isolating vertical business units from the 1980s s or earlier, and paying attention to the horizontal structure of business processes in the 1980s S and 1990s s to develop new ecosystem business examples. The focus is on expanding the supply chain and supporting customers and partners to access business services. Figure 1 shows the development of an enterprise.
How can we make the enterprise's IT environment more flexible and faster to respond to changing business needs? How can these heterogeneous systems and applications communicate as seamlessly as possible? How can we achieve the goal of an enterprise without making the enterprise go bankrupt?
It responders/supporters develop concurrently with the development of enterprises, as shown in figure 2. Now, many IT managers and professionals believe that we are finding a satisfactory answer-service-oriented architecture.
To reduce the problems posed by the heterogeneous, interoperability, and changing requirements, such architecture should provide a platform to build application services with the following characteristics:
L loose coupling
L transparent location
L protocol independence
Based on such a service-oriented architecture, service users do not even have to worry about specific services to communicate with, because the underlying infrastructure or service "bus" will represent users in making appropriate choices. The infrastructure hides as many technical details as possible from the requester. In particular, technical specifications from different implementation technologies (such as J2EE or. NET) should not affect SOA users. If a service implementation already exists, we should re-consider replacing it with a "better" Service implementation. The new service implementation must have a better service quality.

Service-Oriented Architecture as a solution
Since the "Software Crisis" has promoted the creation of software engineering, the IT industry has been striving to find solutions to the above problems. In the past few years, the progress of some core technologies has brought us to this day. Next, we will briefly discuss these core technologies, but we will focus on how they help solve it problems.

Object-Oriented Analysis and Design
In applying UML and patterns-an introduction to object-oriented analysis and design, larman describes the essence of Object-Oriented Analysis and Design as "considering problem domains and logical solutions from the perspective of objects (objects, concepts or entities ". In "object-oriented softwareengineering: A Use Case Driven Approach", Jacob and others define these objects as "they are characterized by many operations and States (remembering the impact of these operations) ".
In object-oriented analysis, such objects are identified and described by problem domains. In the object-oriented design, they are converted into logical software objects, these objects will be implemented in an object-oriented programming language.
Through object-oriented analysis and design, some aspects of objects (or object groups) can be encapsulated to simplify the analysis of complex business scenarios. To reduce complexity, you can also abstract some features of an object, so that you can only capture important or essential aspects.
Component-based design is not a new technology. It naturally evolved from an object example. In the early stages of Object-Oriented Analysis and Design, fine-grained objects were advertised as "Reusable" mechanisms, but such objects have a low level of granularity, there is no proper standard for reuse to be widely used in practice. In application development and system integration, coarse-grained components are increasingly becoming the target of reuse. These coarse-grained objects aggregate more fine-grained objects to provide well-defined functions. In this way, you can also package the solution package into such a "component ".
Once the Organization implements a complete architecture based on completely independent functional components at a higher level, it can divide the applications that support the enterprise into a group of components with a larger granularity. Components can be viewed as a mechanism for packaging, managing, and publishing services. They can use a group of technologies together: enterprise-level use cases can be achieved through the combination of updated object-oriented software development and legacy systems.

Service-oriented design
In "component-based development for enterprise systems", Allen involves the concept of a service. "It describes components as executable code units encapsulated by the physical black box that provides the relevant services. Its services can only be accessed through consistent published interfaces (including interaction standards. Components must be connected to other components (through communication interfaces) to form a larger group ". A service is usually implemented as a coarse-grained discoverable software entity. It exists as a single instance and interacts with applications and other services through a loosely coupled message communication model. Figure 3 shows important service-oriented terms:
L service: logical entity, a contract defined by one or more published interfaces.
L service provider: software entity implementing service specifications.
L service user (or requester): The software entity that calls the service provider. Traditionally, it is called a "client ". A service user can be an end user application or another service.
L service locator: a special type of service provider, which acts as a registration center and allows you to find Service Provider Interfaces and service locations.
L Service Proxy: a special type of service provider that can send service requests to one or more other service providers.
 
Interface-based Design
In component and service development, interface design is required, so that the software entity can implement and publish the key part of its definition. Therefore, in component-based and service-oriented systems, the concept of "interface" is critical to successful design. The following are some important definitions related to interfaces:
L Interface: defines a set of public method signatures, which are logically grouped but not implemented. The interface defines the contract between the service requestor and the provider. All methods must be provided for any implementation of interfaces.
L released interface: a unique and accessible interface. The client can discover it through the registration center.
L public interface: an accessible interface that can be used by the client. However, it is not released. Therefore, static knowledge about the client is required.
L dual interfaces: interfaces are usually developed in pairs. In this way, one interface depends on another interface. For example, a client must implement an interface to call the requester, this is because the client interface provides some callback mechanisms.
Figure 4 defines the UML definition of the Customer Relationship Management (CRM) service, which is represented as a UML component. The specific implementation interfaces include accountmanagement, contactmanagement, and systemsmanagement. Among these interfaces, only the first two interfaces are published interfaces. However, the latter is a public interface. It should be noted that the systemsmanagement interface and the managementservice interface constitute a dual interface. Crmservice can implement many such interfaces and implement Interface Behavior in multiple ways. This capability depends on whether the client allows greater flexibility in implementing the behavior. It is even possible to provide different or additional services to specific types of clients. In some runtime environments, such functions are also used to support different versions of the same interface on a single component or service.
 
Layered application architecture
As mentioned above, object-oriented technology and language are an excellent way to implement components. Although components are the best way to implement services, you must understand that a good component-based application may not constitute a good service-oriented application. Once you understand the role of a service in the application architecture, component developers are likely to use existing components. The key to this transformation is recognizing that the service-oriented approach implies additional application architecture layers. Figure 5 demonstrates how the technology layer is applied to the program architecture to provide a more granular implementation (it is closer to the application's users ). We have created an application edge term called this part of the system, it reflects the fact that the service is an excellent way to expose the external view of the system (through internal reuse and combined use of traditional components ).
 
Measure the test taker's knowledge about the service-oriented architecture.
A service-oriented architecture provides a way to build a distributed system that provides application functions as a service to end-user applications or other services. The components can be divided into functional elements and service quality elements. Figure 6 shows the architecture stack and elements that may be observed in a service-oriented architecture.
Note: the service-oriented architecture stack is a controversial issue, because various supporters have proposed several different stacks. Our stack is not proposed as a Service Stack. This is because we want to build a useful framework.
The architecture stack is divided into two halves. The left half focuses on the functional aspects of the architecture, while the right half focuses on the service quality aspects of the architecture. These elements are described in detail as follows:
Functional aspects include:
L transmission is a mechanism used to send service requests from service users to service providers and send responses from service providers to service users.
L service communication protocol is a negotiated mechanism through which service providers and service users can communicate with each other regarding the content to be requested and the content to be returned.
L service description is a negotiated model used to describe what the service is, how the service should be called, and what data is required to successfully call the service.
L describe the services actually available.
L a business flow is a collection of services that can be called in a specific order and using a group of specific rules to meet business requirements. Note: You can regard a Business Process as a service, which leads to the idea that a business process can be composed of services of different granularities.
L The Service Registration Center is a repository of services and data descriptions. Service providers can publish their services through the service registration center, service users can discover or find available services through the service registration center. The Service Registration Center can provide other functions for services that require a centralized repository.
Service quality includes:
L a policy is a set of conditions and rules under which the service provider can apply the service to the user. Policies have both functional and service quality-related aspects. Therefore, both functional and service quality areas have policy functions.
L security is a rule set that can be used for authentication, authorization, and access control of service users who call services.
L transmission is an attribute set and can be applied to a group of services to provide consistent results. For example, if you want to use a group of services to complete a business function, all services must be completed, or none can be completed.
L management is an attribute set that can be applied to management services or services.

SOA collaboration
Figure 7 shows the collaboration in the service-oriented architecture. These collaborations follow the "search, bind, and call" example. service users perform dynamic service locating by querying the Service Registration Center to find services that match the standard. If a service exists, the Registration Center provides the user with the interface contract and Endpoint address of the service. Demonstrate entities that support the "search, bind, and call" example in the service-oriented architecture.
The roles in the service-oriented architecture include:
L service user: the service user is an application, a software module, or another service that requires one service. It initiates a query of services in the Registration Center, binds services through transmission, and performs service functions. The service user executes the service according to the interface contract.
L service provider: a service provider is an entity that can be addressed through a network. It accepts and executes requests from users. It publishes its own service and interface contract to the service registration center so that service users can discover and access the service.
L Service Registration Center: The Service Registration Center is a supporter of service discovery. It contains a repository of available services and allows interested service users to search for Service Provider Interfaces.
Each entity in the service-oriented architecture plays one or more of the three roles of the service provider, user, and registration center ). The operations in the service-oriented architecture include:
L release: to make the service accessible, You need to publish the service description so that the service user can discover and call it.
L discovery: the service requestor locates the service by querying the Service Registration Center to find the service that meets its standards.
L binding and calling: after the service description is retrieved, the service user continues to call the service based on the information in the service description.
Components in the service-oriented architecture include:
L service: You can use the service through published interfaces and allow service users to call the service.
L Service Description: service description specifies the way in which the service user interacts with the service provider. It specifies the format of the request and response from the service. A service description can specify a set of preconditions, backend conditions, and/or QoS levels.
In addition to the definition of dynamic service discovery and service interface contract, the service-oriented architecture also has the following features:
L services are self-contained and modular.
L services support interoperability.
L services are loosely coupled.
L The service is location-transparent.
L a service is a combination of components.
These features are also the main features that meet the requirements of the e-commerce on-demand operating environment, as defined in "e-business on demand and service-oriented architecture.
Finally, it should be noted that the service-oriented architecture is not a new concept. As shown in figure 8, the technologies involved in the service-oriented architecture include at least CORBA, DCOM, and J2EE. Service-Oriented Architecture early adopters have also successfully created their own service-oriented enterprise architecture based on messaging systems (such as IBM WebSphere MQ. Recently, the SOA activity stage has been expanded to include World Wide Web (WWW) and Web services.
Services in the SOA Scope
In the service-oriented architecture, services mapped to business functions are determined during business process analysis. Services can be fine-grained or coarse-grained, depending on the business process. Each service has a well-defined interface through which you can discover, publish, and call a service. Enterprises can publish their services to their business partners or publish services within the Organization. Services can also be combined by other services.

Services and components
A service is a coarse-grained processing unit that uses and generates a set of objects transmitted by values. This is different from the objects in programming language terms. On the contrary, it may be closer to the concept of business transactions (such as CICs or IMS transactions) rather than the concept of remote CORBA objects.
A service is composed of components that work together to provide the business functions requested by the Service. Therefore, components are more granular than services. In addition, although services are mapped to business functions, components are usually mapped to business entities and business rules that operate on them. As an example, let's take a look at the order component model of the WS-I Supply Chain Management sample, as shown in 9.
In component-based design, you can create components to strictly match business entities (such as customer, order, and order item )), and encapsulate the behavior that matches the expected behavior of these entities.
For example, the order component provides the ability to  about the list of ordered products and the total number of ordered products) the component provides the function to obtain the quantity and price information of ordered products. The implementation of each component is encapsulated behind the interface. Therefore, the user of the purchase order component does not know the mode of the purchase order table, the algorithm for calculating taxes, and the rebates and/or discounts in the total order amount.
In service-oriented design, services cannot be designed based on business entities. On the contrary, each service is a complete unit for managing operations in a group of business entities. For example, customer service will respond to requests from any other system or services that need to access customer information. Customer Service can process requests for updating customer information, add, update, and delete investment portfolios, and query customer order history. Customer Service has all data related to the customers it manages and can query other services on behalf of the caller to provide a unified view of customer service. This means that a service is a manager object that creates and manages a group of components.

Benefits of a service-oriented architecture
As mentioned above, enterprises are dealing with two problems: rapidly changing capabilities and cost reduction requirements. To maintain competitiveness, enterprises must quickly adapt to internal factors (such as mergers and acquisitions) or external factors (such as competitiveness and customer requirements ). It requires economic and flexible IT infrastructure to support enterprises.
We can realize that adopting a service-oriented architecture will bring us several benefits and help us to succeed in today's turbulent business environment:

Use existing assets
SOA provides an abstraction layer through which enterprises can continue to use its investment in it by encapsulating these existing assets into services that provide enterprise functions. Organizations can continue to get value from existing resources without having to build from scratch.

Easier integration and management complexity
In the service-oriented architecture, integration points are standards rather than implementation. This provides transparency and minimizes the impact of infrastructure and those changes. By providing service specifications for existing resources and assets built based on totally different systems, integration becomes easier to manage because complexity is isolated. This is even more important when more companies collaborate to provide value chains.

Faster response and marketing speed
The ability to combine new services from existing services provides unique advantages for organizations that need to flexibly respond to demanding business requirements. By using existing components and services, you can reduce the time required to complete the software development lifecycle (including collection requirements, design, development, and testing. This allows organizations to quickly develop new business services, quickly respond to changes, and reduce time to market preparation.

Reduce costs and increase reuse
By publishing business services in a loosely coupled manner, enterprises can easily use and combine services according to business requirements. This means the reduction of resource replicas, and the increase in the possibility of reuse and cost reduction.

To achieve
With SOA, enterprises can plan ahead and make full preparations for the future. SOA business processes are composed of a series of business services that can be created, modified, and managed more easily to meet the needs of different periods.
SOA provides flexibility and response capabilities, which are crucial for the survival and development of enterprises. However, the service-oriented architecture is by no means a panacea, and migrating to SOA is not an easy task. Do not expect to migrate the entire enterprise system to a service-oriented architecture in one night. We recommend that you migrate the appropriate part of the enterprise functions when business requirements appear or are exposed.