	An XML information server for advanced B2B architectures		Table of contents		Indexes		Content &, knowledge management

Insure yourself with XML!

Fontaine, Philippe

Philippe Fontaine

Project Manager

SGML Technologies Group

SGML Technologies Group, 29 Boulevard Général Wahis
Brussels B-1030 Belgium
Phone: +32 2 705 70 21 Fax: +32 2 705 81 01 email: phf@sgmltech.com web site: www.sgmltech.com

Biography

Philippe Fontaine - Philippe is a project manager at ACSE sa/nv, Brussels, a member of the SGML Technologies Group. For over ten years he has been active as a software engineer and systems architect specializing in object-oriented distributed applications and complex document workflow systems. All these systems use XML either as a document storage and exchange medium or as a formal message specification tool for communications between distributed application processes. He obtained a degree in electromechanical engineering at the Free University of Brussels. Philippe Fontaine has spoken at several international conferences and has published papers in different SGML/XML journals.

Abstract

In e-business applications, the project manager is used to being confronted with the problems of modelling his business and structuring the data exchanged within his application. This paper focuses on the ability to useXML in three ways to solve his problems: to exchange structured data, to specify the business components in a standard way, and to preserve the investments made in the architecture.

Context

Since the paper covers e-business applications in the insurance sector, first of all the context of the insurance business in general is described and how brokers and insurance companies are working together over the Assurnet network in Belgium in particular.

XML	The remainder of the paper focuses on the architecture of these client/server applications to show the intelligent exploitation ofXML .

Insurance business

As illustrated in , the insurance business is usually split into two sectors with regard to the type of cover: life and non-life. The life sector includes group and individual life insurance whereas the non-life sector handles fire, car, liability, and comprehensive insurance.

Insurance business sectors

However, the actions or services that can be performed are similar regardless of the insurance sectors: quotation, production, and claims. Production is the most time-consuming in terms of administrative work since the work includes addressing the new contract business, endorsements (modification, suspension, and cancelling), and invoicing. Companies that are working with insurance brokers are looking for tools or applications that can be delivered to the brokers in order to delegate these administrative tasks.

Assurnet

Delegation of administrative tasks to the brokers is now possible in Belgium with Assurnet, this being the telecommunications network for the Belgian insurance industry. It allows brokers and insurance companies to exchange standardized messages in order to carry out business transactions.

gives a schematic view of the Assurnet network. Three kinds of members are connected to the network: insurance brokers, insurance companies, and Assurnet itself acting as a central point to deliver common services (see below). Although structured insurance requests can be exchanged in a synchronous mode (online requests via the front-end server) or in an asynchronous mode (mailed requests via the exchange server), one of the main objectives of the insurance community is to promote the transactional way.

Assurnet network

The key objectives of the Assurnet initiative are threefold:

to increase the evolution of the insurance business by providing a complete technical and functional infrastructure;

to promote the development of online applications by setting up a network and by providing all basic components needed to develop such applications;

to allow the insurance companies to develop and to install their own applications on the broker's platform (not just the standard ones provided by Assurnet as was the case in the first release of the Assurnet network).

Behind the word Assurnet are hidden three different concepts:

a value-added network offering services to its members such as access control, legal tracing of transactions, software distribution, and shared databases of common business information;

a set of communication, business, and presentation standards for the client/server applications exported to the brokers (the business standards address the content and the structure of the insurance requests through the specifications of theEDIFACT /Telebib2 standard);

EDIFACT, Electronic Data Interchange For Administration, Commerce and Transport

a company founded and administrated by the most important Belgian insurance companies and offering support in terms of installation, hot-line, architecture set-up, and development consultancy.
Activities of the company include:

development and management of the Assurnet network;

management of their own analyses and developments;

training and assistance to the end-users and to the developers within the insurance companies;

delivery and installation of the standard Assurnet equipment.

Currently, there are about 7,000 broker offices and more than 50 insurance companies connected to the Assurnet network. Most of the companies have developed and deployed their own specific applications to manage the production tasks related to car and fire insurance.

Architectures

XML	After having outlined the underlying concepts, this section gives an overview of two apparently different types of architecture in order to be able to show whereXML is used and why.

Objectives and requirements

The underlying objectives of the following Assurnet client/server solutions are to preserve the customer's investments, to guarantee the openness of the architecture, to implement a modular approach, to free the user from technology dependencies, and to enable future business and technical evolution.

The requirements for these architectures are:

to set up an architecture that allows the building of Assurnet applications, which means client/server applications connected to the Assurnet network, satisfying the functional and technical requirements dictated by Assurnet;

to set up an architecture that allows the building of Web-enabled applications while preserving the biggest part of the investments (that means that the previous Assurnet applications have to be able to be transformed into Web applications quickly and simply);

to set up an architecture that integrates the legacy applications (usually running on a mainframe) with clean and well-defined interfaces so that the replacement of this legacy will not impact the rest of the applications.

Architectural model

In it is shown how different types of applications can be integrated within a single architecture. The distinction is made between the business components that are located on the application server and the dialog and client components that are located on the front-end servers and on the end-user's platforms. The glue between these different client types and the application server is provided by a uniqueXML message definition. As seen in this figure, the production server gathers the legacy applications.

Architectural overview

As detailed below, the application server is made of several parts.

The message handler interpretes theXML messages coming from the dialog servers, validates their content and syntax, extracts the data related to the different business objects, and invokes the interface of the corresponding business objects.

The business objects constitute the heart of the business layer; the static model (ie the data structure) and the dynamic model (ie the transactions) of the business objects represent the entire business of the application; their interface with the clients is the transaction interface exported by the dynamic model. To accomplish these transactions the business objects invoke the services exported by the business services layer.

The business services are all the services that have to be performed on the application server (compared to services performed on the production server) during a business transaction. These services are not part of the business objects since they can be located on a different machine, developed by other teams on different development platforms. However, they have to export a clean and well-defined interface for the important reasons of encapsulation and interchangeability.

On the other side, the clients that might issue business transactions can be of several types.

Assurnet brokers - With the application installed by the company, these clients issue requests structured inEDIFACT /Telebib2 by exploiting the Assurnet communication and dialog protocol. The verbs of the protocol are implemented on the so-called AS/2 (front-end) server as well as the software needed to interpret the Telebib2 messages; the static and dynamic content of the messages are translated into the uniqueXML structure and sent to the application server where they are processed by the business layer. These same mechanisms apply in the opposite direction.

EDIFACT, Electronic Data Interchange For Administration, Commerce and Transport

Web users - These users can be insurance customers (direct insurance) or brokers who are not necessarily connected to Assurnet. Exchanges between the browser and the Web server are taken in charge by dialog objects until the business request is complete; at that moment, the usualXML business message is built and sent to the application server. (This architecture is detailed below since it shows clearly the full exploitation ofXML in all its layers.)

Specific users - For the insurance companies, there might be many other channels to issue business requests that distinguish themselves by specific dialog protocols and/or specific message formats. Such specific requirements are handled by dedicated dialog servers, the output of which is always the same: company-standard businessXML messages for the application server.XML ensures complete openness for these specific distribution channels.

Company agents - Finally, since company agents take an active part in the life of the insurance business objects, they have to be able to interact with these business objects by issuing business requests too. With this architecture they can do it directly in theXML format provided the company has developed the appropriate agent application.

XML	Implementations

Depending on the type of software delivered to the client (ie the broker), the application architecture will be named 'thin' or 'fat' client architecture. In a thin client architecture, the Internet browser is the only software required on the client platform and the communication with the server is done on the Web, whereas in a fat client architecture the software installed on the client platform is a complete application with presentation, business, and communication functions as well as the run-time software needed to support this client application.

EDIFACT, Electronic Data Interchange For Administration, Commerce and Transport

HTML, Hypertext Markup Language

Both architectures can accept business data from heterogeneous sources, ie from brokers using different media and/or formats to transmit their insurance transactions. For example Assurnet brokers exchange standardEDIFACT requests, Internet brokers exploitHTML andXML standards, whereas some big brokers' offices have their own proprietary formats, which look like a mix betweenEDIFACT and COBOL records. It is crucial not to hard-wire the server application and the business objects to these different formats, rather to introduce a translation layer to a standard pivotXML format.

EDIFACT, Electronic Data Interchange For Administration, Commerce and Transport

Furthermore, as highlighted in the previous section, because of the uniqueXML interface both implementations can coexist within the same architecture and share the same business layer. The choice for a certain type of implementation depends on technical and strategic criteria such as the integration into the client's environment, the duration and the costs of the development, the distribution of the application, the performance, the awareness of up-to-date technologies, and the notion of an enterprise portal.

In some installations, first a fat client application has been built for the Assurnet brokers, and then a thin client application has been added in the same architecture for Web users willing to issue some quotation requests.

Focus on XML

XML	This section goes into more detail in the description of these applications showing thatXML can play a major role regardless of the architecture chosen. The thin client architecture has been chosen to illustrate the concepts and the techniques since it highlights the multiple uses ofXML .

Why XML?

XML	In such applications,XML is used to specify any kind of information wherever this information has to be shared between systems and people over the years. This implies 'openness' and 'standard'.

Nowadays, openness is a key factor in any development in general and in the insurance business in particular since it helps preserve the investments against changes in the exchange formats of data coming from the outside, changes in the definition of the business products and services, changes in the technologies used, and changes within the company itself.

illustrates the detailed architecture of a thin client application.

Use of XML

In this architecture,XML is used as a pivot format for exchanges between components, as a structured method for information on the Web, as a formal description of the structure and the behaviour of the business objects, and as a formal description of the presentation dialogs. Such usage is described below.

XML	The reader can find a lot of information about the benefits of usingXML in papers, at conferences, and on the Web. In the next sections, focus is on the features that are the most relevant in the context of the insurance business and open architectures.

XML as pivot format

When developing e-business applications, one of the key tasks consists of implementing components for processing the messages to be exchanged. Such components aim either at converting the messages from one format to another, or at using the information contained in the message in the components of the business layer .

XML	Using a pivot-oriented approach for developing such components proved to be extremely cost-effective. The approach consists of using a single internal representation of the information inXML to interface the business layer, as shown in .

XML as pivot format

The benefits of such an approach are the following:

the code of the business layer can be independent of the actual concrete representation of the information, by relying only on theXML model;

XML	the application can be adapted more easily if the external syntax of a message is modified;

the set of features available in the development environment, associated with theXML syntax, becomes independent of the choice of the external representation format;

XML	the use of a consistent set of tools and techniques for manipulating theXML syntax across applications improves the productivity of the developers.

XML as a modelling format

In such complex applications, the clear and unique specifications of the functionalities provided by the different layers are a key factor of success. Furthermore, if these functional specifications could be exploited to generate parts of these target applications, this would avoid some misunderstanding of the specifications as well as errors in their implementation.

XML	In it is shown how different parts of the application can be generated automatically from a unique source of specifications written inXML .

XML as a modelling format

DTD, Document Type Definition

Given this approach the functional specifications are gathered within a singleXML (logical) file according to a well-definedDTD . Validation against thisDTD ensures that all data needed to generate the components of the application is present and well structured. Depending on the type of component that has to be generated, a specific set of rules is associated with the parsing phase, exploiting only the content of theXML specifications that is relevant to the component to be generated.

DTD, Document Type Definition

The component that can be generated automatically could be:

technical and functional documentation;

the structure of the classes and the layout of the database corresponding to the specified objects;

client screens in different formats associated with the structure of the business objects;

the specifications (ieDTD s) of the messages that are exchanged between the client and the server in a typical client/server application;

DTD, Document Type Definition

the code able to interpret the previous messages, including validation rules.

This list is not exhaustive. In this paper the focus is on the specification of the dynamic model of the business objects as well as the generation of some components of the user interface.

business objects

Business layer

Business object modelling

DTD, Document Type Definition

The insurance business objects, such as the insurance policy or an insurance claim, can be modelled in their data structure (the static part) as well as in their behaviour against external events (the dynamic part). Both models can be specified withXML instances. TheseXML instances have to satisfy well-definedDTD s in order to be able to validate their structure and their behaviour before building the application itself. Behind this aspect of validated modelling, the sameXML instances can be used also to generate different parts of the target application such as the database layout, the business object interface, inputs to the finite state machine implementing the behaviour, and the documentation.

OMT
state diagram

Dynamic behaviour of the business objects is at the heart of the business layer since all the functionality of this layer as well as the structure of the business interface itself are articulated around this model. According to theOMT methodology , the behaviour of the business objects can be modelled as a state diagram, as illustrated on the next figure for a typical insurance policy.

State diagram (partial) of an insurance policy

In the diagram above, an insurance policy changes from onestate to another each time an allowedevent is triggered. During thisstate transition , specifiedactions are executed to achieve the functionality required on this transaction. For instance, when an insurance policy has been proposed (stateProposed ), it can then be accepted automatically by the system (eventAccepted ), refused automatically by the system (eventRefused ), or submitted for further analysis by a company agent (eventTo be analysed ) according to the acceptance criteria of the company. Accordingly, the next state of the insurance policy will beAccepted ,Nil , orWaiting . The different appropriate actions are executed for each transition such as update of the production database, transmission of a feedback message to the broker, or generation of the contractual documents.

COM, Component Object Model

DTD, Document Type Definition

The business object state diagrams are specified inXML through a dedicated user interface. The resultingXML file is compliant with the state diagramDTD that allows for the generation of the related documentation and for the run-time interpretation of the state diagram itself. AnXML -based engine has been built as aCOM component in the business layer that manages the life of all business objects according to theXML specification of their state diagram.

XML	A security model can be specified on the same diagram by adding permissions on the transitions: only users belonging to authorized roles or groups of roles for a given transition can perform this transition.

Business object interface

The business object interface exports the external events defined in the state diagrams of the business objects. In the previous example, the interface to the insurance policies would gather thenew business ,accepted (by agent) , andrefused (by agent) business events and their attributes.

DTD, Document Type Definition

These business events and their attributes are structured inXML according to a well-definedDTD , which guarantees the openness of the whole architecture since it constitutes the interface between the company-oriented business layer and the so-called customer-oriented dialog layer.

DTD, Document Type Definition

In order to cope with the evolution of the insurance products (ie business objects), theDTD has to be flexible enough in order not to be forced to modify all generic tools and components each time the business specifications change. As a consequence, thisDTD must not be hard wired either to the structure of the business objects or to the defined list of the business events. A higher level of abstraction is required and the final validation of data is left to the message handlers.

Dialog layer

The dialog layer is the layer oriented to the clients of the application. It includes the presentation aspects as well as the aspects concerning the application-level protocol used to carry out a dialog with the end-user. For thin client applications, this last part concerns the sequence of Web pages and the application of the validation rules on the data in between.

Client interface

A typical view of the user interface is shown in the next figure. Within the Web browser, the application user interface is made up of different parts:

a menu bar and/or a tool bar allowing the user to issue the authorized actions to the server (these actions can be split into object-oriented actions (ie triggering the business events on the business objects such as theNew business event in our insurance policy example) and general purpose actions (eg selection of the business transaction, search tools, undo, and help));

a data structure navigation frame that allows the user to navigate through the structure of the business object involved in the transaction (this frame looks like a tree where the branches and the leaves map the data structure of the business object (eg guarantees, risks, or owner, for an insurance policy));

a detailed data frame showing all the displayable data of the selected leaf in the navigation frame where this frame can be used both for data entry and for data display.

Typical user interface

It should be noted that the menu and toolbar and the navigation frame are generated dynamically for the client from the data coming from the server whereas the data frame is built on the server and filled in dynamically for the client with the data.

The figure below gives an actual example of such a user interface showing the data frame with the general information data of a fire insurance policy.

Example of user interface

A dialog is associated with each business transaction (eg create a new car insurance policy, or update an existing fire insurance policy). This dialog defines the data and the actions that are presented in the different parts of the user interface as well as the data and the actions that can be entered by the end user.

shows details of the structure of the information that is exchanged between the browser and the Web server in both directions.

Web client/server messages

CSS, Cascading Style Sheets

Specific to Web-based architectures, data exchanged between the Web server and the browser can be structured inXML in order to include an embedded presentation layer: thisXML string contains available business object data and authorized business actions as well as some presentation-oriented features directly related to data such as visible, enable, read-only, and list of values. Pure presentation information is gathered in associated style sheets (CSS orXSL ) andHTML templates.

HTML, Hypertext Markup Language

This figure is described in more detail below.

Dialog modelling

As for the behaviour of the business objects, the behaviour of the dialogs (ie the succession of screens and actions prompted by the user's requests) can be modelled with state diagrams. By comparison, a business object (eg car insurance policy) is replaced with a dialog object associated with a business transaction (eg update of an existing life insurance), a business event (eg new business) with a dialog event (eg click on a node of the data tree in the navigation frame or trigger of a menu action), and the business action with the actions related to the processing of the dialog (eg applying validation rules, building the next information files, or sending this information to the client browser).

DTD, Document Type Definition

XML is used to specify the state diagrams modelling the behaviour of these dialogs. So for each business transaction, a different dialog can be defined. At run-time, this dialog is automatically controlled with respect to its formalXML definition. The same tools as those for the business layer are used. The sameDTD is used, ie the one that controls any state diagram definition, regardless of the kind of the object that is modelled.

The power of that model resides in the capacity to modify completely the user interface just by modifying the state diagrams of the dialogs, and the detailed data frames if needed, without having to modify the rest of the application.

Dialog interface

DTD, Document Type Definition

Whereas information coming from the browser is gathered in one string structured inXML , information coming from the server is split into several (logical) files according to their nature. TheDTD structuring the data is the same in both directions.

The different pieces of information and their role are described in more detail as follows.

Data - The business data and the dialog events (ie actions that can be triggered by the user in the menu/toolbar or in the navigation frame) are structured inXML . This allows the building generic tools that generate the menu/toolbar and the navigation frame dynamically for the client; other data such as lists of values and multilingual labels are also sent to the browser inXML .

Validation and mapping - These scripts contain several groups of tools:

reusable generic tools for the generation of the menu/toolbar and the navigation frame;

reusable generic tools for the data mapping between theXML structure and the detailed data frame;

XML	semi-generic functions that implement some basic validation rules such as ranges of values, direct consistencies between data and strong type checking.

Layout - The detailed data mapping frame is built on the server and sent to the Web browser inHTML ; the fields are filled in dynamically by the data mapping tools included in the scripts.

HTML, Hypertext Markup Language

Presentation - In order to present a common user interface through all applications of the company, the presentation standards have been gathered in a dedicatedCSS file.

CSS, Cascading Style Sheets

It should be pointed out that the near birth ofXML -companion standards such asXSL and X-Schemas will impact the structure of information described above, mainly in the presentation and scripting areas.

DTD, Document Type Definition

To adopt a common concept to model the different parts of the application, the dialog interface exports the external dialog events and their attributes, as the business interface does with the business events. However, theDTD s are not the same although both have to be generic enough to cope with the evolution of the products.

Some real-world applications

All these concepts, techniques, and tools are exploited in actual applications that are currently running in large Belgian insurance companies as CGU (the amalgamation of Commercial Union and General Accident), HDI-HIB (Hannover International Belgium), and AGF Belgium (a subsidiary of Allianz).

Conclusions

XML	The conclusions address three different subjects: the benefits of exploitingXML inn - tier architectures, the possibility of extending the developments from one application to an application framework, and the extension of these concepts outside the insurance sector.

The main overall benefit is the proved compliance with the openness objectives of these insurance applications. Furthermore,XML brings the modelling and structuring tool that is needed in every application design and development.XML allows the addressing of important questions such as maintenance, reusability, documentation, consistency, and standardization of the developments. In combination withn - tier architectures,XML is the guarantee of a clear software answer to complex e-business interrogations.

DTD, Document Type Definition

If it is considered that a given architecture is appropriate for a certain number of different applications, it is worth thinking of adopting a generic approach in the design and development in order to consider every new application as an instance of an application framework.XML is particularly well positioned for such reusability since the variousDTD s and the related tools (eg state diagram engines) can be exploited in exactly the same way for every occurrence.

Although this paper focuses on insurance applications, it is obvious that this type of architecture and this intensive use ofXML can be reproduced in other business sectors. Finally, this paper should be taken as a set of ideas mixing architecture andXML that could be exploited in everybody's business domain.

Bibliography

Rumbaugh 91

Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., Lorensen, W.; Object-Oriented Modeling and Design; Englewood Cliffs, N.J.: Prentice-Hall, 1991

Vijghen 98

Philippe Vijghen; Cost-effective EDI using XML?, Conference Proceedings of SGML/XML'98 Europe; Paris, France: GCA, 1998.


	An XML information server for advanced B2B architectures		Table of contents		Indexes		Content &, knowledge management