Sun Microsystems Inc.

•If there is no OTS transaction context in the IIOP message, the container must follow the behavior described in Section 16.7.

•If there is a valid, complete OTS transaction context in the IIOP message, the container’s required behavior is described in the table below.

•If there is a null transaction context (as defined in section 18.5.2.1) in the IIOP message, the container’s required behavior is described in the table below. Note that the container may not know whether the received transaction context in the IIOP message is valid or null.

EJB containers that accept the OTS transaction context format but still do not support interoperability with other vendors’ client containers must follow the column in the table above for “null or valid OTS transaction context” if the propagated client transaction context’s Xid or the Coordinator object reference indicate that the client belongs to a different vendor’s container.

18.6 Naming Interoperability

This section describes the requirements for supporting interoperable access to naming services for looking up EJBHome object references (interoperability requirement 2 in section 18.3.5).

EJB containers are required to publish EJBHome object references in a CORBA CosNaming service [ 14 ]. The CosNaming service must follow the requirements in the CORBA Interoperable Name Service [ 15 ] for allowing clients to obtain the root NamingContext’s object reference: the root NamingContext should be available at the object key “ NameService”.

All client containers are required to include a JNDI CosNaming service provider which uses IIOP to access the server’s CosNaming service using standard CosNaming APIs. The CosNaming service provider may or may not use the JNDI SPI architecture. The CosNaming service’s root NamingContext should be obtained by creating an object reference from the URL “ corbaname:iiop:<host>:<port>#”, where <host> and <port> provide the location of the server’s CosNaming service, as described in the Interoperable Name Service.