Section 15.3. Technology

15.3. Technology

This section provides more detail about the technologies used to implement Winterthur's SOA and the e-Platform. Winterthur's host applications had been mostly developed in PL/1 and COBOL, and most program maintenance still requires PL/1 and COBOL (IMS and CICS on z/OS).

15.3.1. ARCHITECTURE

Figure 15-7 shows the different architectural issues to be dealt with in the technical part of an application specification.

Figure 15-7. Technical part of application specification.

Figure 15-8 provides a detailed overview of the e-Platform's internal structure. It consists of HTML, Web services, Java clients in both Internet and intranet, secure proxies screening high-level communication protocols at the entry of the Intranet, Web and application servers, and enterprise information systems.

Figure 15-8. Internal structure of Winterthur's e-Platform.

A key concept underlying Winterthur's SOA and its e-Platform are blueprints. These blueprints are reusable reference architectures that propose standards concerning how business components can be distributed and integrated. They specify technical aspects of platform-specific environments, components, and protocols for various distribution patterns.

Figure 15-9 contains two sample blueprints, one employing a remote communication between an EJB and a CORBA service, and the other using a local communication between an EJB and a domain service implemented in Java.

Figure 15-9. Sample blueprints for Winterthur's e-Platform.

The e-Platform contains blueprints for Java Clients, Servlets, EJBs, CORBA, Message-oriented middleware, Database connectivity and File transfer.

15.3.2. REPOSITORY, SERVICE INTERFACES, AND CONTRACTS

The repository contains two main types of information: the descriptions of the enterprise data elements at the level of attributes and the specification of services (see Figure 15-10). The data element descriptions are reused for the database definition and for the definition of the parameters within a service. All data elements must be approved by a central unitthe data management team.

Figure 15-10. Service definitions are based on enterprise data element definitions.

The application service team uses these data elements to define, in close cooperation with the respective service owners, the detailed service specifications. Data elements and service information are accessible for all developers using browsers within the Intranet.

So far, the focus of Winterthur's SOA development has been on synchronous services offering a request-reply function. These services provide IDL interfaces and have been implemented as CORBA services. It should be noted, however, that the contracts are modeled independently of CORBA and are thus platform-independent. Currently, a second type of service is under development that will offer message-type functionality.

The idea is to use WSDL for a protocol-independent service definition and implementation. The following list contains some of the information that is included in the service contracts and available through the repository:

Service description. Provides a high-level and a detailed description of the service and its individual operations, including versioning.

Timetable. Provides information regarding the availability of the service in both test and production systems.

Operation properties. Provides information concerning its granularity and specific properties for each operation, e.g., concurrency, multiple calls.

Contract conditions. Provides information concerning pre- and post-conditions for each operation.

Special cases. Provides explanations of special cases for each operation.

Service operations and signatures. Provides lists of input and output parameters with detailed explanations concerning admissible values and their respective meanings for each operation.

Errors. Provides a list of possible errors that can occur after operations are invoked for each operation.

Service level. Provides quantitative information concerning the intended service level, i.e., average load/peak load per hour/day/month and response times.

15.3.3. CHOREOGRAPHY, SECURITY, AND MANAGEMENT

The SOA implemented at Winterthur is mainly concerned with providing basic services using widely existing host functionality through service interfaces. Most services are data-centric and thus leverage fundamental SOA functionality. At this point, however, the SOA has not integrated the more advanced functionalities such as service composition.

Thus, there is currently no common modeling approach for the workflow used in the applications accessing host service operations. Instead, the workflow is captured "only" at the conceptual levelin the dynamic models of the use case realizations. Thus, the workflow can be said to be the sum of all use cases. However, the workflow is coming more and more into focus and is to be expected to play a major role in future enhancements of Winterthur's SOA.

At this point, there is also no support for defining distributed transactions in Winterthur's current SOA. One way to ensure transaction-like behavior is to develop a coarse-grained (CORBA) service, spanning all PL/1 objects involved in the transaction. The latest release of the e-Platform enhances the CORBA blueprint with distributed transactions. However, because there are risks when relinquishing control of host transactions to "untrustworthy" client systems (e.g., locking of critical system resources in cases where transactions are not closed), different boards must decide how to best exploit new technical possibilities in Winterthur's environment.

Winterthur's SOA is used by internal and external applications, and security is therefore a major issue. The underlying framework will set credentials so that they will not appear in the operations' signature (otherwise credentials and user ID could be modified programmatically to obtain more privileges). These credentials are used to determine whether a client is authorized to access the functionality provided by a service operation.

Finally, monitoring functions are provided by special platform services and tools that allow an end-to-end monitoring of service execution. A small framework has been developed that periodically calls test programs that check the status of host transactions and CORBA adapters and transmit error reports should a host service be unavailable. These error reports and the monitoring framework are accessible using an HTML-based browser interface.