Chapter 9: EAServer EJB Interoperability  Invoking non-EJB components from EJB clients

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:

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:

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:

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.





Copyright © 2005. Sybase Inc. All rights reserved. Invoking non-EJB components from EJB clients