Microsoft Corporation
1996
This white paper—part of a series of DCOM-related white papers—describes how Cariplo, one of the largest banks in Italy—uses DCOM in its Internet home banking application. This home banking application is currently being deployed with customers throughout Italy.
Cariplo S. p. A. is one of the largest banks in Italy. It was the first bank in Italy, and indeed one of the first in Europe, to adopt Microsoft® Windows NT® Server and Windows NT Workstation operating system over two years ago. It has also developed its new branch office system on top of the Win32® environment, which is a GUI and client/server-based application with 14,000 client installations in approximately 700 branch sites.
Once again anticipating the market, this year Cariplo chose to be the first bank in Italy to offer a home banking solution based totally on new Internet technologies and on Microsoft's integrated environments, including Windows NT, Win32, and COM/DCOM.
Providing a comprehensive home banking solution is a big challenge for various reasons.
These aspects in particular implicitly generate the need to develop a solution in a distributed environment where all system aspects, such as load balancing and hot backup of the computing on different server computers, are resolved.
Design and development of the system started in early 1996 and is currently in a limited, but production-quality beta. Due to these time-constraints, the choice of technology was limited to the following:
This document will focus primarily on the server-side architecture and the technologies applied there. For more details on client-side ActiveX—in particular, ActiveX controls, scripting, safe code download, and asynchronous monikers that proved invaluable in this project—please go to http://www.microsoft.com/activex/.
Cariplo's existing home banking solution for its customers offers users access to the same information and services available at branch offices of the bank. The system is directly derived from the bank's branch office system and uses a two-tier architecture. A simple MS-DOS® program running on the customer's computer links directly to the bank's host over a private modem connection. The client application interacts directly with the mainframe and thus reflects much of the mainframe specific presentation. The home banking system differs from the branch office system primarily by the fact that additional security gates provide extended protection against unauthorized access.
Both the home banking and the branch office systems access the same host environment that essentially consists of a CICS transaction system and a DB2 database. Communication to the host is based on SNA LU2. Each transaction has a corresponding 3270 form. Transactions can be initiated by passing the 3270 form or by explicitly passing the parameters of the transaction. Results of transactions, however, are always returned in a 3270 presentation.
One of the characteristics of the old home banking system was the scarcity on the client side. No enhancements had been made to the user interface, and the system interaction was in no way simplified. Customers were presented with the same user interface (UI) that was used by the bank's employees.
One design constraint resulting from the existing infrastructure was that the host environment could not be modified at all. Any changes would directly affect the bank's core branch-office system, which was beyond the scope of the Internet home banking project.
The primary design goals of the new home banking application can be summarized as follows:
The vision for the bank's information system includes the following general guidelines that were to be first implemented in the home banking system.
In order to handle the transition to a distributed three-tier environment, a new vision of the application architecture has been adopted. The main role of this new architecture is the clear separation of the application entity in three different areas of services:
Specifically separating the user interface services from the business services would allow different front-end technologies to be used, while sharing and reusing the same business services.
Please refer to the Microsoft Solutions Framework (http://www.microsoft.com/msf/) for more information on these and other valuable concepts and the best practices for distributed computing.
Another core element of the new vision is the focus on activities. Focusing the design around activities performed by the user—such as checking and stock portfolio management—provides an additional, object-oriented layer above transactions, which are used as building blocks to manage the relation between low-level entities such as accounts and users. Since the activities layer maps directly to actual business processes, the system can adapt easily to changes in the business process itself.
The home banking project did not include the realization of this vision on the host environment, which would have required a complete business process reengineering of all the information systems of the bank. The home banking project thus had to provide its own abstraction layer on top of the existing, unmodified transaction system available on the mainframe.
Since the business components in the activities layer would require different sets of transactions in ever-changing combinations, the home banking project relies on a set of custom infrastructure components that expose the mainframe transactions to the middle-tier business components. This communication layer bridges the gap between the forms-based transaction model of the host and the object-oriented, distributed programming model of the middle tier.
The third element of the new development vision is that of standardizing on the Microsoft Component Object Model (COM). The first two elements of the vision essentially breaks the application into logical elements, which can be reused and recombined to form new applications or modify and extend the existing application. The Component Object Model provides a programming model, binary standard, and interoperability standard, allowing the logical elements to become independent, binary components that can be flexibly deployed in different configurations and on different machines.
All new user, business, and data services are implemented as COM components. All existing business and data services on the mainframe are encapsulated as COM components to provide a homogeneous programming environment for the entire home banking application.
One example of the flexibility of this approach is the home banking project's integration with a Microsoft Money 97 front end. By replacing the user service components, the same business and data components serve an entirely different user-interface philosophy.
Standardizing on COM lets developers leverage all their existing tools and knowledge.
This section describes the software architecture of the Cariplo home banking solution that, based on the component object modeling view, is composed of many separate components that are implementing the different user interface, business, and data services.
From a technical point of view, the composition of the different components could easily be grouped by the location where they are implemented, which according to a traditional view of a three-level architecture is based on client, server, and mainframe computers.
Anyway, from a business perspective the real advantage of this architecture is not just the technical distribution of the overall computing on different heterogeneous computers, but it is the clear separation between the components that implement the business logic of the application and the components that handle the user presentation of the system.
This conceptual separation is the key aspect of the entire architecture that makes it possible to cover all of the vision aspects described above—deploy a high-performance, fault-tolerant, and flexible architecture.
Realizing the vision of COM-based programming, under the assumption that client and server only communicate over HTTP, requires some integrating infrastructure. Since the ActiveX server framework was not available for this project, a custom framework was used to leverage the advantages of COM as far as possible.
COM components on the client side (ActiveX controls) use URL monikers to retrieve custom data over HTTP. This allows efficient asynchronous access to arbitrary data, while maintaining a simple COM-based programming model. No low-level WinSock programming was required on the client side.
The core of the application was chosen to reside on the server side. Internet Information Server (IIS) was used as the link between the COM-based core application and the HTTP-based clients. IIS was extended with a set of high-performance ISAPI extension DLLs. The extensions did not contain any application specific logic but served merely as gateways between the HTTP protocol and the COM-based server components. Implementing the core components of the home banking system as ISAPI extensions would have reduced the flexibility in redeployment and also the reusability of the components.
All user service and business service components were thus developed as COM components that were called from within the ISAPI extension. The ISAPI extension merely passed the output of the server components to the client. The user service components used template definitions that were stored in an SQL Server™ database. These templates described the layout of each page by indicating the static parts and how the dynamic parts were to be generated. The schema used for describing those dynamic pages is comparable to a simple scripting language, which in the future might be replaced with ActiveX server scripting.
The data returned to the client could be dynamically generated HTML pages—custom binary data that is interpreted and displayed by the ActiveX controls on the client side or OFC-data for the Microsoft Money 97 front end.
As DCOM becomes available for Windows 95, the ActiveX controls on the client side can be modified to connect directly to the user and business service components on the server side using DCOM. This further simplifies the programming model and will allow even more of the user service components to be run on the client side.
DCOM can either be tunneled over HTTP or—for clients that are not limited by firewalls—can be used directly over TCP/IP.
The application accommodates two fundamentally different clients—Microsoft Internet Explorer 3.0 and Microsoft Money 97. The strict separation into user, business, and data services makes this easy. Unlike traditional client/server programming, part of the user services resides on the server.
The customer enters the home banking applications through Cariplo's home page. The home page provides the customer with choices between different major areas of the home banking application, such as checking or portfolio management. The application leverages the simplicity of the navigation paradigm wherever appropriate—for example, choosing between checking and an investment portfolio—while extending the page with smart ActiveX controls when more complex operations are needed. Entering checking transactions becomes easy with ActiveX controls that do parameter validation, provide smart defaults, and so forth.
This approach lets the development team focus on customizing the core tasks of the application, making them easy, intuitive, and robust for the user. Less critical parts can be implemented using HTML-based navigation, without the need for any custom development.
A typical page contains two ActiveX controls in two separate frames. The upper frame contains customer information such as name and account number, while the lower frame contains the actual transaction or a list of transactions. The controls interact with each other using Visual Basic® Scripting Edition that is part of the HTML page containing the controls. The controls also interact with the server over HTTP to dynamically and securely retrieve information and pass information to the server. All of these server interactions are performed through COM components (URL moniker) that are part of Internet Explorer, without the need of any HTTP or TCP/IP-specific programming. The same programming model that is used for the server components applies on the client as well.
Figure 1. Reconciling a checking account
Figure 2. Transferring funds to another bank
How do the client and server components work together? The following example demonstrates what happens when a customer requests the current balance of an account.
The customer browses to the checking page. This page contains an ActiveX control that is to request the balance for account "1234." The control forms a URL of the form HTTP://www.Cariplo.Com/activepages/checking.dll/Balance?1234, where checking.dll is the name of the ISAPI extension DLL; balance is the particular action or information that the client wants to access; and 1234 is a custom parameter for this action, in this case the account number requested by the customer. The ActiveX control uses the URL moniker to issue this request over HTTP to IIS.
The server receives the request and calls the ISAPI extension DLL, passing it the URL. The extension DLL parses the URL and invokes a COM component, with the parameters contained in the URL. The COM component queries a SQL Server database to the template of the results to be returned. The COM component parses the template and invokes other COM components to obtain the dynamic parts of the result. Once the resulting data is complete, the COM component returns it to the ISAPI extension, which in turn returns it to the client.
Templates can describe both textual and binary data, so both dynamic HTML pages and custom binary data can be returned using the same infrastructure. The choice of the COM component and the available method invocations are actually hard-coded in the ISAPI extension DLL for performance reasons and to simplify the parsing and generation of the templates.
As ActiveX server scripting becomes available, this mechanism can easily be replaced with a set of custom Visual Basic Scripting Edition or Microsoft JScript™ scripts.
In addition to the Internet Explorer–based client, the Cariplo home banking solution can accommodate Microsoft Money 97 as a front end. Microsoft Money 97 can connect through HTTP to the Microsoft Internet Server. Microsoft Money defines a common file format called Open Financial Connectivity (OFC). OFC is a text-based interchange format similar to HTML in that it is based on SGML.
The same mechanism of ISAPI extensions calling COM components is used here, but the template does not contain HTML fragments—it contains OFC fragments.
While the user service components are by definition HTML/OFC specific, the business service components are entirely independent from the actual representation of the results. The purpose of the business service components is to provide an abstraction of activities that bundle a set of mainframe and SQL Server transactions into a simple view for use by the user interface components.
The business service components were written as in-process COM objects in Visual C++® and use free-threading to achieve maximum performance and scalability. All processing is performed from within the process of IIS, thus requiring only extremely efficient in-process method invocations between user and business service components. However, packaging the components as COM objects maintains modularity and makes it possible to deploy the components in different processes for robustness considerations or even on different machines for scalability considerations.
The home banking application links into the existing mainframe system. However, it requires additional information—such as security credentials, access logs, and home banking–specific fees—that are simply not available in the mainframe application. Since one design constraint of the project was to leave the mainframe application unmodified, this data needed to be stored elsewhere. A SQL Server database was used for this purpose, and the integration between SQL Server and mainframe transactions was performed by the business service components.
The mainframe contains both a DB2 database and a CICS-based legacy application. The DB2 database is accessed through ODBC, just like the SQL Server databases. COM-based database access, such as DAO or RDO, was considered but not chosen due to the requirement of implementing the business components as free-threaded COM objects. The benefit of encapsulating ODBC as a custom COM component was outweighed by the cost. In the future, OLE DB can be used to further unify the programming model toward COM.
Access to the CICS-based mainframe application was encapsulated as a COM component. Since the mainframe application represents data as 3270 pages, a complete 3270 emulator was implemented as a COM component. Instead of providing a user interface, the emulator parses the pages, asynchronously handles the SNA LU2 session with the mainframe, and provides the information through well-defined and easy-to-use COM interfaces. The emulator uses the SNA LUA API provided by Microsoft's SNA Server to implement a LU2 protocol.
With this architecture, the business service components can use simple COM interfaces exposed by the emulator to initiate mainframe transactions and retrieve their results.
The SQL Server database contains critical application data unique to the Internet home banking system. In addition, it stores a replica of the mainframe data to make the implementation of the business components easier and improve the overall performance of the application.
A logically separate database on the same SQL Server stores the template information for the user service components.
Access to SQL Server is performed through the ODBC API.
The abstract architecture looks straightforward—user service components, business service components, and data services are cleanly separated. Different front ends can easily be adapted. Changes to business rules can be implemented by modifying well-known business components, and even the mainframe application is cleanly integrated.
However, the nature of the application requires additional thought to achieve good scalability—a potentially huge number of simultaneous users must be able to perform a high number of requests while maintaining fast response times. The design thus must allow the application to scale. It must be possible to add more server machines to accommodate more simultaneous users.
Because the user service components and the business service components do not maintain any shared states between invocations, it is possible to simply run multiple copies of them on different machines. Each machine runs IIS, the ISAPI extension DLLs, and the COM components implementing the user and business services. Users are dynamically routed to the different services by using DNS to resolve the same name to different IP addresses—each time a user connects, the DNS service assigns a different server.
However, users need to see the changes they perform on one server reflected immediately on all other servers. For example, it definitely must not be possible to transfer the remaining balance of a checking account twice.
Since this state is maintained in the databases on the mainframe and on the SQL Server, it is clear that these two elements of the application need to be shared by all the replicas of the business components. Fortunately, both the mainframe and Microsoft SQL Server are known to scale well even on single "machines."
The problem is thus to efficiently share the data services between different machines running replicas of the user and business service components.
Both the ODBC and the mainframe's LUA2 protocols are connection oriented—a relatively expensive operation establishes the connection. Once the connection is established, access is very efficient. In the presence of a potentially huge number of concurrent users causing a high throughput of requests, it is not possible to maintain a dedicated connection per user or establish a new connection for each individual request.
The solution to this problem is to implement a component that manages a pool of shared connections. The Pool Manager opens a reasonable number of connections. As other components require a connection, they request a connection from the central component instead of opening a connection themselves. When the components have performed their requests, they return the connection to the Pool Manager.
For the ODBC connections, this can easily be implemented through the use of an in-process Pool Manager running on each of the replicated servers. Each Pool Manager opens a fixed number of ODBC connections to the SQL Server and hands them to components upon request. Since all components share a single process, the ODBC handles themselves can be passed to the other components.
The mainframe connections, however, are a scarce resource. The infrastructure allows only a limited number of simultaneously open connections, which is not large enough to simply distribute them evenly among the replicas. The Pool Manager thus has to run on a central server and dispense the connections to all replicas upon demand.
Having chosen to implement the mainframe connections as COM components, it becomes straightforward to implement the Pool Manager as another COM component that simply dispenses COM references. With DCOM, the Pool Manager can transparently be accessed remotely, and the references it returns are transparently connected to the connection components on the central server.
The LUA connection component encapsulates a single connection to the host environment. It is implemented as in-process components and exposes a dual interface that offers the following methods:
The LU2 protocol requires permanent handling of protocol packets, even if no request or transaction is pending. The LUA connection component achieves this by creating a dedicated worker thread when the connection is first established using the Open method.
The Send method simply passes the request to the worker thread and returns. This asynchronous processing lets the client use the calling thread for other purposes, which further increases the scalability of the overall application. The client calls Receive when the transaction has returned to retrieve the result of the transaction.
The methods of the LUA connection component are designed to be accessed remotely and are written such that high-level languages such as Visual Basic can easily use the functionality.
The LUA Pool Manager controls access to a set of LUA connections. When the Pool Manager is first created, it obtains its configuration information from the registry. The configuration indicates the number of connection objects, the name of the remote LU of the system to which to connect, the names of the LUA connection to be used, the login script that must be executed during the logon process, and so forth.
The Pool Manager creates the LUA connection components in advance, initializes them appropriately, and stores a COM interface pointer for each instance in an internal array-like data structure.
Managing the pool
Clients request a connection component from the Pool Manager, which performs the transaction operation and returns the connection component.
The Pool Manager exposes an interface for this purpose, which essentially consists of three methods:
The Pool Manager stores references to the previously created connection components in an array-like data-structure. The references are simply COM interface pointers. Each connection in the array is tagged with the current state of the connection. A flag indicates whether a connection object is available or in use.
The GetObject method simply retrieves the next available connection, marks it as being used, and returns the interface pointer to the calling client. If no connections are available, the call blocks the calling client until another client releases a connection. The client receives a direct reference to the connection component and can freely use it to issue one or more transactions and retrieve their result. The Pool Manager component does not get involved until the client calls the ReleaseObject method. The ReleaseObject method simply marks the connection as available.
For performance reasons, the Pool Manager—as well as the connection component—was developed in C++ using COM's free-threading model. Since in this model COM does not perform any serialization of calls or protection against re-entrancy, both components protect critical data structures through Windows NT synchronization primitives, such as semaphores, events, and critical sections. When the GetObject method waits for a connection to be released by another client, it simply blocks the thread on a synchronization object and gets unblocked as soon as a connection becomes available.
If a client encounters a problem while using the connection component, it has to call the ResetObject method, which simply marks the connection as inconsistent and returns. A background thread then releases the inconsistent connection and establishes a new one. This guarantees that under no circumstances are clients blocked by lengthy LU2 or host transactions, unless they really require a specific result.
The same background thread also performs cleanup of connections that are not returned by clients. This cleanup is triggered periodically at a configurable interval.
Distributing resources
The Pool Manager itself does not implement any network-specific functionality. All it does is handle COM interface pointers and creation/release of instances of the LUA connection components. Even the LUA components are in-process components.
How can multiple clients on different machines access these connection components? The Pool Manager is a COM object and is simply configured to allow remote access to its interfaces. The DCOM configuration utility simply assigns the correct launch and access permissions.
When clients call the GetObject method, DCOM transparently converts the reference to the connection component into a remote reference, which the client can use just as if it were connected directly to the component.
To achieve a connection for all clients to the same running instance of the Pool Manager on a machine, the Pool Manager implements a custom class factory, which simply returns the same reference for all calls to IClassFactory::CreateInstance. Clients can simply call CoCreateInstance (C++) or CreateObject (Visual Basic).
Administering the pool
The Pool Manager component is critical for the home banking application and needs to be monitored and dynamically reconfigured. For this purpose, the component exposes a separate interface, which is also implemented as a dual interface.
This interface is used by a "Pool Explorer" application implemented in Visual Basic that monitors the state of all connections in the Pool Manager. With DCOM, this simple client application can run on any machine.
Performance and scalability were major issues when implementing the architecture. DCOM helped glue together the host environment and the COM-based middle tier.
Another major aspect of the home banking application was security. Users should only have access to the information that they are allowed to see. The system had to guarantee that no unauthorized access was possible.
The main entry point to the application is through IIS. The home banking application used SSL to authenticate users. The ISAPI extensions simply retrieve the authenticated user name and pass it to the business components, which use it to validate access based on the custom information store in the SQL Server database. In the future—when the components on the client-side connect to the server components using DCOM—security will be further simplified by allowing the business components to actually impersonate the client. Access checks can then simply be performed using the highly optimized access check mechanisms available in Windows NT. These access checks are implemented in SQL Server and can also be applied in the LUA connection components to further increase security in the middle tier.
In addition to the security provided by the secure communications channel, custom passwords are required for critical user transactions. And in addition, the information returned to the ActiveX controls on the client-side is also encrypted using a custom encryption mechanism.
Dividing the network into different zones, which are protected by routers and firewalls, complements the access control implemented at the application level.
Internet Information Servers are protected by firewalls that only permit access to the ports and addresses required by the home banking clients. The SQL Server database and the LUA components run in a separate zone to which Internet clients do not have access. Lastly, this second zone is again protected from Cariplo's intranet by another set of routers.
The vision of implementing the application using a three-tier architecture with a focus on user activities and based on COM and DCOM paid off for the Cariplo home banking project.
In the future, DCOM can be used to further integrate the client-side components into the distributed application. Instead of passing serialized data over HTTP, the client-side components can communicate directly with the business components on the server. User authentication can transparently be propagated to the database and LUA components, further increasing the overall security of the home banking application.
For the latest information on Windows NT Server, check out our World Wide Web site at http://www.microsoft.com/backoffice or the Windows NT Server Forum on the Microsoft Network (GO WORD: MSNTS).