Browse Prior Art Database

Language neutral object-key representation

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

Publishing Venue

IBM

Abstract

Disclosed is a mechanism for creating object keys in Java(*) that obey a well-defined format such that those keys can be interpreted outside of a Java environment. A Java-based object container exports servant keys for its objects using Java based methods (notably, serialization). The servant keys form a portion of the overall object key flowed on IIOP requests. The wire format of a serialized Java object can only be reliably interpreted from within a Java application. IBM's CICS(**) TS supports workload management of enterprise beans (which have servant keys as described above) by splitting a logical application server into request receivers and request processors. Request receivers execute in a non-Java environment, receiving incoming IIOP requests and routing work to one or more request processors. Request processors host the Java environment in which the enterprise beans live. To route work correctly, the request receiver needs to be able to interpret the servant key of the target object for the request. However, the request receiver is a non-Java environment, and the serialized form a Java object can only be reliably interpreted from within a Java environment. How can the servant key be changed to allow it to be parsed in a non-Java environment, without breaking other implementations using the existing key format? The solution is to replace the Java serialization used to export the servant key with another Java process called externalization. Externalization allows you to control the wire format of an externalized object, and we use this to write the contents of the servant key in a well-known language neutral manner. In this way the servant key can be parsed from another language environment (in our case PL/I in the request receiver). To avoid version to version migration problems with existing objects using the old key format the solution is implemented as follows: Generating servant keys:

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

Language neutral object-key representation

Disclosed is a mechanism for creating object keys in Java(*) that obey a well-defined format such that those keys can be interpreted outside of a Java environment. A Java-based object container exports servant keys for its objects using Java based methods (notably, serialization). The servant keys form a portion of the overall object key flowed on IIOP requests. The wire format of a serialized Java object can only be reliably interpreted from within a Java application. IBM's CICS(**) TS supports workload management of enterprise beans (which have servant keys as described above) by splitting a logical application server into request receivers and request processors. Request receivers execute in a non-Java environment, receiving incoming IIOP requests and routing work to one or more request processors. Request processors host the Java environment in which the enterprise beans live. To route work correctly, the request receiver needs to be able to interpret the servant key of the target object for the request. However, the request receiver is a non-Java environment, and the serialized form a Java object can only be reliably interpreted from within a Java environment. How can the servant key be changed to allow it to be parsed in a non-Java environment, without breaking other implementations using the existing key format?

     The solution is to replace the Java serialization used to export the servant key with another Java process called externalization. Externalization allows you to control the wire format of an externalized object, and we use this to write the contents of the servant key in a well-known language neutral manner. In this way the servant key can be parsed from another language environment (in our case PL/I in the request receiver).

     To avoid version to version migration problems with existing objects using the old key format the solution is implemented as follow...