Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Enterprise JavaBeans™ Specification, Version 2.0 - Sun Microsystems.pdf
Скачиваний:
14
Добавлен:
24.05.2014
Размер:
2.71 Mб
Скачать

Sun Microsystems Inc.

Support for Distribution and Interoperability

Enterprise JavaBeans 2.0, Public Draft

Remote Invocation Interoperability

6.Propagation of the Internet or intranet user’s principal name for invocations on enterprise beans from web or EJB containers when the client and server containers have a trust relationship (scenarios 1,3,4), described in section 18.7.

18.4Remote Invocation Interoperability

This section describes the interoperability mechanisms that enable remote invocations on EJBObject and EJBHome object references when client containers and EJB containers are provided by different vendors. This is needed to satisfy interoperability requirement 1 in section 18.3.5.

All EJB, web, and application client containers must support the IIOP 1.2 protocol, which is part of the CORBA 2.3.1 specification [ 13 ] from the OMG [28]. Containers may additionally support vendor-spe- cific protocols.

CORBA Interoperable Object References (IORs) for EJBObject and EJBHome object references must include the GIOP version number 1.2. The IIOP infrastructure in all J2EE containers must be able to accept fragmented GIOP messages, although sending fragmented messages is optional. Bidirectional GIOP messages may optionally be supported by J2EE clients and servers: if a J2EE server receives an IIOP message from a client which contains the BiDirIIOPServiceContext structure, it may or may not use the same connection for sending requests back to the client.

Since Java applications use Unicode characters by default, J2EE containers are required to use the Unicode UTF16 format as the default code set for transmission of character and string data (in the IDL wchar and wstring datatypes), in absence of any code set negotiation. J2EE containers may optionally support additional code sets using the code set negotiation feature of IIOP1.2.

EJB containers are required to translate Java types to their on-the-wire representation in IIOP messages using the Java Language to IDL mapping specification [ 7 ] with the wire formats for IDL types as described in the GIOP specification in CORBA 2.3. The following subsections describe the mapping details for Java types.

18.4.1 Mapping Java Remote Interfaces to IDL

For each session bean or entity bean that is deployed in a container, there are two Java RMI remote interfaces - the bean’s home interface and the bean’s remote interface. The Java Language to IDL Mapping specificatio n [ 7 ] describes precisely how these remote interfaces are mapped to IDL. This mapping to IDL is typically implicit when Java RMI over IIOP is used to invoke enterprise beans. Although there may be a CORBA object for each EJBObject or EJBHome object, J2EE clients use only the Java RMI APIs to invoke enterprise beans.

[28]CORBA APIs and earlier versions of the IIOP protocol are already included in the J2SE1.2, J2SE1.3 and J2EE1.2 platforms through JavaIDL and RMI-IIOP.

5/31/00

362

Sun Microsystems Inc

Remote Invocation Interoperability

Enterprise JavaBeans 2.0, Public Draft

Support for Distribution and Interoperability

18.4.2 Mapping value objects to IDL

The Java interfaces that are passed by value during remote invocations on enterprise beans are javax.ejb.Handle, javax.ejb.HomeHandle and javax.ejb.EJBMetaData. The Enumeration or Collection objects returned by entity bean finder methods are value types. There may also be application-specific value types that are passed as parameters or return values on enterprise bean invocations. In addition, several Java exception classes that are thrown by remote methods also result in concrete IDL value types. All these value types are mapped to IDL abstract value types or abstract interfaces using the rules in the Java Language to IDL Mapping.

18.4.3 Mapping of system exceptions

Java system exceptions, including the java.rmi.RemoteException and its subclasses, may be thrown by the EJB container. If the client’s invocation was made over IIOP, the EJB server is required to map these exceptions to CORBA system exceptions and send them in the IIOP reply message to the client, as specified in the following table

System exception thrown by EJB

CORBA system exception

container

received by client ORB

 

 

 

 

javax.transaction.

TRANSACTION_ROLLEDBACK

TransactionRolledbackException

 

 

 

javax.transaction.

TRANSACTION_REQUIRED

TransactionRequiredException

 

 

 

javax.transaction.

INVALID_TRANSACTION

InvalidTransactionException

 

 

 

java.rmi.NoSuchObjectException

OBJECT_NOT_EXIST

 

 

java.rmi.AccessException

NO_PERMISSION

 

 

java.rmi.MarshalException

MARSHAL

 

 

java.rmi.RemoteException

UNKNOWN

 

 

For EJB clients, the ORB’s unmarshaling machinery will map CORBA system exceptions received in the IIOP reply message to the appropriate Java exception as specified in the Java Language to IDL mapping. This results in the original Java exception being received by the client J2EE component.

363

5/31/00