Section 16.3. Technology

16.3. Technology

This section describes in more detail the technology used to construct the SOA at Credit Suisse. It comprises a sketch of the architecture used to implement the information and event buses, an overview of the repository structure, the contracts and the service interfaces, and a summary of how security, workflows, and management are handled.

16.3.1. ARCHITECTURE

As we mentioned earlier, the integration architecture deployed at Credit Suisse combines three different integration paradigms.

Whereas the Credit Suisse Service Infrastructure provides synchronous communication and is used for providing frontend access to host applications, the Event Bus Infrastructure (EBI) uses asynchronous communication to integrate new non-host applications. Finally, the Bulk Integration Infrastructure uses file transfer for communication.

16.3.1.1 Synchronous Integration with the CSIB

When introducing the Information Bus, CSG began with an initial structuring of the existing applications, which was achieved by partitioning the applications into approximately 20 domains (refer to Figure 16-1) where an application domain combines all data and applications belonging to a certain business area. Figure 16-7 shows how applications are encapsulated inside domains. Whereas coupling is tight within a domain, it is loose across domains where coupling uses the information bus.^[4]

^[4] The concept of a domain at CSG is largely similar to the notion of service in this book. The approach taken by CSG is somewhat similar to the approach laid out in Section 10.2.1, "Service Enablement," and depicted in Figure 10-4. However, CSG decided not to make an effort to refactor any logic within the domain or between domains, where communication was not through one of the service buses. Thus, the actual applications remain in fact tightly coupled, even if the service interfaces might not expose the coupling to the client. Over time, replacement and upgrades of the underlying application and changes in the inter-domain communication models might facilitate an adoption of decoupled infrastructure without any significant impact on the already existing service clients.

Figure 16-7. Partitioning of applications into domains, which are loosely coupled.

The CSIB was first implemented using CORBA technology. Figure 16-8 provides a detailed overview of the initial architecture (which did not include the Event Bus) and the respective technologies used for the different layers.

Figure 16-8. Initial implementation of the Credit Suisse Information Bus.

As an alternative to CORBA, DCE and DCOM were evaluated but discarded. The integration of CORBA and EJBs used to implement the application frontends was built by Credit Suisse. Due to strict abstraction from the underlying technology, CORBA could in principle be replaced by another technology, such as Web services. So far, experiences with CORBA have been mainly positive, and it is still used in implementing new services.

16.3.1.2 Asynchronous Integration with the EBI

In 2000, when the Information Bus had been successfully introduced and had proven to be robust and scaleable, Credit Suisse decided to add a second integration platform. The basic idea was to address backend-to-backend application integration (within one domain or across different domains) with the same basic concepts that had proven successful when introducing the SOA and the Information Bus.

Credit Suisse calls its approach of adding an event bus to the Information Bus a generalization of the SOA toward a component-based architecture. They reserve the term "service" for the synchronous communication used in the Information Bus. However, the approach to SOA advocated in this book is much more generic and also comprises asynchronous communication as used in the Credit Suisse event bus.

As we already stressed, it is not so much the technology that characterizes a SOA as the general methodology associated with it. This is nicely illustrated by the fact that Credit Suisse "reused" all concepts developed in conjunction with the introduction of the information bus for the introduction of the event bus. Furthermore, CSIB and the EBI share the same service implementations, which facilitates the reuse of business logic and live data sharing beyond the scope of a single infrastructure, demonstrating that the CSG SOA is truly technology-independent.

The Event Bus Infrastructure is currently a message-based integration solution supporting topic-based routing and transformations. At the moment, it is not process-basedthat is, there are no workbaskets and no specific process layer. However, extensions in this direction are envisaged for the mid-term future (see Figure 16-9).

Figure 16-9. CSG's integration architecture comprising the event bus.

Technically, the EBI is based on message queues. The current implementation relies on products of IBM's WebSphere suite. WebSphere MQ (MQ Series) provides the reliable base for the transportation and storage of messages, while WebSphere Business Integration Message Broker provides facilities for message transformation and publish-and-subscribe.

Credit Suisse particularly stressed the fundamental importance of managed interfaces and contracts. These two key prerequisites for successfully decoupling applications are used rigorously by Credit Suisse for both the information and event buses.

In fact, the boards and processes for the event bus are identical to those established for the Information Bus. This is not limited to the abstract nature of the design and development process but also covers technical details. Thus, the service interfaces for the event bus messages are specified using IDL. Moreover, events and messages using the same type of information as an existing information bus service reuse the data structures already modeled for the service.

16.3.1.3 Bulk Integration Infrastructure

The Bulk Integration Infrastructure is the third type of software bus to be developed at CSG.

Figure 16-10 illustrates the interplay between the various CSG software buses. It already contains the third infrastructure component, which is currently under construction: a bulk integration infrastructure, which will be responsible for a consistent management of file-based data exchange.

Figure 16-10. Interplay between Information Bus and event bus.

Again, this third infrastructure component will reuse the same methodology as both the information and event buses. It is currently under development and uses conventional point-to-point file transfer. The goal is to establish a file broker to support a centralized control of the various transfers. This extension is currently in the evaluation phase.

16.3.2. REPOSITORY, SERVICE INTERFACES, AND CONTRACTS

The repository has been developed by CSG and contains information regarding design and management of services and events. For each service, the following information is available:

Service interface. The IDL interface specification of the service.

Properties. Specific properties of the service, such as effect on data (e.g., read, write), availability (e.g., public, private), and current status (e.g., test, production).

Planning. Information regarding dates on which tests have occurred or are planned and the date on which the service went into production.

Contact information. Relevant contact persons, such as developers, owner, designer, and/or client/user.

Implementation details. Information concerning the service implementation, such as modules and databases used.

Service conditions. A textual description of preconditions and corresponding post conditions guaranteed by the service.

Exceptions. A list of exception codes with brief explanations.

Service level. Information regarding the target response times (round trips) and expected requests per hour, day, and month (average and maximum).

Parameter descriptions. A detailed description of the in and out arguments of the service.

16.3.3. CHOREOGRAPHY, SECURITY, AND MANAGEMENT

The SOA implemented at Credit Suisse does not incorporate complex SOA solutions for choreography, security, or management.

Workflow components are only used for workflows involving human users. At the service level, however, there is no explicit process modeling in which service operations are orchestrated into complex workflows. CSG's SOA can be classified as networked with respect to its expansion stage (see Chapter 6, "The Architectural Roadmap"). Credit Suisse closely monitors the growing functionality provided by application servers in this area and is considering the integration of service composition and workflow modeling for future enhancements of its SOA.

CSG uses the mechanisms based on optimistic logging that are depicted in Chapter 8, "Process Integrity," to implement distributed transactions. If an operation of a logical transaction fails, logged information is used to trigger compensating actions. These compensations reverse the effects of already executed operations of the same logical transaction. There are no ACID transactions across the boundary of a domain.

The security solution employed at Credit Suisse is based on PKI (Public Key Infrastructure). The PKI solution is used for internal integration only at the moment. External integration currently operates using dedicated connections. However, a PKI solution for external integration is under construction, although this type of security is more suited to current enterprise application landscapes (see Chapter 9, "Infrastructure of a Service Bus").

To manage the distributed services and the underlying infrastructure, a wide variety of tools are used. Special CORBA tools support general system management. In addition, Credit Suisse developed tools that access and process data stored in a central logging component. This logging component contains detailed information regarding executed services, including information on data input and output during service execution.