 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 64: Financial Services Party Component
This JSR has been Withdrawn 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) Barmenia Insurance (Germany) Castek (Canada) Genesis Development Corporation Progressive Financial Technologies Profit Ltd. (Finland) Synergy Insurance Solutions, Inc. USAA Zurich Financial Services (Switzerland) 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:
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.
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:
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:
|
