|
Insure yourself with XML!
|
 |
 |  | Find |
|
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 use XML 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.
|
Keywords
|
|
Contents
|
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.
The remainder of the paper focuses on the architecture of these client/server
applications to show the intelligent exploitation of XML.
Insurance business
As illustrated in
Figure 1, 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.
Figure 1
. 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.
Figure 2 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.
Figure 2
. 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 the EDIFACT/Telebib2 standard);
- 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.
Previous
Table of Contents
Architectures
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 where XML 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
Figure 3 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 unique XML
message definition. As seen in this figure, the production server gathers
the legacy applications.
Figure 3
. Architectural overview
As detailed below, the application server is made of several parts.
- The message handler interpretes the XML 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 in EDIFACT/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 unique XML structure and sent to the application server where they are processed by the business layer. These same mechanisms apply in the opposite direction.
- 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 usual XML business message is built and sent to the application server. (This architecture is detailed below since it shows clearly the full exploitation of XML 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 business XML 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 the XML format provided the company has developed the appropriate agent application.
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.
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 standard EDIFACT
requests, Internet brokers exploit HTML
and XML standards, whereas some big
brokers' offices have their own proprietary formats, which look like a mix
between EDIFACT 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
pivot XML format.
Furthermore, as highlighted in the previous section, because of the
unique XML 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
This section goes into more detail in the description of these applications
showing that XML 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 of XML.
Why 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.
Figure 4 illustrates the detailed architecture of
a thin client application.
Figure 4
. 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.
The reader can find a lot of information about the benefits of using XML 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 [Vijghen 98].
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 in XML
to interface the business layer, as shown in
Figure 5.
Figure 5
. 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 the XML model;
- 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 the XML syntax, becomes independent of the choice of the external representation format;
- the use of a consistent set of tools and techniques for manipulating the XML 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.
In
Figure 6 it is shown how different parts of the
application can be generated automatically from a unique source of specifications
written in XML.
Figure 6
. XML as a modelling format
Given this approach the functional specifications are gathered within
a single XML (logical) file according
to a well-defined DTD.
Validation against this DTD 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 the XML specifications
that is relevant to the component to be generated.
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 (ie DTDs) of the messages that are exchanged between the client and the server in a typical client/server application;
- 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 layer
Business object modelling
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 with XML instances.
These XML instances have to satisfy
well-defined DTDs in order to be able
to validate their structure and their behaviour before building the application
itself. Behind this aspect of validated modelling, the same XML
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.
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 the OMT
methodology [Rumbaugh 91], the behaviour of the business objects
can be modelled as a state diagram, as illustrated on the next figure for
a typical insurance policy.
Figure 7
. State diagram (partial) of an insurance policy
In the diagram above, an insurance policy changes from one state
to another each time an allowed event is triggered.
During this state transition, specified actions
are executed to achieve the functionality required on this transaction. For
instance, when an insurance policy has been proposed (state Proposed),
it can then be accepted automatically by the system (event Accepted),
refused automatically by the system (event Refused),
or submitted for further analysis by a company agent (event To
be analysed) according to the acceptance criteria of the company.
Accordingly, the next state of the insurance policy will be Accepted, Nil, or Waiting.
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.
The business object state diagrams are specified in XML
through a dedicated user interface. The resulting XML
file is compliant with the state diagram DTD
that allows for the generation of the related documentation and for the run-time
interpretation of the state diagram itself. An XML-based
engine has been built as a COM
component in the business layer that manages the life of all business objects
according to the XML specification
of their state diagram.
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 the new business, accepted (by agent), and refused
(by agent) business events and their attributes.
These business events and their attributes are structured in XML according to a well-defined DTD,
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.
In order to cope with the evolution of the insurance products (ie business
objects), the DTD 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, this DTD 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 the New 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.
Figure 8
. 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.
Figure 9
. 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.
Figure 10 shows details of the structure of the information
that is exchanged between the browser and the Web server in both directions.
Figure 10
. Web client/server messages
Specific to Web-based architectures, data exchanged between the Web
server and the browser can be structured in XML
in order to include an embedded presentation layer: this XML
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
or XSL) and HTML
templates.
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).
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 formal XML
definition. The same tools as those for the business layer are used. The same DTD 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
Whereas information coming from the browser is gathered in one string
structured in XML, information coming
from the server is split into several (logical) files according to their nature.
The DTD 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 in XML. 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 in XML.
-
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 the XML structure and the detailed data frame;
- 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 in HTML; the fields are filled in dynamically by the data mapping tools included in the scripts.
- Presentation - In order to present a common user interface through all applications of the company, the presentation standards have been gathered in a dedicated CSS file.
It should be pointed out that the near birth of XML-companion
standards such as XSL and X-Schemas
will impact the structure of information described above, mainly in the presentation
and scripting areas.
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, the DTDs 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
The conclusions address three different subjects: the benefits of exploiting XML in n
- 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 with n - tier architectures, XML
is the guarantee of a clear software answer to complex e-business interrogations.
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 various DTDs 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 of XML
can be reproduced in other business sectors. Finally, this paper should be
taken as a set of ideas mixing architecture and XML
that could be exploited in everybody's business domain.
Bibliography