Section 15.2. Implementation

15.2. Implementation

This section deals with the processes and structures that Winterthur established to guarantee the success of the SOA, the repositories constructed to make information on services available, and the project management techniques employed.

Selling SOA within the Winterthur was difficult, especially explaining its benefits and its cost. It took also a relatively long time to make its specific concepts understood and to develop an understanding of the systems' implications and the necessary process adjustments.

Two reasons led to the initial support for the SOA. First, the problems resulting from the monolithic structure of the mainframe applications were blatantly obvious, in particular regarding maintenance costs and lack of flexibility. Second, architects, and analysts advertised for the SOA at all major IT events.

In particular, the local CIO strongly supported the SOA. Building on the previously available e-Platform infrastructure, a project team accomplished the necessary standards, guidelines, training modules, processes, and organization to define and implement the SOA. The project team was staffed with a resort architect, an e-Platform architect, e-Platform engineers, members of the software development support group and data management, host application developers, and an external consultant.

15.2.1. PROCESSES AND STRUCTURES

Figure 15-4 shows the development process based on the Rational Unified Process proposed by the e-Platform. It distinguishes between a business view and a technological view on one hand and the three standard development disciplines (Requirements, Analysis & Design, and Implementation) on the other.

Figure 15-4. e-Platform's analysis and design process.

The business view focuses on functional requirements and develops use case models and a component landscape. In doing so, it explicitly aims at designing reusable business components that provide their functions through services. The technological view deals with the non-functional requirements and concentrates on the reference architecture based on e-Platform blueprints. The application architecture is formed by the integration of the business view and the technological view.

Figure 15-5 shows the key aspects of Winterthur's design process in more detail. In order to capture the requirements, use case models, user interfaces, and conceptual business models are developed. These roughly corresponded to the three tiers of the architecturethe presentation layer, the application layer, and the domain service layer. The models are used as a basis for the realization of the use case and the service design, and they consider both static and dynamic aspects of the system. Whereas the static service design focuses on the service interfaces and data elements, the dynamic service design addressed workflow issues, that is, how service operations are to be combined in order to obtain the business activity-oriented services identified in the design of the use-case realization.

Figure 15-5. Details of Winterthur's analysis and design process (focused on the business view).

In order to ensure that the general design process is actually applied to specific services, a dedicated team called Application Services was established within the Winterthur Market Unit Switzerland. One of its tasks is to advise the application project teams on how to leverage the Service-Oriented Architecture in the best possible way. To do so, members of the group support the business developers when new services were designed. The group also offers training and instruction courses on its Service-Oriented Architecture, service-oriented design principles, and repository use. It is also responsible for QA on service definition.

15.2.2. SERVICE REPOSITORY

As shown in Figure 15-6, the repository contains information about available services. Note that this information is provided at the contract levelit forms an abstraction of technical details concerning implementation. The repository acts as a link between the more conceptual levels of the business context and the more technological levels covering the actual implementation.

Figure 15-6. The repository links conceptual level with technological levels.

The main purpose of this abstraction and layering is to guarantee independence from a particular technological solution, which in turn significantly increases flexibility. Because a service contract does not depend on whether the service is implemented using MOM, PL/1, EJB, SOAP, or CORBA, it is possible to exchange service implementations with minor modifications for client applications using the services. Such an exchange is concerned only with the implementation and deployment on a different blueprint, whereas at the contract layer there is no visible change. The major change concerns the corresponding technology bindingthat is, the code that maps the service interface specified in the contract to a particular technology.

The repository also contains metadata describing the implemented services, which are useful for application designers and developers. This includes information such as service ID, service name, service status, domain, owner, and short descriptions. The service contract, also stored in the repository, additionally describes special cases, errors, quality of service, versioning, etc. We provide a more detailed description of Winterthur's service contracts and the implementation of the service repository in Section 15.3.

15.2.3. PROJECT MANAGEMENT

The Application Service Team, described beforehand, is responsible to make sure that SOA is applied correctly. The team keeps the focus on reusability and captures and categorizes, together with the data management team and the service owner, the data used in the different applications.

Specific requirements with respect to project management arise from the fact that services have to be designed so that they are as reusable as possible. In particular, the analysis phase in which the basic business requirements are compiled becomes more complex. Instead of simply involving the business experts for the new application, experts from potential future applications have to be included in the design process. The Application Service Team and the service owners therefore have to make sure that future requirements are taken into consideration during the analysis phase in order to guarantee reusability of the developed services.

The Application Services and the Data Management Team responsible for the analysis and design of new services consist of seven employees. Their main task is to establish the service contract, which serves as a basis for the IDL specification of the service interface, and to implement the IDL and the interface module. Members of application development teams then build the actual implementation of the services.

In general, a mixture of a top-down and bottom-up approach is used in Winterthur's projects. On one hand, services are implemented when they are needed by applications. On the other hand, services are implemented with reuse in mind, and technological considerations are taken into account from the beginning. In particular, granularity of services is designed with performance issues in mind; too finely grained services are generally avoided because they pose performance risks due to the many time-consuming remote calls that would be needed to perform a single business activity.

Change management is realized by using a versioning system. The repository contains detailed information about the various service versions available, including expiry dates for obsolete versions.