![]() |
If a WebSphere to 3rd-party interoperation scenario is inadequate, you can consider ORB coexistence as an alternative solution. Coexistence refers to "the ability of two different ORB runtime environments to reside and function in the same process". It is important to understand that the Java ORB Portability Interfaces were designed to facilitate a selection of multiple ORBs, with the intent that there would be one ORB loaded at a time. These interfaces were not designed to support multiple ORBs coexisting at the same time.
An advantage of coexistence is that the client does interoperate with the server (using the same ORB or, at least, ORBs from the same vendor) at all levels: IIOP, services, and proprietary features.
However, the runtimes of different ORBs can interact and behave in surprising ways. Older ORBs that define incompatible org.omg.* runtime APIs cannot coexist with WebSphere: the stubs implemented to these APIs do not work in the WebSphere environment. At best, they do not compile; at worst, they compile with hidden side effects. Newer ORB runtimes that use the Java ORB portability interfaces, as defined in the Java language mapping specification for the OMG Interface Definition Language (IDL) 2.3, should coexist better although, even for newer ORBs, some incompatibilities can exist.
To enable coexistence, you can need more handcrafting of code, because the application cannot rely solely on an environment that presupposes one ORB (for example, EJB containers).
Each ORB has its own independent root name context, which may or may not be equivalent. These name contexts are independent, and an object reference available in one should not be expected to be available in the other. However, in theory, an IOR obtained from one naming context should be valid in any ORB.
A coexistent ORB does not propagate service contexts for CORBA services from other ORBs. For example, for the security service, two coexisting ORBs have two different security contexts, authentications, authorizations, and so on.
A 3rd-party client ORB runtime coexisting with a WebSphere EJB server runs independent of the WebSphere EJB container or its controlling infrastructure. Therefore the 3rd-party ORB is unlikely to look for or understand service contexts on the thread of execution, believing itself to be a client residing in its own process. Likewise, the EJB container has no knowledge of the 3rd-party ORB. Thus the WebSphere context is not considered within the execution of a method to an object accessed through a coexisting 3rd-party ORB.
Related tasks... | |
Developing a C++ CORBA client | |
Related concepts... | |
Parent: WebSphere CORBA support | |