Section 17.3. Technology

17.3. Technology

Having discussed the implementation aspects of the project, we now want to take a closer look at the actual technology employed. This discussion will cover the technical architecture, XML service definitions, and technical infrastructure.

17.3.1. ARCHITECTURE

The technical architecture of the IF.com system required the integration of a wide range of heterogeneous technologies. The banking engine in the Mid-Tier is implemented based on Java and BEA WebLogic. The Web Channel (Web server to render HTML pages) is based entirely on Microsoft. This is due to the fact that IF already had a security approval for this Microsoft-based architecture based on their first-generation online bank. Call center and IVR (Interactive Voice Recognition) are based on the Genesys CTI suite, using customized C and C++ on Unix. In the backend, a variety of mainframe, Unix, and NT systems had to be integrated. Figure 17-6 provides a high-level overview of the technical architecture of the system.

Figure 17-6. Technical architecture of IF.COM.

17.3.2. SERVICE REPOSITORY, SERVICE INTERFACES, AND CONTRACTS

As we discussed previously, the IF.com service architecture is divided into two main layers: a number of basic services in the backend, and a central service in the middle, which is a mixture of an intermediary and a process-centric service. All services are "hard-wired" through configuration filesthat is, there is no explicit service registry. Given the nature of the project (all services are controlled by the same project), this approach makes sense. The following describes the service operations and contracts of the banking engine service and the basic services in the backend.

17.3.2.1 Basic Services

The basic services implemented by the Intelligent Finance system are based on a number of very different technologies, ranging from CORBA to DCOM to XML and MQ Series.

Interestingly, Halifax itself started to develop a Service-Oriented Architecture for its mainframe-based core banking system, which was also used in the Intelligent Finance project. The so-called message switch for the Halifax mainframe is based on XML and MQ Series. A technique similar to the one described in Chapter 3 is used to simulate synchronous service operations by using message correlation to group matching requests and responses together.

17.3.2.2 Banking Engine Services

The IF.com banking engine is based on approximately 1,300 XML Schema definitions, 120 WSDL Web service interfaces, and 600 Web service operations. Halifax is now processing over 1,000,000 XML SOAP transactions a day. This makes Halifax Intelligent Finance one of the biggest and most successful Web services projects today.

The banking engine service is divided into a number of different namespaces, including Common, ContactCentre, Workflow, OpenAccount, PersonalAdvisors, QuickQuote, and Service Request. The OpenAccount namespace, for example, includes service interfaces such as AddressMgr, ApplicationMgr, BroadRequest, OfferEngine, CreditCardApplication, CurrentAccountApplication, and so forth. The OfferEngine includes, for example, XML Schema definitions such as DebtType, MortgageProductDetails, and MortgageOffer. The OfferEngine service interface provides operations such as renegotiateMortgageOffer(), getMortgageOfferAcceptance(), and so on.

In general, the granularity of service operations is closely tied to the granularity of screens used by the Web channel and call center channel.

The banking engine service runs on a standard J2EE application server, using session beans to implement service interfaces. To support the SOAP runtime protocol, a WSDL compiler and code generator was used. For example, it is able to generate Java skeletons that accept incoming SOAP messages and dispatch them to the Java session beans (refer to Figure 17-6). The same tool was used to generate VB client code (for the IIS-based Web servers) and C++ client code (for the CTI product that provided computer telephony integration for the call center). Obviously, today this functionality would be available out-of-the-box for most programming platforms, but in 1999/2000, XML Web services technology was just emerging, and therefore proprietary compilers were developed to support early version of the WSDL and SOAP specifications.

17.3.2.3 Service Versus Service Interfaces

Recall our discussion on different service types in Chapter 5. One of the key messages was that data ownership amongst services has to be clear and that different services should not share access to the same data (see Section 5.1.3.1). However, as discussed in Chapter 4, one service might have multiple interfaces that provide shared access to the data owned by the super ordinate service. In addition, the code base of independent services should be structured in a way such that there are no cross-dependencies between the different service implementations. If we apply this definition to the Intelligent Finance situation, it becomes clear that the banking engine really represents one large service with multiple interfaces but not multiple independent services. In effect, this has created a somewhat monolithic service, with some disadvantages. In the Intelligent Finance case, the key disadvantages are dependencies of the code base behind the different service interfaces: these dependencies complicate the maintenance of individual services because work cannot easily be split into individual tasks. In addition, relatively complex test environments are required. If the different service interfaces were truly independent services, much less complex development and test setups could be used.

Intelligent Finance has recognized this challenge and has significantly invested in the breaking up of the monolithic service architecture into services that are truly independent on the code as well as the data level. The resulting more loosely coupled service design has helped tothe s significantly enhance maintenance productivity and the ability to introduce new functionality much more quickly.