Browse Prior Art Database

A reuse mechanism for object containers

IP.com Disclosure Number: IPCOM000014392D
Original Publication Date: 2001-Mar-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 68K

Publishing Venue

IBM

Abstract

Disclosed is a mechanism which allows a single implementation of some new 'functionality' (e.g. EJB) to be shared across a family of differing application servers. Given a family of application servers providing differing qualities of service, and supporting different platforms, and given new functionality which is to be introduced across all of those application servers, it is desirable to write the function (and its associated tooling) once only and have it reused in all of the application server runtimes. In this case, the applications servers are the WebSphere(*) application server (advanced and enterprise editions, across all platforms) and CICS(**) TS 2.1. The function to be introduced is an Enterprise JavaBeans container. Reusing the container implementation across all the runtimes ensures a consistent interpretation of the EJB specification across them, and provides for a single set of tooling (VisualAge for Java(***), Enterprise Edition) that can work with all family members. The container itself is complex, and each target application server has its own environment, assumptions and APIs. How can the container be written in an application-server independent manner and then hosted in a multiplicity of application servers.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 54% of the total text.

Page 1 of 2

A reuse mechanism for object containers

Disclosed is a mechanism which allows a single implementation of some new 'functionality' (e.g. EJB) to be shared across a family of differing application servers.

     Given a family of application servers providing differing qualities of service, and supporting different platforms, and given new functionality which is to be introduced across all of those application servers, it is desirable to write the function (and its associated tooling) once only and have it reused in all of the application server runtimes.

     In this case, the applications servers are the WebSphere(*) application server (advanced and enterprise editions, across all platforms) and CICS(**) TS 2.1. The function to be introduced is an Enterprise JavaBeans container. Reusing the container implementation across all the runtimes ensures a consistent interpretation of the EJB specification across them, and provides for a single set of tooling (VisualAge for Java(***), Enterprise Edition) that can work with all family members.

     The container itself is complex, and each target application server has its own environment, assumptions and APIs. How can the container be written in an application-server independent manner and then hosted in a multiplicity of application servers.

     The solution involves the adaptation of the common component (the EJB container) to work with three runtime-neutral sets of interfaces. Whenever the container requires a server-specific service (for example, transaction management, persistence management, meta-data storage) an interface is defined as part of the "Container-Server Interface" or CSI. The application server hosting the container provides a collaborator that implements the interface. When the con...