Chapter 9: EAServer EJB Interoperability

Intervendor EJB interoperability

EAServer complies with the interoperability requirements in the EJB 2.0 specification, allowing you to interoperate with EJB 2.0 compliant servers from other vendors. There are two approaches to inter-vendor interoperability:

Using CORBA 2.2 client interfaces This option allows interoperability between EAServer and other vendors that support CORBA 2.2.

Using the EAServer Java or C++ CORBA client model, you can call another vendor’s CORBA 2.2 compliant application server (the server must support IIOP 1.0 or 1.1). Similarly, you can use another vendor’s CORBA 2.2 compliant client ORB to call any component hosted by EAServer (the client ORB must support IIOP 1.0 or 1.1).

This option is simpler than the EJB 2.0 RMI/IIOP option, but does not support some EJB 2.0 interoperability features such as transaction and security context propagation.
Using EJB 2.0 RMI/IIOP interoperability This option allows interoperability between EJB 2.0 compliant application servers, but can be more complex to program, particularly in languages other than Java.

RMI/IIOP interoperability depends on CORBA 2.3 IDL Valuetypes, which has the following implications:
- Valuetypes and other IIOP 1.3 features cannot be used by pre-CORBA-2.3 client ORBs.
- At the time of this writing, standard support for RMI/IIOP clients (specifically Valuetypes) in languages other than Java is lacking.
RMI/IIOP interoperability supports some features not supported by CORBA 2.2 interoperability, such as:
- Interoperable naming, when using the interoperable name formats described in “Interoperable naming URLs”.
- Transaction propagation, when using the OTS transaction model as described in “Transaction interoperability”
- Security context propagation in accordance with the CSIv2 requirements outlined in the EJB 2.0 specification. For more information on this feature, see “Intercomponent authentication for EJB 2.0 components” in the EAServer Security Administration and Programming Guide.
- Parameter and exception type inheritance and null value propagation in method invocations.

EAServer supports RMI/IIOP interoperability for EJB clients and components, without using CORBA 2.3 Valuetypes in the IDL interface definitions. The generated stub and skeleton code can marshall parameters in accord with the RMI/IIOP requirements, even though the IDL does not use Valuetypes. Since the IDL does not use Valuetypes, EAServer EJB components remain compatible with components of other types and with CORBA 2.2 clients.

EAServer can simultaneously support RMI/IIOP and CORBA 2.2 clients. The client’s interoperability requirements are automatically detected at run time. To use RMI/IIOP from another vendor’s EJB 2.0 container, you must use the EAServer classes described in “Classes for RMI/IIOP connections from third-party containers”.

Interoperable naming URLs

You can use interoperable naming URLs for EJB 2.0 components and clients. Using an interoperable naming URL causes the EAServer runtime to use the RMI/IIOP protocol, which is required for EJB 2.0 interoperability features such as caller credential propagation. For more information on interoperable naming services, see Chapter 5, “Naming Services,” in the EAServer System Administration Guide.

Interoperable naming URLs for EJB clients

To use RMI/IIOP as the network protocol, an EJB client must specify a corbaname interoperable naming URL as the value of the JNDI context’s PROVIDER_URL property. When using corbaname URLs, you must specify the user name and password using the JAAS API, as described in “JAAS on the client” in Chapter 11, “Using the JAAS API,” in the EAServer Security Administration and Programming Guide.

When using the EAServer EJB client runtime, the URL syntax is:

corbaname:iiop:ver@host:port/NameService[rmi]

Or to use the default IIOP version number:

corbaname:iiop:host:port/NameService[rmi]

Where:

ver	Is an optional version number. Supported versions are 1.1 and 1.2. The default version is 1.1, unless you append the `#rmi:/` suffix, which forces the IIOP version to 1.2.
host	Is the server host name.
port	Is the server’s IIOP port number.
[rmi]	Is the optional naming prefix `#rmi:/`, which specifies RMI Valuetype semantics. Valuetype semantics are required to propagate null parameter values in method calls. Using this option forces the IIOP version to 1.2.

For example, this URL specifies a connection to the host moxy at port 9000, using IIOP 1.2 with Valuetype semantics:

corbaname:iiop:1.2@moxy:9000/NameService#rmi:/

As another example, this URL specifies a connection to the host moxy at port 9000, using IIOP 1.2 without Valuetype semantics:

corbaname:iiop:1.2@moxy:9000/NameService

This URL identifies a connection to the host moxy at port 9000, using IIOP 1.1:

corbaname:iiop:moxy:9000/NameService

The string /NameService is optional in all corbaname URLs. For example:

corbaname:iiop:1.2@moxy:9000#rmi:/

Or:

corbaname:iiop:1.2@moxy:9000

Interoperable naming URLs for EJB references

Servlets, JSPs, application clients, and EJB 2.0 components can use EJB references to alias names used to resolve EJB home interfaces in the implementation code. To use RMI/IIOP for invocations of the called component, you must specify a corbaname URL in the Link Value setting for the EJB reference.

To specify a name server address and IIOP version number, use a URL of the form:

corbaname:iiop:ver@host:port/NameService#[rmi]comp-name

To specify a name server address and use the default IIOP version of 1.1:

corbaname:iiop:host:port/NameService#comp-name

To specify a component that is installed in the same server or cluster:

corbaname:rir:/NameService#[rmi]comp-name

Where:

ver	Is an optional version number. The default version is 1.1. Supported versions are 1.1 and 1.2.
host	Is the server host name.
port	Is the server’s IIOP port number.
[rmi]	Is the optional naming prefix `rmi:/`, which specifies RMI Valuetype semantics. Valuetype semantics are required to propagate null parameter values in method calls. This option requires IIOP 1.2. When connecting to another vendor’s name service, the service may require a different naming prefix to specify RMI Valuetype semantics.
comp-name	Is the name with which the component is bound to the name service. For EAServer components, this is the value of the `com.sybase.jaguar.component.bind.naming` property, which defaults to package-name/component-name if not set.

For example, this URL references a component named Finance/Accounting, using the local name service and IIOP 1.2 with Valuetype semantics:

corbaname:rir:/NameService#rmi:/Finance/Accounting

This URL references the same component name, running on moxy at port 9000, using IIOP 1.2 and RMI Valuetype semantics:

corbaname:iiop:1.2@moxy:9000/NameService#rmi:/Finance/Accounting

The string /NameService is optional in all corbaname URLs. For example:

corbaname:rir:#rmi:/Finance/Accounting

Classes for RMI/IIOP connections from third-party containers

To connect to EAServer using another vendor’s EJB 2.0 client, application client, EJB, or servlet or JSP within a Web container, add easportable.jar to the CLASSPATH. easportable.jar is located in the EAServer java\lib subdirectory and contains the classes in the com.sybase.ejb.portable package. These classes are:

EJBMetaData
Handle
HomeHandle

Adding easportable.jar to the CLASSPATH enables you to call these methods on a javax.ejb.EJBHome or javax.ejb.EJBObject instance residing on EAServer:

getEJBMetadata
getHandle
getHomeHandle

To call EJB components in EAServer from a third-party container, the EJBs must have been deployed from an EJB-JAR file or EAR file with the Use Interoperable Naming option checked.