Example 3: Exposing a Session EJB As a CORBA Component


You can expose a session EJB as a CORBA component by configuring with a Geronimo-specific deployment plan for the application. This example shows how to configure and deploy such an EJB component.

To keep things simple, the EAR application that is used is once again the authors list application from Chapter 12.

This example does the following:

  • Creates a geronimo-application.xml plan to deploy the AuthorsBean EJB as a CORBA component

  • Includes a CORBA client application, running under the Geronimo client application container, to test the exposed EJB

One of the most important things to get just right when exposing a CORBA component is the access security configuration. Geronimo CORBA supports CSIv2, explained next.

CORBA 2.3 Security

To implement a secure communication channel between CORBA components over heterogeneous networks, the CORBA 2.3 specification includes Common Security Interoperability, Version 2 (CSIv2). CSIv2 is a comprehensive specification that can be used to negotiate and implement application-specific levels of security for distributed systems. The unique property of CSIv2 is that it can be implemented over a large variety of transport layer protocols and requires only a single message exchange to establish a security context. Geronimo’s CORBA support includes support of CSIv2.

Geronimo Support for CSIv2 Security

The CSIv2 implementation in Geronimo is encapsulated in several GBeans. These GBeans are a mandatory part of Geronimo’s CORBA communications stack. You must configure these CSIv2 GBeans appropriately when exposing/deploying CORBA components in Geronimo.

Figure 14-12 shows the security interactions in a CORBA 2.3 network.

image from book
Figure 14-12: The CORBA CSIv2 implementation

In Figure 14-12, the server side of the CORBA implementation has a Target Security Service (TSS) GBean. The client side of the CORBA implementation has a Client Security Service (CSS). Together, the CSS and TSS GBeans implement the CSIv2 negotiation of security required. Figure 14-12 also shows how the CSIv2 implementation can achieve required data secrecy, integrity, authentication, and authorization requirements.

Configuring Server-Side CSIv2 Security

Security negotiation occurs between Geronimo CSS and TSS components. To expose an EJB as a CORBA component, you must select the appropriate TSS component instance. Each TSS component instance implements a certain level of required security. Table 14-8 shows the available TSS implementation in Geronimo 1.1.

Table 14-8: CSIv2 TSS GBean Available in Geronimo 1.1
Open table as spreadsheet

TSS GBean Name

Security Enforced

IdenityTokenNoSecurity

The TSS implementation requires no additional CSIv2 security enforcement. Communication is over standard TCP channel.

SSLClientCert

Client is required to authenticate via client certificate. Communication is over SSL for data encryption and integrity.

SSLClientPassword

Client is required to authenticate with password. Communication is over SSL for data encryption and integrity.

SSLClientCertIdentityToken

Combines client certificate authentication with identity token. Communication is over SSL for data encryption and integrity.

SSLIdentityToken

No additional client authentication required beyond an identity token. Communication is over SSL for data encryption and integrity.

In the geronimo-application.xml plan, as a child element of the <session> bean, the <tss-link> element indicates to the Geronimo server your selected TSS level of security. The following listing shows the use of the <tss-link> element in the example.

 <?xml version="1.0" encoding="UTF-8"?> <application     xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-1.1">       <environment>       <moduleId>         <groupId>geronimo</groupId>         <artifactId>progeroncorba</artifactId>         <version>1.0</version>         <type>car</type>       </moduleId>       <dependencies>         <dependency>           <groupId>geronimo</groupId>           <artifactId>j2ee-corba</artifactId>           <type>car</type>         </dependency>       </dependencies>     </environment>     <module>         <ejb>authors-ejbs.jar</ejb>         <openejb-jar             xmlns="http://www.openejb.org/xml/ns/openejb-jar-2.1">             <enterprise-beans>                <session>                    <ejb-name>AuthorEJB</ejb-name>                    <jndi-name>AuthorEJB</jndi-name>                    <tss-link>IdentityTokenNoSecurity</tss-link>                </session>             </enterprise-beans>         </openejb-jar>     </module>     ...

In this example, the TSS component selected by the <tss-link> component will allow client access with no security other than an identity token. There is no encryption of data sent over the network.

Configuring Client-Side CSIv2 Security

On the client side, you will need to select a CSS component instance. Table 14-9 shows the available instances with Geronimo 1.1.

Table 14-9: CSIv2 CSS GBean Available in Geronimo 1.1
Open table as spreadsheet

CSS GBean Name

Security Enforced

NoSecurity

Attempt to access server with no security. Data will be sent over unencrypted TCP.

NoSecurityIdentityTokenPrincipal

Attempt to access server with an identity token. Issue the token based on the security principal.

NoSecurityIdentityTokenCert

Attempt to access server with an identity token scheme. Issue the token based on a client certificate.

SSLIdentityTokenCert

Access server with identity token based on client certificate. Use SSL for data communications.

SSLIdentityTokenPrincipal

Access server with identity token based on security principal. Use SSL for data communications.

SSLClientPassword

Authenticate to server with password. Use SSL for data communications.

SSLClientCert

Authenticate to server with client certificate. Use SSL for data communications.

The selection of CSS GBean is specified in the deployment plan for the client application.

For Geronimo release 1.1, the CSS and TSS GBeans in Table 14-8 and 14-9 are actually not preconfigured in the geronimo/j2ee-corba/1.1/car or the geronimo/client-corba/1.1/car modules. Instead, you must configure these GBeans explicitly in your deployment plans. See the source code download for details on this GBean configuration. This is likely to change in a future subrelease, as Geronimo adapts to other ORBs beyond the SUN JDK ORB.

CORBA Client Support

CORBA client can be written in any programming language on any supported OS or hardware platform. To access the Geronimo hosted CORBA component from another system, you need to do the following:

  • Obtain a CORBA 2.3–compatible ORB on that system that supports CSIv2

  • Generate a CORBA IDL from the Java access interface, and then use the IDL to generate a language-specific binding on the supported platform

The creation of a client on a non-Java platform is out of the scope of this example. In this example, things are kept simple by using a Geronimo-hosted client.

A Geronimo-hosted CORBA client can take advantage of the following:

  • Application client container support provided by Geronimo for its deployment and configuration

  • JNDI-based CORBA naming service lookup provided by the container

  • RMI-IIOP support, eliminating the need to work through IDL or CORBA Java binding

The client application in this example takes full advantage of Geronimo as a client container, simplifying the configuration and coding.

Improtant

As of Geronimo 1.1, the client container support will only work when the client is running on the same machine as the server. This restriction will be eliminated in future versions of Geronimo, check the release notes for more information.

The geronimo-application.xml configures the client application in a <module> element, including the selection of CSS component. The following listing shows the client application configuration in this deployment plan.

     ...    <module>         <java>authors-clientapp.jar</java>         <application-client xmlns=" http://geronimo.apache.org/xml/ns/j2ee/application-client-1.1"">            <client-environment>              <moduleId>                <groupId>wrox</groupId>                <artifactId>corbaclient</artifactId>                <version>1.0</version>                <type>car</type>              </moduleId>              <dependencies>                <dependency>                  <groupId>geronimo</groupId>                  <artifactId>client-corba</artifactId>                  <type>car</type>                </dependency>              </dependencies>             </client-environment>             <server-environment>         </server-environment>            <ejb-ref>                <ref-name>AuthorServer</ref-name>                <ns-corbaloc>corbaloc::localhost:1050/NameService</ns-corbaloc>                <name>AuthorListEJB</name>             <css-link>NoSecurity</css-link>             </ejb-ref>          <realm-name>client-properties-realm</realm-name>             <callback-handler> com.ibm.dw.geronimo.corba.client.SecurityCallbackHandler             </callback-handler>         </application-client>     </module>       ...

The highlighted line shows the selection of the CSS GBean instance via the <css-link> element. Note that the <ejb-ref> reference the AuthorListEJB defined in the server’s configuration. This allows the client code to look up the EJB via the <ref-name> using JNDI.

Specifying Dependency on Parent Modules

To ensure that you can find the TSS and CSS GBean component when you deploy the example, you must ensure that you set <dependency> in the environment to the appropriate CORBA configurations. More specifically, in this example, the EJB server component has a parent module of geronimo/ j2ee-corba/1.1/car. This parent configuration is where the TSS beans are configured.

 <application     xmlns="http://geronimo.apache.org/xml/ns/j2ee/application-1.1">       <environment>       <moduleId>         <groupId>geronimo</groupId>         <artifactId>progeroncorba</artifactId>         <version>1.0</version>         <type>car</type>       </moduleId>       <dependencies>         <dependency>           <groupId>geronimo</groupId>           <artifactId>j2ee-corba</artifactId>           <type>car</type>         </dependency>       </dependencies>     </environment>

For the client, the dependency is geronimo/client-corba/1.1/car.

 <application-client xmlns=" http://geronimo.apache.org/xml/ns/j2ee/application- client-1.1"">            <client-environment>              <moduleId>                <groupId>wrox</groupId>                <artifactId>progeroncorbaclient</artifactId>                <version>1.0</version>                <type>car</type>              </moduleId>              <dependencies>                <dependency>                  <groupId>geronimo</groupId>                  <artifactId>client-corba</artifactId>                  <type>car</type>                </dependency>              </dependencies>             </client-environment>

This is all that is required to expose the EJB for CORBA access and to configure the client.

Configuring ORB Parameters via config.xml

The CORBA support components in Geronimo are GBeans. Like all other GBeans, they have configuration attributes that can be overridden in the config.xml file.

The standard config.xml comes with default values for CORBA components that work well with SUN JDK 1.4’s built-in ORB (supported by Geronimo 1.1).

For example, the TCP port used by the CORBA Naming Service can be modified in config.xml (with Geronimo server turned off) by modifying the following bolded lines.

 ... <module load="false" name="geronimo/j2ee-corba/1.1/car">     <gbean name="NameServer">       <attribute name="dbDir">var/cosnaming.db</attribute>       <attribute name="port">1050</attribute>     </gbean>     <gbean name="Server">       <attribute name="args">-ORBInitRef, NameService=corbaloc::localhost:1050/NameService</attribute>     </gbean>     <gbean name="UnprotectedServer">       <attribute name="args">-ORBInitRef, NameService=corbaloc::localhost:1050/NameService</attribute>     </gbean>     </module> ...

Trying Out the Example

The geronimo/j2ee-corba/1.1/car module is not started by default in Geronimo 1.1. You must start this before you can deploy the example. To start this module, you can do one of the following:

  • Use the Web console or command-line deployer to start the module while the server is running, and then restart the Geronimo server

  • Shut down the server, edit the config.xml file to remove the load=false attribute on the module, and then start the Geronimo server

In either case, you should see the geronimo/j2ee-corba/1.1/car module started (on the Web console, or use the list-module command of the deployer) after the restart of the Geronimo server.

To deploy the authorlister.ear archive, where both the server and client are bundled, you can use the following command:

deploy deploy authorlister.ear geronimo-application.xml

Or, you can use the Web console to deploy authorlister.ear with the geronimo-applications .xml plan.

Note that all of the CORBA-specific configurations are isolated to the geronimo-application.xml deployment plan. This keeps the authorlister.ear generic and deployable on other servers. Since the geronimo-application.xml is an external deployment plan, you can, in fact, use any name for the file.

To run the client application, use the following command:

java -jar bin/client.jar wrox/progeroncorbaclient/1.0/car

You should see the client accessing the CORBA bean over RMI-IIOP.




Professional Apache Geronimo
Professional Apache Geronimo (Wrox Professional Guides)
ISBN: 0471785431
EAN: 2147483647
Year: 2004
Pages: 148

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net