This chapter describes SilverStream's support for CORBA. It covers the following topics:
This chapter assumes that you are familiar with CORBA. If you are new to CORBA or just want to explore a specific CORBA topic, you can find more information at the OMG Web site at www.omg.org.
The Common Object Request Broker Architecture (CORBA) is an object-oriented distributed computing infrastructure specified by the Open Management Group (OMG).
CORBA allows you to build applications so that objects can call methods on other objects, regardless of where each object is located. The objects might be located in different processes or on different machines; the remote machines can be of different types and the objects can be implemented in different languages. The caller does not need to know where the other object is actually located.
There is a set of services that is common to all distributed computing environments. OMG has defined IDL interfaces for many of these services so that objects have a common way to access them. For example there are CORBA-defined Naming, Event Management, Persistence, Lifecycle, Concurrency, Security and Transaction services. CORBA allows your application to make use of these services and to be a remote object-oriented service.
The SilverStream Application Server includes the JBroker ORB. JBroker is an enterprise-class Java-based CORBA ORB. You can use the JBroker ORB from the SilverStream Server, SilverJRunner, or any browser. You can use it to develop, deploy, and manage Java-based CORBA applications. It includes the following features:
For more information on JBroker, see the JBroker documentation available from the online help system.
To build a SilverStream CORBA application, you create the following objects:
This business object instantiates the implementation class and registers it with the JBroker naming service. SilverStream recommends that you use either a server-start business object or an invoked object.
The IDL file defines the interfaces that your CORBA application uses. You use SilverStream's Business Object Designer to create and compile the CORBA IDL.
SilverStream provides a CORBA IDL wizard to create a framework for writing your CORBA IDL definition. You can launch the CORBA IDL wizard by choosing New CORBA IDL from the SilverStream Business Object Designer. Here is an example of a CORBA IDL file.
One you have defined the IDL, you simply save it to invoke SilverStream's IDL compiler.
When you save the IDL file, SilverStream launches the idl2java compiler in a DOS window. The idl2java compiler generates the stubs and skeletons and any additional helper objects that are necessary. It specifically:
SilverStream generates a Java Object named packagename._interfacenameImplBase. When compiling the previous example, idl2java would create Customers._CustImplBase.
The Java object that is created will have two constructors.One constructor is null, the other has a parameter for each of the attributes defined in the IDL.
The Java interfaces include the methods described by the interface. The interface definition in the previous example results in a Java interface called packagename.Cust
The JAR file contains both the client and server sides of the application. Although each side of the application does not need the other side, you gain simplicity by having a single JAR file. The files are typically small so the extra server classes should not have a significant impact on client download times.
You can see the JAR when you open the Jars node of the EJB Jars and Media node of the SilverStream Designer.
To access the CORBA objects from a SilverStream form, page, or business object, you must include a reference to the IDL JAR file. To access the CORBA objects from an external file, you need to download the JAR from the server and add it to the path.
Use the following guidelines when writing IDL files in SilverStream:
The CORBA implementation class resides on the server. It includes an implementation for each of the methods defined by the CORBA IDL. You use SilverStream's Business Object Designer to create the implementation class.
Here are the steps:
NOTE If you are using the Business Object wizard, do not create stubs for abstract methods on the base class.
NOTE If you are using the Business Object wizard do not create stubs for interface methods.
NOTE When you finish the wizard, SilverStream generates an error message stating that the methods on the implementation class must be declared abstract. You can ignore this message. It is generated because you have not yet written implementations for the methods defined by the interface (that is the next step).
You need to create a SilverStream triggered business object whose job is to:
Both invoked business objects and ServerStart objects are useful. Invoked objects work well when testing your application, while ServerStart objects are useful in production environments.
Here are the guidelines for writing this object:
You could use "IIOP" as the prefix for the objectname. For example, "IIOP/CORBACustomer".
This is the name that any client will use to lookup your CORBA object.
This is the object that calls the methods exposed on the CORBA server-side object. The client-side class gets the reference to the server object using the JNDI naming service. Once it has the reference, the client object can make method calls as though the server-side class were local.
Here are the guidelines for your CORBA clients:
AgrServerSession session=AgRuntime.connect("localhost", 80);
(The parameters for connect() are host and port number.)
InitialContext initialContext=new InitialContext();
If the server is on another machine, you need to qualify the object name like: