British Telecom Design Mode Best Practice - Hierarchical SOA Architecture
Author: Cui Xiaobo BEA Systems (China) Co., Ltd. Senior Technical Consultant
Typical Enterprise SOA platforms connect to many companies to apply resources and users, and can divide the enterprise to apply resources into two types of service providers and service consumers. Good management results can be obtained by dividing services into different levels. A service level is used to make the background system (BES) resource available, while another service level connection front-end system (FES) to the SOA platform, the third service hierarchy assembles the basic service of the first service level and connecting business users together Complex composite types. Similar service packet practices can effectively expound the characteristics of the SOA platform hierarchy. For each hierarchy, there are corresponding different technologies, development models, test devices, deployment configuration, and system management systems, and more.
First, hierarchical divided hierarchical architecture is the most flexible implementation method. Simply, SOA can consist only by basic access services. These access services are directly encapsulated by the set of interfaces provided by BES. However, this service does not meet the integration requirements of the most basic integrated project. In most practical projects, the logic of integrating different backend systems is required. This integration logic can also be seen as a set of services, this service has a good defined external publishing interface. These services are a higher level of service that utilizes a lower level of BES access service. These service implementations are ways to arrange or coordinate. Finally, most consumer applications for these higher level coordinated services or lower level access services in a business integration environment will not directly support the external service interface. Therefore, another set of services is required to be packaged to serve each FES. Therefore, the foundation of the layered architecture is proposed, as shown in the figure: there are three layers in this architecture. Each layer has a corresponding set of technical needs and roles. q Access service layer is responsible for issuing a group of BES interface as a standard service. Q Assemble the service layer to reset the service to implement integrated logic. q Consumer Service is responsible for enabling FES to access other two-layer release services, which typically FES cannot be called directly.
A separate enterprise information system (EIS) can perform one or both of the FES or BES roles, which can be exposed through access to the service, and the service is called through the consumer layer. Another important point is that any layer of service can be called by FES, you do not have to do it through all layers in the architecture.
(1) Access service layer Access service layer provides basic services called by the SOA platform. The center of the key architecture is a reuse of design and management services. Designing and Developing Access Services requires technologies such as WTC, JCOM, Web Service, etc.), Adapter Development Settings Technology, and Message Middleware Technology. The access service layer is a single interface by accessing the service released by the BEA, and the main goal is to achieve maximizing reuse on the platform. Other layers access these services via controls or through a publishing interface. Its simplest form is just a BES exposed through the control. For example, a J2EE connection architecture adapter (J2EECA) database adapter is installed and set to connect a special system and the service generated by each required SQL statement together. This can then be stored by integrating application view controls. What services belong to this layer? This layer mainly considers all published interfaces based on BES-based, not for each FES or the same level. A composite service that implements multiple calls to BES will be part of this layer. For example, in order to generate a user of a given BES, it is necessary to generate a user ID, then the username, and then the user address, etc. Each portion is used as a different call, then a "generated user" composite service will be bound to all of these calls. This composite is more convenient, a greater extent to reuse the services provided by BES. Overall, a process suitable for access will satisfy the following points: Q Just connects to the owner and service of a BESQ interface and BES together
(2) The assembly service layer assembly service layer is mainly functions that complete the delivery of new services, which are a reorganization of the access service layer. The main architectural characteristics of this layer are flexible. The assembly service layer achieves this flexibility by properly implementing data concentration, process definition, and workflow tools to create ideal services. Designing and implementing assembly services requires integrated business processes and rules, and has exported experts in data integration, process modeling, and workflow development. A variety of integrated logic is required in this layer, and it is released to become a complete service. This layer uses access to access to FES to provide meaningful service. What services need to include in this layer? Any service that utilizes more than one EIS system needs to be included in this layer. Services that implement people-oriented interacting through Worklist also need to be included in this layer. As described above for the access to the access layer, the services in some collaborators may only access one BES system. If these services need to complete the functionality that contains integrated needs, not just from a single BES system, they are also included in the collaboration service layer. A simple principle suitable for this layer: Any service that is not a consumer layer or access to the storage layer is a collaborative service layer. Independent data integration services, such as providing data conversion, data mapping, including primary key mapping, data dependent routing services require residing in collaboration layers. These services may not access the BES system by accessing access. (3) The main purpose of the consumer service layer consumer service is responsible for the connection between platform and application service requestors (such as FES system), this layer service provides: Q protocol mapping - mapping to service release interface protocol: JMS and Web SERVICES. Q Paradigm Mapping - Synchronize to Asynchronous and Vice-Versa. Q Data mapping - data format mapping, gathering, etc. Service requesters include applications based on a variety of architectures, as well as legacy system service requesters including fat clients, messaging systems, socket protocols, etc. A protocol interpretation service is generally required. For requestors that support platform protocols such as Portal, B2B services, multi-channel, Paradigm, and data formats can be directly interfaced with the platform. Integrating service requestors to the SOA platform requires rich knowledge of specific service requesters, and there is also a skill of data conversion. Which services should the consumer service layer contain? The consumer service layer recommends the services of specific access service layers and coordination service layers. The purpose of reassembly is to let the service can be called in a more convenient form, typically, if you pack a JPD process into a web service, just this. In addition, packing the Page Flow of a JPD to a portlet, or more convenient to make the front-end portlet system assemble and call. For example, a consumer layer service receives an event issued by a FES, but this event does not have sufficient information to call the corresponding collaboration layer, requiring the service layer service to complete the event, and query the function of the related information to the FES. This is a significant functional strengthen, which is suitable for consumer service. Of course, if this enhanced process needs to be queried to a separate system, it means a separate service of the requesting service layer after an integration process.
Second, the point-to-end view is worth pointing out that these levels are not enforced when examining end-to-end communication between the FES to the BES system. As mentioned above, the request service layer is only necessary when accessing standard interface technology for the SOA platform is required. If a FES itself supports the standard of the SOA platform, FES can directly access the services provided, and skip the request service layer. Similarly, for some simple integration requirements, such as querying the available data in the stand-alone system does not need to be reorganized. Of course, we recommend that the way we should never ignore access to the access layer, which guarantees that the various services provided by the BES maintain consistency and flexibility across the platform. It also avoids the emergence of skipping all levels of design scenarios, so you can guarantee the meeting management principles. Another point is worth mentioning. In an integrated scenario, many systems are both Bes and FES, and of course, some pure front-end systems (such as portal) and inherent backend systems (such as databases) are present. When two-way loosely coupled communications (such as using JMS), a two-way integration requirement can be converted to implement two unidirectional communication. This is an example of doing FES and BES systems in the same business process. Third, the service repository needs to establish a service repository to record information about the service, and you can achieve easy reusability between services between different projects. This resource library does not need to be an automatic runtime system (similar to UDDI), which is used for system reference for designing and development. This repository can be made in the form of a shared folder or rely on document management tools. The definition of services in the resource library requires least need to include the following services: Q service name and version. Q Service function and summary of intentions. Q function and non-functional needs. q The level of the service resides and the particle size between the hierarchies. Q Services Detailed interface description. Includes published and / or private interfaces, as well as detailed descriptions of interfaces such as URLs, methods, parameter types, and desired values and usage. Q Services owner. Refers to an independent individual or organization (more common situation) responsible for maintaining the service.
