Find JSRs
Submit this Search


Ad Banner
 
 
 
 

JSRs: Java Specification Requests
JSR 64: Financial Services Party Component

This JSR has been Withdrawn
Reason: Withdrawn at the request of the submitter. XML party components for this functionality are being developed under the Customer Profile Exchange (CPex).

Original Java Specification Request (JSR)

Identification | Request | Contributions



Section 1. Identification

Submitting Participant: IBM Corporation


Name of Management Contact Person: Danny Yellin, Director, IBM Financial Services Solutions Architecture

E-Mail Address: dmy@us.ibm.com

Telephone Number: +1 914 642 4631

Fax Number: +1 914 642 5783


Name of Technical Contact Person: William Senn, Senior IT Architect, IBM Financial Services Solutions Architecture

E-Mail Address: William_Senn.Contr@be.ibm.com

Telephone Number: +32 2 655 5767

Fax Number: +32 2 655 5656


List of endorsers for this JSR:

AVSG (Germany)
Gunther Steuten, Managing Director
+49 221 308 1806
gunther_steuten@avsg.de

Barmenia Insurance (Germany)
Hans-Ulrich Moers, Head of Department, Application Development
+49 202 438 2165
h-u.moers@barmenia.de

Castek (Canada)
Michael Sparling, Chief Technology Officer
+1 416 777 2553
MSparlin@castek.com

Genesis Development Corporation
Viktor Ohnjec, VP Global Services
+1 610 429 1553
vohnjec@gendev.com

Progressive Financial Technologies Profit Ltd. (Finland)
Risto Salonen, Chairman
risto.salonen@profithome.com

Synergy Insurance Solutions, Inc.
Bart Krauss, President
+1 215 321 6260
bartkrauss@synergycomponents.com

USAA
Rickey Burks, Executive Director of Enterprise IT Architecture
+1 210 498 6360
rickey.burks@usaa.com

Zurich Financial Services (Switzerland)
Robert Bertschi, Head of IT Strategy Development
+41 (0)1 625 2947
robert.bertschi@zurich.com



Section 2: Request

2.1 Please describe the proposed Specification:

This JSR is a proposal to define an Enterprise Java BeanTM (EJBTM) component interface for the financial services industry's Party domain. This component API is intended to be a standard definition of the properties and behavior of the various persons and organizations (referred to generically as Parties) that exist in the realm of the financial services industry. This Party component's interface would be flexible enough to support all the various persons and types of organizations found in the financial services domain. It is expected that this standard component interface will be implemented multiple times by both financial service organizations and ISVs. The resulting set of Party components should provide financial services organizations with a rich selection of interface compatible Party components.

The typical financial services organization has developed and deployed its operational applications by line of business (LOB). Often times these LOB specific applications were built to meet the processing requirements of a single financial services product or product group. This approach to application development has resulted in redundant and incompatible Party functionality within many financial services enterprises. The recent acceleration in the rate of mergers and takeovers in the financial services industry has also contributed to this problem.

IBM's goals for defining this financial services party component interface are to:

  • Define a standard component interface that provides for the encapsulation all business attributes and behaviors of the Parties involved in the financial services industry.
  • Facilitate a financial services organization's ability to eliminate redundant Party related applications.
  • Facilitate a financial services organization's ability to depict a 'client centric' view of its customers and business partners.
  • Facilitate the financial services industry's ability to share Party information across organizational boundaries.
  • Facilitate a financial services organization's ability to provide on-line self-service to its customers over the Internet.

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Components that implement this specification are intended to execute on Java Application Servers and execute within Enterprise JavaBean (EJB) containers conforming to the J2EE specification.

2.3 What need of the Java community will be addressed by the proposed specification?

This JSR is intended to advance the ability of financial services organizations and Independent Software Vendors (ISVs) to build applications using component based development (CBD) techniques. Today, there exist only incomplete or proprietary specifications of the business components required by financial services organizations. The absence of a robust open financial services component standard makes it difficult for ISVs to build components that have a broad market appeal and consequently limits a financial services organization's choices for buying compatible components. This JSR will also facilitate the ability of customers and business partners of a financial services organization to access party information in a standard way over the Internet.

2.4 Why isn't this need met by existing specifications?

Currently no standardized set of Java components exists for the Financial Services industry.

Information technology standards for the financial services industry have been adopted by several standards organizations, such as the OMG and ACORD. The OMG has defined CORBA compliant interfaces for a Party Management Facility/Component as part of its CORBAFinancials efforts. This work should be included as input to this EJB based Party component definition. Thus far, the ACORD standards focus on the business processes needed to support insurance producers (agencies, brokers, etc.). The early ACORD standards included standardized paper forms for insurance producers and standardized Electronic Data Interchange (EDI) formats for sending producer and policy data to insurance carriers. More recently, ACORD has developed JavaTM based versions of these standards called JLife and JObjX. To date, the ACORD efforts have not had a 'component' focus. However, the business functionality defined by the ACORD standard in the Party area should be accommodated by the proposed EJB component interface.

2.5 Please give a short description of the underlying technology or technologies:

IBM proposes using its Insurance Application Architecture (IAA) as the underlying technology for this EJB Party component interface specification. IAA was originally developed by 40 insurance companies and is now licensed by over 100 financial services and software development companies worldwide. One of the central themes of IAA Edition 4 has been the encapsulation of attributes and behavior into distinct logical packages of classes. These class packages are subsequently arranged into distinct physical components. Another central theme of IAA has been to architect flexible applications that have the capability of supporting multiple lines of business. Combining these two themes has resulted in the definition of a powerful and flexible logical object model for insurance business components. Portions of this logical model has been successfully implemented by several insurance carriers. These carriers have all used different implementation technologies and targeted different lines of business. These successes have proven the viability and flexibility of the IAA object oriented design model for insurance business components.

IAA's object oriented logical domain model is called the Business Object Model (BOM). The BOM was developed to offer generic and flexible behavior that can be generally applied across the entire financial services industry. The BOM contains 18 packages each of which models a unique domain. Classes from several of these BOM's packages have been grouped together into a single physical Party component. Below is a description of the functionality provided by the Party component listed by logical package.

  • Party Package - The Party package covers the attributes and behavior of persons and all types of organizations. It also covers the roles these persons and organizations can play in respect to other persons or organizations and, more widely, to any object.
  • Location Package - The portion of the Location package contained in the Party component covers the attributes and behavior of contact points. Contact points are used to establish a destination for communications. Contact points can be defined for persons or organizations. The Location package supports different types and usage of contact points. For example, work telephone number, personal e-mail address, vacation PO box, home postal address, emergency care of addresses, etc.
  • Activity Package - The Activity package contains classes that makes it possible to define the different activities that are of interest to an insurance company. The Party package contains Activity classes to describe general activities performed by a person, an organization, or a role played by a person or organization. For example, a party Activity can be used to represent the line of business that an organization is in or the day-to-day services provided by an organizational unit within the company. The Activity package is also used to track the occupations, hobbies and habits of individuals.
  • Contract Package - The Party component contains classes from the Contract package to track employment contracts, service contracts, re-insurance contracts, etc.
  • Registration Package - The Party component contains Registration package classes in order to define different types of official registrations and the role of each of these types of registration in the insurance business. Registrations are of interest to insurance companies because they provide evidence that may be required by the company in order to process a certain customer request, to provide coverage, and so on. Examples of registrations include; marriage licenses, birth certificates, company registrations, driving licenses, death certificates, etc.
  • Condition Package - The Party component contains Condition package classes in order to provide the ability to define the conditions of people and organizations. This capability is used, for example, to record a person's financial status, etc.
  • Category Package - The Party component contains Category package classes in order to provide the ability to define a dynamic grouping of objects by defining sets and allowing an object to belong to multiple sets at a time.
  • Type Package - The Party component contains Type package classes in order to define the types of objects that are relevant to an insurance company without affecting the inheritance structure of the class of the objects.

IAA's Business Object Model and Party Component definitions represent a considerable investment of IBM's time and money. IBM understands that a certain amount of the intellectual property (IP) contained in these assets will be reflected in the interface of the EJB Financial Services Party Component. However, IBM does intend to maintain ownership of the remaining IAA BOM and Component Model IP and does wish to protect its investment in these assets. For this reason, IBM must request that all specification committee members either be IAA licensees or sign a nondisclosure contract to protect IBM's IP. In turn, IBM will sign the appropriate nondisclosure documents to protect any IP that other committee members disclose to the specification committee.

2.6 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

IBM proposes that the package name of 'javax.financials.party' be used for this JavaTM specification.

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

For performance reasons, some portion of the Financial Services Party Component may be implemented using native code.

2.8 Are there any security issues that cannot be addressed by the current security model?

The Financial Services Party Component will require the collaboration of security services. The specification will define these security service dependencies, however, the specification of the interface to these security services is considered to be outside the scope of this specification.

2.9 Are there any internationalization or localization issues?

The Financial Services Party Component is intended to be available for use internationally. Therefore, the component interface specification should support the internationalization features of the Java language.

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

We believe this is the first Java Specification Request submitted to the Java Community Process that proposes specifying a component interface to handle the Parties found in the Financial Services industry. Thus, we do not expect this specification to overlap with other existing JavaTM specifications.



Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

The following BOM related materials are available as part of the IAA Edition 4.1 Object Model Suite:

  • BOM Rational Rose '98 MDL and CAT files
  • BOM Users Guide
  • BOM Reference Manual
  • IAA Component Model Users Guide (not complete)
All documentation is available in PDF Version 3 format.

3.2 Explanation of how these items might be used as a starting point for the work.

The IAA Edition 4.1 BOM defines a generic object model for representing the real world objects found in the insurance industry problem domain. Using the BOM and associated documentation as the starting point, we suggest the following overall steps be taken to specify the EJB Party Component interface:

  • Define a robust set of use cases that the component must support.
  • Identify the various component interfaces that need to be defined.
  • Identify the BOM classes, operations and events that are available to support the required component interfaces.
  • Use specification committee input to enhance the BOM definitions as required to support the required interfaces.
  • Define the properties, method signatures, and events of each interface.
  • Document the component's collaboration dependencies.