Service-Oriented Architecture: Implementation Challenges

Introduction

You may have considered implementing SOA in your enterprise. In this implementation process, you will encounter complex challenges-including those that only exist in your company and industry. However, with a flexible roadmap to control the implementation of SOA, you can quickly face and solve these challenges.

SOA is an important new architecture example that supports modular implementation of intermediate layer solutions. This method is especially applicable when multiple applications developed based on different technologies run on different platforms and the platforms interact with each other.

However, SOA can be implemented without waking up overnight. First, enterprises must work toward building advanced components and services. A road map and enterprise-specific standards are essential prerequisites-to ensure systematic implementation of this architecture in the enterprise.

This article provides different solutions to the various challenges that enterprises will encounter when implementing SOA. Some examples are provided based on EDS and customer practices. At the same time, it is also adjusted based on eds experience when constructing a tool, which facilitates the configuration, management, and deployment of enterprise network services.

Architecture Components

Figure 1 shows the basic components of an SOA architecture. These components include:

A service provider. A service provider is a component or component set that provides business functions in a stateless manner and accepts predefined inputs and outputs.

A service consumer is a component set and is interested in using one or more services provided by the service provider.

Service Warehouse. A service warehouse includes a description of the service. The service provider records the services they provide in the service warehouse, and the service consumer accepts the service warehouse to find the services they provide.

Figure 1. SOA architecture component

Challenges

There are eight key challenges for enterprises to implement SOA. These challenges are listed in a typical project deployment plan as follows:

1. Service identification. What is a service? What commercial functions can a specified service provide? How can we provide services with the best granularity?

2. Service place. In an enterprise, where is the best service place?

3. Definition of service scope. How can these services be integrated into the logic field?

4. Service packaging. How can the functions provided by the existing host system be packaged as reusable services?

5. service coordination. How can we coordinate these complex services?

6. How can I send the request from a service consumer to an appropriate service or service field?

7. Service Management. How do enterprises manage and maintain services in a step-by-step manner?

8. Adoption of service communication standards. How can enterprises adopt a specific standard for a long time?

Service Identification

Challenges

Correct identification of services and Determination of corresponding service providers is a key primary step when building SOA. In today's world, similar business functions within an enterprise can be provided by multiple systems.

Method

There are two ways to solve this challenge: service rationalization and service consolidation. Service rationalization is a careful analysis of all systems and application platforms that provide specific commercial functions. Through service rationalization, commercial functions implemented by a small number of access systems can be accessed on the massive access system platform. Using this method on streamlined systems, we can deliver more reliable services.

Figure 2. service rationalization account Configuration

Figure 2 provides an example of service rationalization. A large number of front-end applications, such as online banking, CRM, and vru, require an account to configure relevant information provided by commercial functions. The information record system of the customer and account database should support account configuration for commercial functions. You can call this function based on the features of the foreground application to return the subsets of the account configuration.

In this example, enterprises increase online and vru access for customers while reducing the use of CRM that requires human interaction.

Service merge

Service merging combines all services into one service mode, which supports the expansion of user interfaces displayed by multiple individual services. The combined and redefined services can be provided stably by independent application systems.

Figure 3. Service merging product catalog

Figure 3 illustrates how a product directory library is accessed by three independent services. The three services are used to find a predefined subset of product-related information. After the service is merged, only one service provides all the product directories. This service includes the information provided by each independent service in the service merge. The service consumer selects the content of interest in the product catalog. Service merging becomes an efficient way to help a large number of streamlined services support the same commercial functions.

Service Location

Challenge services are often executed on a specific set of commercial entities on a specific record system. This record system is an ideal place for service execution. However, distributed architecture solutions will lead to the spread of commercial data across multiple application platforms, while commercial entities will also generate a large number of records generated by the record system. Data synchronization between two systems becomes a key requirement. In this case, where is the best service place?

Method

There are three methods to solve this challenge: the content-based method, the service library method, and the backend replication method.

Content-Based Method

This method sends the received service request to the correct record system. This solution allows service consumers to see service places transparent: algorithms determine that service consumers do not know where a specific service is provided. When a request is given, the record system support service is packaged as a logic body.

Figure 4. Content-Based Method

Figure 4 illustrates a content-based method example. In this example, the consumer information is isolated by region. Consumer information in a specific region is stored in a database in a specific region of the data center. However, service consumers in any region can access this information. After receiving a service request, the consumer configures the service to execute a commercial rule to determine the region in which the information useful to the consumer is stored. Then, the consumer configures the service to send the request to the located region.

Service library-Based Method

The above describes a change based on the content method, which is displayed in Figure 5 based on the service library method. When a consumer configures a service to execute the same commercial rules as the content-based method, it coordinates the service configuration information to direct the service request to the correct region. This method makes it easier to change the service request sending logic when necessary. By changing service configuration information, service requests can be easily sent to different regions without changing the business rules of the service.

Figure 5. Service library-Based Method

Backend replication method

This method coordinates the internal interaction application connection capability to access the physical database containing the specified information. In this way, each record system can access information distributed on the system like a logical interface. This service can be executed on each record system. The physical location of the operated data is transparent to the service itself. Figure 6 shows a method for copying back segments. The same consumer configuration service is executed in a record system close to the service. When the information of databases in other regions is requested, the internal data replication capability provided by the database technology can support obtaining relevant data.

Figure 6. backend replication method

Service scope definition

Challenges

Services are classified by logical region to reduce the number of components and simplify the structure. For some structural reasons, these groups can be coordinated: load balancing, access control, proxy simulation, and vertical or horizontal business logic. However, there are often a series of challenges for business departments and technical centers in an enterprise to be consistent in defining a correct scope of service. What is a good service scope logical group?

Method

You can select multiple methods to define the service scope. Table 1 shows an example of cross-business application and platform classification. This example describes the important features of each method discussed in this section.

Main intermediate layer platform applications of commercial departments
 
Home Loan UNIX SAP
 
Online Banking windows Siebel
 
Financial Center UNIX lelesoft
 
Insurance Service Windows SAP
 
Personal Loan Linux Oracle
 
Enterprise loan unix ibm DB2

Function Scope

The function scope is based on the commercial functions of a specific service set. It is best to arrange the business process owner in the enterprise to define and isolate business functions and the corresponding service scope. In this way, the business process owner of a specific scope can control the services in this scope. As long as the business process owner is confident that the services within their respective scopes are also provided to other enterprises, they have full control over the architecture and application of this service.

In the preceding example, there are three functional services: Loan, finance, and insurance. Services in these fields must span multiple platforms and backend applications to process requests in their fields. However, these business processes make similar in a specific field, regardless of the applications or platforms that execute services.

1. Loans. Loan coverage services are clearly included in the release and management of loans to consumers and enterprise users. This service area includes housing mortgage loans and loans for goods that are purchased with other values equivalent to housing. Services may include lending, installment repayment, and interest calculation.

2. Finance. Financial coverage services are clearly linked to finance through a large number of media, including networks, ATM, vru and financial centers. The service may include opening an account to query the transfer between the account balance and the account.

3. Insurance-covered services only include services for the insurance industry. The service may include insurance fee calculation, medical history search, and complaint handling.

Based on technical scope

The functional service scope that spans multiple technical platforms makes the internal challenges that keep pace with each technical platform always exist. Vendors strive to reveal industrial standards in one way to support their solutions and enable companies to rely on their architectures, hardware, and software. Technology-based service scope specifications allow efficient use of specific technical capabilities.

In this example, the service scope can be classified by UNIX, Linux, and Windows platforms. Basic services such as error records, transaction monitoring and time processing are good processing objects for such services. They rely on the operating platform, but are independent of the commercial processes that drive the scope of this function.

Based on Application Scope

As a method to help enterprises face the needs of updating existing systems, the concept of enterprise application integration emerged. Nowadays, enterprises have a large number of front-end application systems, so they need to integrate these similar systems to process, package, and propose the same data in different ways.

A specific system is allowed to provide group services based on the application service scope. This method makes it easier to manage and maintain services, because systems in one domain are the same for all services.

In the above example, SAP, Siebel, PeopleSoft, ibmdb2, and Oracle are both good application-based customers. Some typical services in these scopes are listed below.

SAP

● Account payment-account reconciliation

● Financial computing

PeopleSoft

● Add employees

● Update Compensation

Oracle

● Data Replication

● Role Description Based on account information

Service Packaging

Challenges

In SOA, an enterprise system must focus on services. This can be easily achieved by an integrated constructor. The structure-oriented system has some difficulties. These systems are constructed by some integrated circuit applications, including all commercial rules and process logic. This information is assigned to a set of multiple connection programs.

An SOA supports independent services-without any knowledge about other services. Structured programs are closely associated with specific contexts. How are these structured programs once again surrounded by independent services?

Method

We can use a three-step approach to address this challenge. This approach involves defining logical business areas in an architecture scheme, assigning an assembly to these business areas, and loosely coupling associations between the two sets. These steps are described in detail below:

1. Define the business domain. In this step, we create a logical domain for commercial functions. We can use the program call planning diagram and process flow diagram to define these business areas. We can also define the business field by adjusting the inter-program relationship of the architecture system. [The program of the architecture system is often related to other programs. There are some common commercial methods in the relationship between such programs and programs.]

2. Program allocation. In the standard business field, we allocate independent programs to a specific field. We need to reallocate programs that do not relate ourselves to the corresponding business areas, so that they can be arranged in a specific business area with more rules. Under the guidance of the service scope concept discussed earlier, such an assembly can be better arranged.

3. Loosely Coupled Association. At this point, even if these programs have been arranged in the standard business field, they need to be associated with each other. In the last step, we replaced the original mild coupling association with a more loose coupling. To do so, we redefine the architecture program interface so that other applications can adjust themselves; the program provides the same output and accepts the same input, just as they started to do. This redefinition process provides a great opportunity to ensure that these programs serve the enterprise as a whole, rather than a single program independent service enterprise-just as they were initially created. This method also brings the existing architecture systems closer to the service-oriented, and configures them to make them an internal structure system, while the external architecture is service-oriented for service users.

Service Coordination

A specific service exists because at least one service consumer sends a request for this service. However, in some cases, a service has to call many other services to satisfy the original request of the service consumer. In simple cases, a specific service expands the original request to one or more other services. However, complicated situations can lead to a large number of recursive calls to services. In some extreme cases, the internal dependency calls of some services can lead to an endless loop.

Here is an example. When a ticket is sold, the following services must be executed:

Consumer acquisition

Get calendar

Check available information

Provision cost

Accept payment

Build coordination capabilities so that every service can be smoothly executed in such complex circumstances

7.

Figure 7. service coordination challenges

How are these integrated services coordinated?

Business Process Management Methods

This method simplifies independent services: these services are not capable of coordinating other services called to satisfy requests.

Alternative, this capability is placed on the business process layer. The business process is responsible for calling each sub-service to provide the combined service to satisfy the original request of the consumer. The business process becomes a professional example of service composition.

Figure 8. Business Process Management Methods

Figure 8 illustrates the business process of this ticket purchase, including every independent logical step. This business process looks for services through a simple access, and then coordinates in order for appropriate steps.

Service sending

Challenges

SOA also provides regional transparency to consumers: service consumers must be able to send any service request within any service range. At the same time, it is a time-consuming step to access the service database before calling a service. How can these architectures provide regional transparency while ensuring acceptable system performance levels?

Method

We can solve the challenge of sending services in two ways.

Smart services

In this way, we build our own region information for all services. This eliminates some jump requests and also causes service overloading. This method is persistent considering the update frequency of services and service locations. In addition, this method is not consistent with the loosely coupled service architecture at all times. However, he supports a higher-level execution solution.

Send

Another way is to move sending from a sending component to an independent service. These sending components can be in two levels: service domain and service.

1. Sending a service domain. A service domain can be sent intelligently in all service domains. When a request is received, it determines whether it can satisfy the request by its own service. If yes, It processes the request. If not, it sends the request to the correct service that can satisfy the request.

2. Service sending. A service is called within the scope of a service, and requests are sent to the correct service within the domain. Only requests that can satisfy the service in the domain are delivered to the service. Service sending reduces the load of information on various services.

Service domain sending and service sending are more practical for service domains that include a certain number of services. Smart services are a viable option for those services.

Figure 9. service domain sending and service sending

Figure 9 illustrates the concept of intra-domain service domain sending and service sending.

Service Management

Challenges

No matter how an enterprise defines a service domain, there are several philosophical and technical methods to create new services or modify existing services. Who will monitor, define, and manage changes to existing services in the Enterprise?

Method

An enterprise can establish an internal management body to better cope with this challenge. A large number of management models are possible. The following are some examples.

Center Management

Through central management, the management bodies in an enterprise are explained from each service domain and the parts that do not directly depend on each service domain. It must also be noted from different business departments and some event handling experts who may express their views on key technical components of the solution. The central management body is like a complete review after a service is deleted. It also includes changes to existing services before they can be executed.

Figure 10. Central Management Model

As shown in figure 10 above, the central management body relies on the guidelines and standards for enterprises to establish and implement SOA. It also relies on communication with other business departments, architecture groups and technical groups through these standards.

Distributed Management

Through distributed management, each business department can independently control how to provide services within its own organization. Distributed Management requires a functional service method. A Service Architecture Committee can still provide high levels of guidelines for service implementation, but it does not have to approve adjustments to the existing service architecture within the business unit. The Committee may recommend consistency with the guidelines, but cannot force such a process.

Figure 11. Distributed Management Model

11 as shown in the distributed management model, business department a and department B have the right to establish their own independent standards. However, appropriate passive standards (Architecture and procedural standards) are all waiting for the Department to comply with the appropriate positions.

Use of service communication standards

Challenges

For vertical industries, communication standards are different, which leads to standards based on a Data Element Set and communication mode. However, at an independent data element level, these standards are flexible and enterprises can adapt to them to stay consistent with specific business restrictions of enterprises. In this way, different business departments in the same enterprise can be consistent with the unified standards in different ways. In addition, these standards also provide the creation of customer data elements.

For example, the ifx standard identifies multiple methods for a customer:

<Customer Unique Identifier> the internal database uniquely identifies a consumer.

<Customer Login identifier> the account used by the consumer to log on

Both fields are unique. When adopting the ifx standard, enterprises must determine the time and location of each domain. Sometimes, the consumer even decides to ignore these two identifiers and re-create a customer domain. This customer domain is more suitable for the enterprise record system!

How can enterprises choose a separate standard?

Metadata Management Method

Enterprise metabases support reliable descriptions of key commercial entities. These descriptions are an extension set of information distributed across multiple enterprise systems. Data Dictionary, that is, logical and physical data models, is the key input for definition and maintenance of metabases.

The metadata management group should be a centralized group in the central management model discussed earlier. Metadata management must be performed at the enterprise level. In other words, even if an enterprise chooses a Distributed Management Model to maintain the service, it must select a central management model to support metadata.

In the preceding example, the consumer metadata includes a simple identifier, which is unique. In addition, metadata should ensure that the description of management information is maintained, including the login account and password. Therefore, even if an enterprise has selected a unique identifier for the consumer through a customer domain, this customer domain must be described in the metabase.

Conclusion

Like chunlei, SOA has been quickly accepted by the IT industry. It helps enterprises build and deploy services in a modular way. However, the actual application of the architecture needs to be carefully planned. Enterprises of interest must first determine their long-term application and support for SOA.

By developing and developing a road map for implementation, enterprises can cope with a series of challenges they will encounter in advance. Each enterprise will face a unique set of challenges, and the corresponding methods for coping with these challenges are also different. The impact of these challenges-in execution and after execution-also depends on the environment of these specific enterprises.

 

 

Address: http://tech.sina.com.cn/s/2009-07-27/10491000356.shtml