6.5 Cross-Enterprise Integration Framework
6.5 Cross-Enterprise Integration FrameworkAn integration framework is essential to define different integration tiers and basic components or enabling technology for enterprise and cross-enterprise integration. It also outlines how each integration tier communicates with the other. The integration framework does not build on top of existing EAI vendor products. It can mix-and-match implementing any EAI vendor products with Web Services technology. There are five different tiers of integration that need to be considered . Figure 6-1 provides a sample scenario where a user accesses Web Services functionality provided by a series of legacy back-end systems to perform a fund transfer. A client user has a unique network identity using a digital certificate with a user id and password to access business services from a number of Service Providers. The client user performs a Single Sign-on using his Network Identity (step 1), where his credential is authenticated against a series of PKI infrastructure and Directory Servers under a federated identity management environment. This process will invoke the authentication and the associated entitlement services to determine whether the client is a valid user, and whether he is authorized to access the fund transfer service (step 2). All client requests for the fund transfer Web Services are represented in SOAP messages, which are carried over HTTPS in this scenario (step 3). SOAP messages can also be carried over other data transport, such as SMTP or FTP. The legacy back-end systems are wrapped as XML-RPC Web Services using Java Connector Architecture. Chapter 5, Mainframe Integration and Interoperability, discusses the details of how legacy mainframe systems can be wrapped as Web Services using XML-RPC. Upon receipt of the SOAP service request, the server-side SOAP component (SOAP tier or skeleton) will then invoke the remote back-end mainframe system functionality via XML-RPC (step 4). The Java Connector is a J2EE-based integration technology to connect the Web Services client request to the back-end legacy mainframe systems (step 5). The client user has a synchronous Web Services session to retrieve account profile, perform account balance enquiry, and transfer cash from one account to another account. There are complicated back-end business processes that require sophisticated business process collaboration and monitoring. The "fund transfer" processes are being managed by a workflow rule engine and an Integration Manager hosted by the financial portal Service Provider (step 6). All workflow processes are being monitored with all transactions logged for audit purposes. Figure 6-1. Integration Framework 6.5.1 Security IntegrationThe notion of Network Identity is to provide a unique identity for accessing business services over the Internet, where users just need to sign on once for multiple Service Providers. Sometimes, this is also associated with Single Sign-on (SSO) technology. Network Identity often assumes the use of security tokens such as X.509v3 digital certificates or a Kerberos ticket with Public Key Infrastructure. The Network Identity process will also retrieve the user profile and access rights from one federated Directory Servers and validate against the credentials. SAML (and its extension), under the Project Liberty specification, may be used as the underlying security messaging specification. The client requester will initiate a SAML access right assertion to the federated Directory Servers. Upon successful validation, the client requester will be granted access to the authorized business services stored in the user profile. 6.5.2 Data Transport IntegrationSOAP over TCP/IP is the underlying messaging transport. It can be carried over HTTP, HTTPS, SMTP, or FTP. The SOAP 1.1 specification defines SOAP over HTTP. For SOAP-SMTP and SOAP-FTP binding, developers need to write their own provider class for the SOAP bindings. 6.5.3 Middleware IntegrationThe integration framework allows multiple middleware integration options with the back-end systems. Typically, middleware products can communicate with the back-end systems using Java Message Service (JMS). If there is a need to communicate between the client and the back-end systems using two middleware products, even though they may be using JMS, they still require a JMS bridge that binds JMS to the underlying data transport such as SOAP. This is sometimes known as SOAP-JMS binding. With Java technology, developers can also use COM (for example, using a Java-COM bridge), CORBA (for example, using RMI-IIOP or a Java-CORBA bridge), and Remote Procedure Call (or RPC, such as XML-RPC). Using Web Services technology, either of these middleware integration options will use SOAP over HTTPS as the transport. This decouples the middleware from the data transport integration, making interoperability easier. 6.5.4 Data IntegrationAt the data level, business data objects that are encapsulated in existing relational databases can be accessed and retrieved by XQL (XML Query Language or SQL-like XML notation). If the data are persisted in proprietary format and a customized adapter has been built, then developers may wrap the customized adapter as Web Services functionality. At the presentation level, if data need to be transformed, developers can use the XML Style Sheet Processor (XSLT) to translate and render data into another format, such as delimited text, proprietary text format, or PDF. Legacy systems data can be also accessed using the Java Connector Architecture (JCA). Developers can also build custom JCA connectors using an off-the-shelf JCA connector software development kit or Java class library. 6.5.5 Process IntegrationUsing an EAI product, complex business processes can be modeled as Process Models with a Workflow Rule Engine and an Integration Manager. Process Models are an encapsulation of a series of actions, where specific actions will be taken if certain events take place. The Workflow Rule Engine manages a list of business rules defined to describe and execute predefined Process Models when different events take place. To monitor the current or historic events, Process Model actions, or which business rules are fired , we need to administer them by a Process Monitor for performance and audit purpose. Table 6-3 summarizes the integration components and enabling technology by tiers versus layers. You will notice that certain components span different tiers and platforms. Therefore, it is important to remember that enterprise and cross-enterprise integration covers components by components, across tiers and layers . This does not stop at any component level. Table 6-3. Integration Framework Components by Tiers Versus Layers
6.5.6 How to Use the Integration FrameworkIn order to utilize the integration framework, architects and developers may wish to define their integration requirements and map to the five tiers of the integration framework. Then they need to identify their integration approach and model and consider reusing any existing B2Bi integration patterns (refer to the next section). Always customize and adapt your integration methodology for each business case. To customize the integration architecture, architects and developers may wish to start with Use Case modeling. Remember to be customer-centric. Always consider reusability (for example, build a library of repeatable services, codes, and integration tools) and how to lower Total Cost of Ownership (TCO). Place the big picture first, and do not focus on the interfaces or APIs yet. Integration design also needs to cover many aspects of security, processes, data, and business services. Wherever possible, always decouple transport from the message contents or structure. 6.5.7 BenefitsWith a comprehensive integration framework, architects and developers can customize their own structured processes and methodology, which can reduce technology and implementation risks. They can focus on their success, as they may find it easier to set their priorities on the critical integration areas. The integration framework also provides a reusable structure to customize and fine-tune the customer's integration architecture. This sets the big picture or blueprint for its target architecture. The technology options are Open Standards compliant, which eases future extension and interoperability. The integration framework also comes with some best practices that describe when to use specific integration patterns.  |
