| Chapter 17. CORBA in Geronimo [DRAFT (1.0)] | ||
|---|---|---|
 | Part III. J2EE Applications on Geronimo |  |
| Chapter 17. CORBA in Geronimo [DRAFT (1.0)] | ||
|---|---|---|
| | Part III. J2EE Applications on Geronimo | |
Table of Contents
Geronimo's CORBA features focus on EJBs. Session Bean and Entity Beans can be exposed via CORBA, so that they can be invoked directly from remote CORBA clients. Any J2EE component in Geronimo can also invoke EJBs via CORBA. This is not generally useful for client code in Geronimo to access EJBs in Geronimo -- it's easier to use the standard RMI interface. However, it can be used for client code in Geronimo to access EJBs in a Geronimo server running on a different machine, or to access EJBs running in a different J2EE application server, as well as allowing non-J2EE or non-Geronimo clients to access EJBs running in Geronimo.
![[Note]](images/note.png) | Note |
|---|---|
The CORBA features in Geronimo 1.0 only work in the Sun 1.4.2 JVM -- no CORBA features are available when running under Java 5. IBM's WebSphere CE (which is based on Geronimo) also supports IBM JVMs. | |
Every participant in a CORBA communication needs to have an ORB available, which mediates the communication between the local objects and the remote ORB. In addition, each participant typically needs a naming service, in which local CORBA services can be registered and made available to remote clients.
The Java VM includes both an ORB and a CORBA naming service. Geronimo uses both the ORB and the naming service included in the JVM. While this is convenient in terms of requiring fewer third-party libraries, it has tied Geronimo's CORBA features to the Sun 1.4.2 series an JVMs. The Java 5 CORBA features as well as other JVM vendors' CORBA implementation are configured and operated differently, and therefore are not compatible.
![[Tip]](images/tip.png) | Tip |
|---|---|
A more portable CORBA implementation will be included in a future Geronimo release, reducing the dependency on this specific Java VM. | |
One key thing to be aware of is that each side of a CORBA communication is associated with a security service. This is known as the CSS for a CORBA client (Client Security Service) and the TSS for a CORBA server (Target Security Service). In practice, this means that an EJB exposed via CORBA must be associated with a TSS, and an EJB reference to a remote CORBA EJB must be associated with a CSS.
Note that any number of components may share the same TSS or CSS -- there can be one TSS per EJB and one CSS per EJB reference, or many EJBs or EJB references can share the same security services. That much is entirely up to the developer. As well, the TSS and CSS may be deployed at any level in Geronimo -- at the server level, or packaged within an application or module. Normally, however, the TSS or CSS is included in the EAR or module where the CORBA settings are configured. That way the settings are kept close to the components that use them, and each component can use the most appropriate security configuration.
As far as the responsibilities of a security service, the TSS needs to be configured to handle the various types of security information that an arbitrary caller may provide, while the CSS needs to be configured to provide the security information that the remote server expects. This is made more complex by the number of security protocols CORBA supports, so the main issue is to make sure the both sides of the conversation are configured for a common subset including the network protocol, the authentication mechanism, etc.
| Note |
|---|---|
The CORBA security features implemented in Geronimo are driven by the Common Security Interoperability (CSI) v2 specification. When digging in to the detailed CSS and TSS configuration, a solid understanding of the topics covered in that specification will help. | |
The main CORBA services (such as the ORB, the Naming service, etc.) are part of the geronimo/j2ee-corba/1.0/car configuration. Normally, there is no need to change or replace this configuration, except for two specific cases:
To run the CORBA naming service on a network port other than the default of 1050, several settings must be overridden in var/config/config.xml.
The configuration includes a number of default TSS and CSS GBeans, but due to the wide variety of configuration options, it is not normally recommended that an application use these. Instead, each application should declare and use its own TSS and/or CSS GBeans.
The main Geronimo GBean responsible for starting an ORB is named Server, and its type for reference purposes is CORBABean. This isn't particularly important except that custom TSS needs to be configured with a reference to it, and it also needs to be configured if the name service will listen on a port other than 1050. Additionally, there is a secondary (less often used) ORB GBean called UnprotectedServer.
The configuration required to change the default naming service port is shown in the following example. Custom CSS and TSS configuration is described in the following sections, along with the required configuration for EJB to be exposed via CORBA or EJB references to remote CORBA EJBs.
Example 17.1. CORBA: Changing Default Naming Service Port
The CORBA entry in var/config/config.xml might look like this in order to change the default port to 1051:
<configuration name="geronimo/j2ee-corba/1.0/car">
<gbean name="NameServer">
<attribute name="dbDir">var/cosnaming.db</attribute>
<attribute name="port">1051</attribute>
</gbean>
<gbean name="Server">
<attribute name="args">
-ORBInitRef,
NameService=corbaloc::localhost:1051/NameService
</attribute>
</gbean>
<gbean name="UnprotectedServer">
<attribute name="args">
-ORBInitRef,
NameService=corbaloc::localhost:1051/NameService
</attribute>
</gbean>
</configuration>![[Warning]](images/warning.png) | Warning |
|---|---|
The CORBA configuration is not started in Geronimo by default. It can be started manually with the deploy tool or the console, but it's always safest for any CORBA application module to declare an import with a uri of geronimo/j2ee-corba/1.0/car to ensure that the CORBA services are started before the module itself. | |
| |  | |
| 16.4. Web Services Clients in Geronimo |  | 17.2. Exposing EJBs via CORBA |