Application Architecture Overview
Insure3 a Flexible Approach to
Core Processing Systems for
Property & Casualty Insurers
www.castek.com
Insure3 Claims – Application Architecture
© Castek Software Inc. 2006. All rights reserved worldwide.
This document contains information proprietary to Castek Software Inc. which shall not be
disclosed to third parties nor reproduced in whole or in part for any purpose whatsoever, without
the prior written permission of Castek Software Inc.
© Castek Inc. 2003
ii
Insure3 Claims – Application Architecture
Table of Contents
Introduction .................................................................................................................... 1
Architecture Tier Details.................................................................................................... 3
Presentation / Desktop Tier ..................................................................................... 4
User Services Tier .................................................................................................. 4
Business Services Tier ............................................................................................ 5
Enterprise Integration Tier ...................................................................................... 7
Data Services Tier ................................................................................................ 10
Supporting Technologies ................................................................................................. 11
iii
Insure3 Claims – Application Architecture
INTRODUCTION
Insure3 Claims is a module in Castek’s Insure3 Suite of core business
processing systems for Property & Casualty insurers.
The functional scope of Insure3 Claims is to support insurers’ in performing
the core business activities across the full claims lifecycle, from first notice
through assignment, adjudication, settlement and recoveries.
Insure3 Claims also addresses the non-functional requirements associated
with enterprise-scale, mission critical applications: performance, scalability,
reliability, operability and maintainability. These goals drive the use of a
layered architecture and best practice design patterns for application
development.
The Insure3 Claims system is architected as a thin-client, service-based,
Java 2 Enterprise Edition (J2EE) application. This drives a partitioning of the
application into four basic logical tiers, which can be physically deployed on
one or more computers, plus an Enterprise Integration tier to represent
interaction with other existing systems and external service providers.
The diagram below depicts these tiers and the interactions between them:
Presentation
Desktop
Tier
User
Services
Tier
Business
Services
Tier
Data
Services
Tier
Enterprise
Integration
Tier
Presentation / Desktop Tier
The desktop tier represents the user’s computer and their visual interface
into the Insure3 Claims system. In the Insure3 Claims application this tier
runs on the physical computer that the end user is using. A Web Browser
presents the user interface and allows the end user to interact with the
application.
1
Insure3 Claims – Application Architecture
User Services Tier
The user services tier represents the user’s processing model, in other
words, the way in which they perceive their interaction with the system. This
tier responds to user actions and manipulates the objects in the User
Interface (UI) domain model. User actions are mapped to service requests
that can be satisfied by the Business Services tier, and the corresponding
responses are reflected back in the UI model. Finally, this tier is responsible
for rendering the user interface pages that are displayed in the presentation
tier. In the Insure3 Claims application this tier resides in the Web Server
and Web Container that responds to HTTP posts sent from the Presentation
tier.
Business Services Tier
The business services tier represents the application’s processing model.
This tier responds to triggered business transactions, manipulating the
objects in the Business domain model. In the Insure3 Claims application this
tier resides in the Application Server and the EJB Container that receives
service requests from the User Services tier. Additionally, Insure3 Claims
exposes XML Web Services on top of the Business Services components
which facilitate integration with other applications.
Data Services Tier
The data services tier represents the model of persistent information
maintained by the application. This tier responds to requests for data and
manipulates the columns and rows in the relational database tables which
hold persistent data for Insure3 Claims. In the Insure3 Claims application
this tier is supported by the relational database (RDBMS) server which
responds to data requests from the Business Services tier.
Enterprise Integration Tier
The enterprise integration tier represents the focal point for interactions
between Insure3 Claims and other enterprise systems. For the purposes of
this document these systems could be an insurer’s legacy or existing
systems, external application or information service providers, or other
modules of the Insure3 suite. XML Web Services are used as a standard
mechanism to facilitate easier integration through well defined interfaces.
2
Insure3 Claims – Application Architecture
ARCHITECTURE TIER DETAILS
This section provides additional detail on each of the tiers in the Insure3
Claims application: its role, key responsibilities, interactions, design
approach and supporting technologies.
The diagram below depicts the key pieces within each tier that will be
discussed in this section. The numbered arrows indicate the sequence of
flow in processing a user request originating at the thin client user interface
in the web browser.
Presentation /
Desktop Tier
User Services Tier (Web Server)
Business Services Tier (App Server)
2 / 10
Web Browser
HTTP(S)
1 / 15
Application
Servlet
11
W
3/9
Flow Manager
Desktop
Objects
12
HTTP(S)
14
6a
Business
Event
4/8
SOAP
(XML)
JSP
E
B
S
E
R
V
I
C
E
5
Business
Service
Component
(Session
EJB)
SOAP
(XML)
13
Business
Object
Component
(Entity EJB)
Business
Object
Component
(Entity EJB)
6b
6c
Enterprise Integration Tier
Existing
System
External
Service
Data Services Tier (Database Server)
W
E
B
7
S
E
R
V
I
C
JDBC/
SQL-J
E
3
Insure3 Claims – Application Architecture
Presentation / Desktop Tier
The desktop for the Insure3 Claims, in its “out-of-the-box” configuration, is
any electronic device that is capable of hosting Microsoft Internet Explorer
5.5 (or later). The only two requirements for supporting Insure3 Claims thin
client presentation are the ability render HTML and to execute JavaScript.
Scripting is used on the presentation later for proactive field editing,
creating dialog boxes, and other lightweight activities which improve the
efficiency and responsiveness of the user experience. This limited use of
JavaScript has no adverse effect on the bandwidth requirements of the
Insure3 Claims application.
User Services Tier
The User Services tier for the Insure3 Claims requires a Web Server that is
capable of hosting a Web Container, or delegating to a separate Web
Container, that is compatible with the J2EE 1.2 standards for Java Servlet
2.2 and JavaServer Pages (JSP) 1.1.
A servlet acts as the “Front Controller”, representing the Claims application
on the User Services Tier. Front Controller is a J2EE Design Pattern that
ensures all UI interactions with an application enter through a single “front
door”. This allow the servlet to act as a controller for the application,
delegating responsibilities to the appropriate object to meet a user’s goals
and then directing them to the next page in the application flow. For more
information about the Front Controller design pattern please refer to
http://java.sun.com/blueprints/patterns/FrontController.html.
The controller is one part of a standard presentation design pattern called
Model-View-Controller, usually abbreviated as MVC. MVC segregates the
program logic related to creating the presentation (View) from the object
model itself (Model) and the application control logic (Controller). In the
Insure3 Claims application the Application servlet, Flow Manager and
Business Events represent the controller, the Desktop Objects represent the
Model, and the JSPs represent the View. For more information about the
Model-View-Controller design pattern please refer to
http://java.sun.com/blueprints/patterns/MVC.html.
Desktop objects form the User’s object model. The intent was to create a
set of interacting objects that represent the items used in day-to-day Claims
Processing work. The concept of a desktop was chosen as a metaphor to
help derive the proper set of objects with responsibilities useful in handling
claims. Having an object model that reflects the user’s perspective of claims
handling activities supports the user centered design objective of making
personnel efficient and effective in their use of the system.
Insure3 Claims’ User Services tier was created to be a part of a serviceoriented architecture. This service focus influenced the decisions to make
the Desktop objects stateful, and to assign them responsibility for knowing
transactional boundaries. As an example, when taking a First Notice Of Loss
4
Insure3 Claims – Application Architecture
(FNOL), all of the data available regarding an incident is captured. This
information is held in the Desktop until the ‘Submit FNOL’ action is taken.
Once a Desktop object has reached a transactional boundary, it must
forward a request to the Business Services tier. This communication is
made via an XML message.
The Desktop object model is aware of the user’s HTTP Session that controls
its lifecycle. If the HTTP Session times out, the desktop is able to stream its
state into XML format and send this data to a persistent cache. When the
user logs back on to the system, the cache is searched for desktop state
information; if saved state information is located, the desktop will restore
itself to its previous state and the user can continue their work, without
losing any data.
Business Services Tier
The Business Services tier for the Insure3 Claims executes on an Application
Server that is capable of hosting an EJB Container compatible with the J2EE
1.2 standard for Enterprise JavaBeans 1.1. The EJBs in Insure3 Claims are
separated into two business categories: Business Services and Business
Objects.
Business Services are large-grained services representing business process
areas that are supported within Insure3 Claims such as FNOL and
Adjudication. A Web Service typically fronts a Business Service component
allowing easy integration with disparate technologies and platforms. Each
Business Service is implemented as a Stateless Session Bean which acts as
a façade, delegating work to one or more underlying Business Objects. For
more information about the Session Façade design pattern please refer to
http://java.sun.com/blueprints/patterns/SessionFacade.html.
Business Objects represent the core business domain concepts or physical
entities that make up the Claims processing world, such as Claim File,
Incident, Claim, Reserve and Payment. These objects have responsibility for
performing the actual business processing and enforcing business rules. The
persistence of business information in the underlying data store is
accomplished through interaction with the data services tier. Each Business
Object is implemented in the Claims system as an Entity Bean and its
associated Dependent Objects.
The Business Object is designed to be the smallest atomic object in the
Insure3 Claims system. The word atomic in this context denotes that this
object, as a whole, exists on its own as a business concept. A typical
example would be an Invoice. Yes, there are Invoice Line Items, but they
cannot exist without the Invoice. So Invoice becomes a Business Object,
while Invoice Line Item is a Dependent object.
5
Insure3 Claims – Application Architecture
Configuration and Customization Options
Claims components can be tailored to accommodate different business
needs in different ways. The decision as to which approach is provided for a
given feature is based upon a prioritized assessment of configurability
factors such as the frequency of change, who is expected to make the
change, and the ease of performing the configuration.
1) Business Configurability
Areas that are Business Configurable have been specially designed to
allow maximum flexibility for all configurability factors. Business
Configurable areas are architected using one of two patterns:
•
Data-driven. Use database rows to hold the configurable data,
and provide maintenance screens to allow business or system
administrators easy access to modify this information.
Examples of areas where this level of business configurability
is provided in Insure3 Claims include Code Tables, Exception
Messages, Organization Structure and User Profile. Data
configuration is used for these areas because they can change
dynamically and rapidly. These areas need quick turnover
and claims department staff cannot wait for a specialized
technical resource to be available.
•
Integration with a Rules Engine. Insure3 Claims incorporates
a Rule Engine façade that fronts Rules Engine adapters
compatible with the JSR 94 Java Rules Engine API. Through
this common mechanism it is possible to invoke any rule
configured inside these rules engines from the Business
Services tier. For details on the Java Rules Engine API
specification please refer to
http://www.jcp.org/en/jsr/detail?id=94.
Examples of the types of rules that are configurable via Rules
Engine are Incident and Claim File State Transition edits (i.e.
pre-requisite constraints and triggered actions related to
submitting an Incident or closing a Claim File), Fraud
Indicators, and Automatic Adjuster Assignment.
2) Java Extension Points
In some cases there is not a demonstrated need to make ongoing
rapid changes. Areas that primarily require the ability to support
variation between different insurers’ implementations have a Java
Extension Point. A Java Interface is defined, along with a
configurable way to specify which implementation should be used
behind the interface. In most cases there is a default implementation
6
Insure3 Claims – Application Architecture
provided with the core Insure3 Claims product, and it may be
modified according to a customer’s specific needs during system
implementation.
Examples of this level of customization are numbering schemes (e.g.
Incident, Claim File, Claimant and Claim number) and the Incident to
Claim File Transition algorithm. Java extension points are used for
areas of the system that only need to be tailored when the system is
deployed, or areas that change very rarely. In these cases the
system is either not yet in production or the wait for technical
expertise to carry out a change does not negatively impact business
operations.
Enterprise Integration Tier
The Insure3 Claims application does not exist in a vacuum, but rather is one
player in a company’s insurance process. For example, in order for a First
Notice of Loss to be successfully captured, information must be retrieved
regarding the customer’s Policy. This data does not reside inside the Claims
system, but in the Policy Administration System (PAS). As another
example, when a Claim payment is made the details on the payment are
recorded within the Claims system, but a request must forwarded to a
Payment System to produce a check or trigger an electronic payment.
Traditionally, integration efforts have had to deal with connecting two
completely disparate systems, often written in two different languages,
possibly even running on different platforms. This has caused no lack of
troublesome integration issues, and added complexity and cost to
integration efforts.
Insure3 Claims mitigates these issues by using Web Services as the base
technology in all our incoming and outgoing interfaces. Web Services
combines XML as the data encoding standard with HTTP as the data
transport protocol. Since both the client and the service provider can
communicate using XML we remove the typical impedance mismatch
between different languages and different platforms.
A business object, in the Claims application tier, will represent each
enterprise integration point. As an example, the interface with a Policy
Administration System is handled by a component known as the Policy
Admin Bridge. This component acts as a façade for all access to Policy data.
Behind this interface the integration with one or more Policy systems can be
supported by means of a Policy Admin Proxy object. Each proxy implements
the same interface, which allows the core Claims application to communicate
with multiple systems using the same language. It is the responsibility of
the proxy object to properly form an XML request and to send this to the
known address (URL endpoint) for the Policy Admin web service provider.
7
Insure3 Claims – Application Architecture
Insure3 Claims has identified Enterprise Integration points with a number of
other applications commonly found in an insurer’s systems environment
such as Policy Administration, Customer Management, Document
Management, Payment System, and Vendor Management.
As an example, below is a view of the integration design for Policy
Administration which allows for connecting to Castek’s Insure3 Policy as well
as to one or more other existing Policy Admin Systems.
Insure3 Claims Module
Claim
File
Policy
Snapshot
Policy Admin
System Bridge
Factory
Insure3
Policy
Proxy
Other
Policy
Proxy
Insure3 Policy
Web
Existing
Policy Admin System
Web
Snapshots
The term snapshot is used in the Insure3 Claims system to mean a view of
an entity, for a specific business point in time (“As Of” date), taking into
account any backdated changes entered up to a specific system point in
time (“As At” date). Furthermore this snapshot is for a specific usage,
associating to a unique Claims entity.
The snapshot stores the necessary data to allow Insure3 Claims to
“reconnect” to the enterprise integration system and re-request data from
that system. Typically a snapshot will store an internal Claims system
identifier (which is an Object Identifier or OID), an external system identifier
(which is a Globally Unique Identifier, or GUID, composed of a System
Identifier string and a unique Object Identifier string), plus the “As Of” and
“As At” dates needed to get the correct historical view of the information.
The snapshot mechanism allows for minimizing storage of redundant data
inside the claims system in situations where the external system can reliably
be called upon to provide a consistent view of the external data on demand
in real-time.
8
Insure3 Claims – Application Architecture
Caching Enterprise Data
Data that is retrieved from an Enterprise Integration Web Service can be
expensive to obtain both in terms of response time (latency) and processing
demand on the external system. Insure3 Claims has implemented an XML
caching mechanism in order to optimize the retrieval of the same Policy data
over the duration of a “session”. The length of this session is configurable
and can vary by either the source system identifier or another system
appropriate value.
When a request is received in the Enterprise Integration Tier for a business
object (e.g. Policy) that would normally be satisfied through an integration
with another system, the cache is first checked for a copy of the object
based upon its ID plus “As of” and “as At” dates; when a usable copy is
found in the cache, this snapshot is returned to the Business Services Tier,
avoiding the overhead of making the external service call to the source
system. In addition, the cached copy can be used to ensure that data is still
available for claims processing at times when the source system is
unavailable, or when the source data is no longer in the other system.
ClaimsPath and Service Provider Collaborative
Communications Integration
Castek’s ClaimsPath is an application that connects an insurer and all of the
service providers involved in the claims resolution process, from first notice
of loss to approval of invoices. ClaimsPath allows adjusters to connect and
send assignments from their desktop directly to their service provider
partners in the supply chain, as well as track and document all
communications.
Insure3 Claims’ first focus is on supporting the core claims business
processes within an insurer. ClaimsPath could be used to extend claims
management capabilities to include the insurer’s external supply chain
partners, serving as a Vendor Management and Collaborative
Communication module for Insure3 Claims. The design for integration with
ClaimsPath for service provider communications is consistent the other
explicitly identified external interfaces for Insure3 Claims. Castek has
identified the points in claims business process workflows where the core
Claims system will interact with a Service Provider Collaborative
Communications system and an XML service-based interface has been
specified to facilitate these interactions.
System Listener Framework
The Insure3 Claims product, like any enterprise application, has integration
points to outside systems. Some of these integration points are critical to
the successful handling of Claims, while others are optional and customer
specific.
9
Insure3 Claims – Application Architecture
Insure3 Claims is designed in accordance with the general principals of high
cohesion and loose coupling. Basically this implies limiting the number of
integration points that Insure3 Claims explicitly has to know about. The key
integration points expected for typical claims application implementations
are explicitly supported through specific mechanisms in the Enterprise
Integration Tier.
However, individual insurers may have other integration points. The System
Listener framework provides a common standards-based approach to
supporting these additional interfaces to existing systems and external
entities.
Every major business event completed in Insure3 Claims results in a
Transactional XML (tXML) stream being generated. This XML is published
through the System Listener component. The System Listener pushes this
XML stream out to each Subscriber that has been registered. An
implementation team can write custom Listener Subscriber objects, each of
which will be able to use the data in the tXML for its own purpose.
System Listener
Listener
Claims
Component
System
Event
System
Listener
Component
Existing
System
Listener
Listener
External
Service
Data Services Tier
The Data Services tier for the Insure3 Claims is a Database Server that has a
JDBC 2.0 compliant driver and SQL-J support.
SQL-J is a standard for integrating embedded SQL statements into Java.
SQL-J syntax is simpler and more intuitive that native JDBC, plus it has the
additional benefit of creating static SQL. Static queries are processed in a
much more efficient manner than dynamic queries by the database engine.
Also, bind information stored in the database catalog about the data access
paths used to fulfil these static queries will allow a Database Administrator
to further tune the database for optimal performance.
The information persisted in the Data Services Tier is the most critical part
of the system, and corruption is not an option. In order to provide the
integrity needed, declarative Referential Integrity (RI) is enforced at the
database level. These RI constraints enforce the relationship rules between
database tables, including foreign key validation and cascade deletion.
10
Insure3 Claims – Application Architecture
SUPPORTING TECHNOLOGIES
The Insure3 Claims application has been architected using Java 2 Enterprise
Edition (J2EE), ANSI SQL and XML as the primary enabling technologies.
The widespread adoption of these technology standards for the development
of enterprise applications facilitates integration of Insure3 Claims with a wide
variety of Enterprise Application technologies and third party systems.
The layered service oriented architecture and use of recognized best practice
design patterns, as described earlier in this document, improve the
maintainability of Insure3 Claims, and help to ensure that it can cost
effectively be evolved over an extended lifetime in response to changing
business conditions and priorities.
These technologies also allow maximum flexibility in terms of potential for
porting the application easily across different hardware platforms and
vendor implementations of infrastructure software in the event that an
insurer’s preferred computing environment changes over time.
11