As Norway's largest financial services corporation, Storebrand ASA provides for the health and life insurance as well as banking and asset management needs of more than 280,000 clients throughout Norway. One of the toughest challenges facing this mammoth corporation has been tracking and managing employee records when operating the pension schemes of the 390,000 employees across approximately 6,500 Norwegian companies.

For years, this monumental synchronization task has been largely a manual process, occupying a dedicated staff of 50 to maintain the relevant database entries. The work involved includes the transmittal, verification, updating, and rechecking of data such as dates, salaries, addresses, contracts, account numbers, and other detailed information, and then entering it into Storebrand's centralized database. To do so, data from customers' multiple payroll systems was extracted and sent to Storebrand -- sometimes through the use of forms online but often manually and on paper. Authentication of the data is provided through a combination of Smartcards and certificates. This tedious process begged for an automated solution, yet previously has not been possible using existing Web standards. Therefore, Storebrand's sought to find a way to utilize open standards to electronically exchange documents with partners over the Internet.

Along with employee records synchronization, other business challenges facing Storebrand included linking key products and services together, such as between life insurance policies, pension funds and banking choices. They also sought a better way to offer their products to distributors and customers. Finally, Storebrand wanted to control costs by improving efficiencies both internally and with business partners by automating business processes to lower operating costs.

As a result, Storebrand expected to see improvement in operational efficiency by reassigning the majority of employees currently involved in manual data input and management, thereby potentially saving the company thousands of hours in labor costs annually.

The business and technical challenges

Storebrand ASA approached the IBM j(ump)Start Emerging Technologies UK team with their dilemma. After consulting with jStart Engagement Managers, Storebrand identified a two-prong objective:

1. Modify existing internal business practice of manual employee data handling.
2. Enable data to be captured from client payroll systems using Web Services, automatically perform calculations on that data, and then transfer the resulting information directly to its mainframe database.

On the jStart implementation side, the project objectives were identified as the following:

• Create web services for Storebrand side (as Servlets).
• Adapt Vendor Payroll Systems to web services.
• Implement the necessary infrastructure.
• Ensure security.
• Connect existing Storebrand business partners.
• Provide a proof of technology for web services.

Back to top

Finding a common format

The first step in the process was to identify and agree upon a common data format. A common format was needed for customers to be able to present their data to Storebrand in a consistent way, and Storebrand applications needed to be able to extract the appropriate data and deposit it in their central database.

The majority of Storebrand customers and partners already have captured employee data electronically, and most have linked employee information to their own payroll systems. The information required to perform precise calculation of an employee's benefits originally was kept in each company's payroll system. That means, changes in earnings and other data had typically been extracted onto paper and such document faxed or mailed to Storebrand ASA for manual input.

In order to enable multiple payroll systems (and eventually support a target of all systems of the 6,500+ businesses served by Storebrand ASA), a standards-based solution had to be provided that could be implemented in multiple payroll systems running on different operating systems on a variety of hardware platforms.

Storebrand ASA identified for this purpose an industry-specific XML vocabulary -- XMLife from the US industry group ACORD. With a few additional tags (see the full modified DTD in the Resources section), Storebrand ASA was able to provide a standards-compliant means to exchange data between companies' payroll systems and their own benefits management system.

In selecting XMLife, the joint development team of Storebrand and jStart members took into consideration several factors. First, the format needed a generic solution for all partners, not a schema specific to a single vendor. Neither entity wanted to expend the time or money to develop their own standard. Since ACORD is the current industry standard for the insurance business (which represents approximately 44% of Storebrand's business), and XMLife was an acknowledged and suitable XML Schema for a common adoption, the duo was the obvious choice.

Using this solution, each payroll vendor extracts the necessary data and the data is converted into XMLife. A COM-component provided by the vendor generates a SOAP-request, and a web service at Storebrand receives the data and passes it on to IBM's MQSeries Integrator middleware.

Back to top

Ideal solution: industry specific tModels

While identifying an XML vocabulary for data exchange between businesses is a great start, what the insurance industry needs is to standardize on web services. Web services definitions allow descriptions of specifics in the form of tModels. TModels are basically a free-format extension of the metadata, outlining the comprehensive specifications for a service. As such, the description through a tModel as defined by a WSDL document could contain a pointer to the used XML vocabulary, but also contain further descriptions like business rules, cost, or obligations related to the use of the specific service.

However, this would not be something Storebrand would want to do on their own. Ideally, the insurance industry would define this (that is, exchange of life insurance data) and other business transactions, standardized as web services and documented through tModels for the swift adoption by the entire industry.

For the case of Storebrand and its customers the jointly defined system fit the bill. After the common data format had been agreed to, the next step involved getting multiple disparate systems using different programming languages to communicate with one another. Many of Storebrand's customers use the Windows 2000 operating environment on Intel-based systems architecture, while Storebrand's central data repository operates on an IBM mainframe running a completely different operating environment.

The team began with a project definition workship in early January 2001, investigating the current infrastructure with the payroll department, the business partners, payroll vendor providers, and the technical teams. Development began in February and progressed over the course the next two months before completion of the initial system in early May. Storebrand in the meantime had to get contracts in place with its customers to use the new system, which took until August. The initial tests for the new system has two to three customers processing hundreds of employee benefits clients. Initially the system involves a direct relationship between Storebrand and its client companies. In the future, a third party serving as a payroll vendor provider may be involved as an intermediary. In such a case, the payroll vendor provider would act as an application service provider to the actual client companies with the individuals with benefits needs.

To get the divergent environments to share data, jStart suggested using a SOAP (Simple Object Access Protocol) connection to bridge the gap by connecting the Windows environments of most payroll applications with the WebSphere Java environment at Storebrand Life.

The team determined that three options were available:

1. SOAP alone -- SOAP would provide the basic program-to-program "glue" that enables applications to bind together and enter into peer-to-peer communications.
2. SOAP + WSDL definitions -- WSDL would provide a standardized description of the service, but would not offer full repository lookup. Once the application service has been described, it would be published with a service broker that helps make the application/service known to Web "requestors" (in this case, new Storebrand distributors).
3. SOAP + WSDL + UDDI (including service description in registry) -- UDDI is also a framework for web services integration. It contains standards-based specifications to describe the Storebrand products and services and allow discovery in a global registry architecture.

Storebrand initially opted to utilize a combination of all three technologies. To do this, the team created a COM object that takes the XML document as input and sends it to the Storebrand web service, by transmitting it over the Internet via the HTTP protocol. The customer sites, in this case, primarily used Microsoft Windows NT or 2000 systems to perform their data entry for the benefits processing. Thus, the team decided on building COM interfaces in VB for the client-side and used Microsoft's SOAP toolkit for the interface. On Storebrand's server-side, the team converted an existing Java application to a service by simply using the Wizard provided in the IBM XML & Web Services Development Environment. This web services-enabled application receives the XML document and transforms the data for the verification and update process required to feed the DB2 central database of Storebrand. Data transport and manipulation at the backend is managed with MQSeries Integrator. Figure 1 details the conceptual architecture of the project system.

Table 2 shows the planned deliverables and the individual software components used in the project.

A project of this scale using brand-new technology is not without complications. At that time in early 2001, the team had no idea on how to implement the lacking security of web services. Storebrand's requirement was to have the same level of security as the current online system they offered to their customer using a form on a Web page rather than sending a fax or paper record (that also often required the customer to re-enter all the data onto the Web form). The team ended up using the Secure HTTP and SSL protocols, as is commonly used on many business Web sites. However, one initial problem was that the Microsoft SOAP toolkit for the client-end development did not support SSL at the time. Thus they had to use direct calls to the Microsoft Wininet.dll library to initiate the call to the server-end service. An example of these Visual Basic calls is given in the Resources section. They would then make the SOAP calls (see Resources.)

A second problem was handling sequential messages in an idempotent fashion, such that they are executed once and only once. This is a general lack in web services today. To avoid this classing problem which can cause a service to reprocess multiple instances of the same message, the team added a uniquely generated record number in the application software above the services level.

Additionally, there was no way to identify a client-side context to the server. As part of the implemented security system, the team had to include a certificate as part of the SOAP message. To do this, they used the pluggable provider interface available in the Apache SOAP implementation.

Finally, at the time of the project, the team faced incompatible WSDL implementations in the Microsoft and IBM toolkits. This is one of the factors that led them to not use standard WSDL in the deployment system and instead opt for their own document description format. Once the project moves into a broader context and brings in more companies (as well as more client systems), they plan to evolve towards a single compatible WSDL implementation. An example of the document descriptor they used and an example stub on the server end that matches the descriptor is given in the Resources section.

Once the calls through the Wininet library have established a secure connection to the server end, the Visual Basic client application would make the appropriate SOAP calls to send data. This would theoretically access a service through a description in a WSDL file. However, as noted, it uses the customer deployment descriptor. A set of example files that illustrate the calls to Wininet, Microsoft SOAP toolkit, the theoretical WSDL file, the actual customer deployment descriptor, and a server stub for this particular example is available in the Resources section.

For users of the newly adapted payroll systems, there were several consequences. First, the installation time for the client-side software at each new client company is less than a day. All that is really needed is to make the provided DLL files available to the payroll application, assuming that the client software supports standardized XML. During execution, the operator does not need to do anything different in their client data entry to establish the SOAP connection over the Internet and transmit the necessary data to Storebrand. Wrapping the XML as a COM object also eliminates a potential security risk, which would exist if, during a failure in execution, the XML file would remain accessible as a document on the file system of the client machine. This is particularly undesirable, as the data contains salary and other personnel related information, which needs to be maintained with the respective obligations for such data.

Back to top

A successful solution

The project has been in operation for some months now but over time will evolve to accommodate the more complex situation of all Storebrand's clients in this area. This initial system works with one of the leading benefits processing software package in wide use by Storebrand's client companies from the Scandinavian firm, Tietoenator. However, to get wide adoption across Storebrand's 6500+ customers, they anticipate that they will have at least 30 different popular benefits-processing-packages to deal with. This involves quite a few different platforms on the client side and thus illustrates the real benefit of a system that is truly platform- and language-independent.

Storebrand expects the combination of being able to communicate easily with distributors and clients who are using different systems architectures (using SOAP), being able to make its services known to the industry (using UDDI), and being able to publish details about how to work with Storebrand applications will result in finding new distributors for its financial services, banking, and insurance products, as well as to potentially assimilate offerings of some of its business partners into the Storebrand application portfolio.

Storebrand also expects that web services will be utilized in other business areas within Storebrand Bank and Storebrand Funds business units to reduce internal operating costs there as well.

With Storebrand's web services solution, data maintenance is much more efficient, existing customers and partners are satisfied, and the company considers it's new abilities good for presales. By making use of XML to capture and present data, by modifying business processes between Storebrand and its customers, and by using the SOAP Web standard for program-to-program communications, the company will be able to save thousands of hours in manual information capture and input time -- thus reducing operating costs which pass directly to the company's bottom line.

Resources

• Participate in the discussion forum.
  
  
• Find out more about Storebrand ASA.
  
  
• The IBM jStart team helps companies implement new technologies into their corporate systems.
  
  
• Here are the example files for the Wininet calls, the Microsoft SOAP toolkit calls, the potential WSDL file, and the deployment descriptor.
  
  
• The Web Services ToolKit has added many new features since this project first started.
  
  
• You can also download the XML & Web Services Development Environment that was used in this project
  
  
• Find out about sniffers in this developerWorks article by Larry Loeb.
  
  
• Visit this site to learn more about IBM WebSphere 3.5.2.
  
  
• Check this out for more information on IBM VisualAge for Java 3.5.
  
  

About the authors

Rate this article

Comments

Back to top

Table of contents

• The business and technical challenges
• Finding a common format
• Ideal solution: industry specific tModels
• A successful solution
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

Dig deeper into SOA and Web services on developerWorks

Discover knowledge paths

Skill-building guides for Linux, open source, cloud, Java, business analytics, and more.

Special offers