Apusic Application Server and CORBA interoperability

CORBA (Common object Request Broker architecture, common Object Solicitation Broker architecture) is an application software architecture and Object Technical specification presented by the OMG (object management organization, objects Management Group) , and is widely used in the development of distributed systems. The Apusic application server accomplishes remote access to distributed objects based on the RMI-IIOP (remote method invocation Internet Inter-ORB Protocol) protocol, so it can be invoked with CORBA objects. Moreover, the Apusic application server also realizes the CORBA-EJB mapping specification, which can propagate transaction, security and other contextual information between multiple application server instances and CORBA clients. The interoperability specification of CORBA and EJB includes the following four aspects: the mapping of EJB interface to CORBA interface;

Jndi name to the CORBA name Service (cosnaming) mapping;

Transaction propagation between EJB and CORBA;

Secure propagation between EJB and CORBA.

This article presents a sample demonstration of CORBA Client access to the EJB deployed on the apusic. While this is one of the simplest aspects of apusic and CORBA interoperability and does not involve security and transactional propagation, it has shown the APUSIC capabilities and general steps for development in interoperability.

First, introduce the server and client development environment. The server-side environment is:

Windows Server

JDK1.4.2

Apusic Application Server 3.0

The client's environment is:

Windows Professional

JDK1.4.2

The Apusic application server fully supports standard Ejb-corba mappings, meaning that EJB home and remote are CORBA objects. We can use the RMI compiler provided by JDK Rmic-idl to generate the IDL interface for the CORBA view of the EJB. The Jndi (Java naming Service) used to locate the EJB home interface is mapped to a CORBA naming service so that CORBA clients can find and locate the home interface and use them like CORBA objects. The following figure describes the general steps for CORBA Client access to EJBS: These steps include:

developing and deploying EJBS;

Generates IDL for the EJB remote interface using the RMI compiler rmic-idl;

Use the CORBA IDL compiler to generate stubs for clients based on the client's program language;

Configure the EJB server to use the CORBA name service. Apusic uses the CORBA name service as the provider of the Jndi service by default;

CORBA client locates and locates EJB in CORBA name service;

CORBA client accesses EJB like ordinary CORBA object;

First, develop an EJB module, compile and deploy to the Apusic application server. The EJB in this example is very simple, a stateless session Bean that contains only one business method SayHello.

Public java.lang.String SayHello (java.lang.String name) {

String result = "Hello," + name;

System.out.println ("Invoke SayHello ():" + result);

return result;

}

Then use the RMI compiler rmic-idl to generate IDL for the EJB remote interface:

Rmic-idl-novaluemethods

-classpath%apusic_home%/lib/apusic.jar; /ejb/build

-D IDL Samples.ejb.Hello Samples.ejb.HelloHome

CORBA clients can theoretically be developed using any programming language supported by the CORBA specification. This example shows the development of a Java CORBA client. Use the IDLJ provided by JDK1.4.2 to compile the IDL from the previous step:

Idlj-emitall-i./idl-i%java_home%/lib

-fclient

-pkgprefix Java Apusic

-pkgprefix javax Apusic

-pkgprefix Samples Apusic

-TD SRC

./idl/samples/ejb/hello.idl

Idlj-emitall-i./idl-i%java_home%/lib

-fclient

-pkgprefix Java Apusic

-pkgprefix javax Apusic

-pkgprefix Samples Apusic

-TD SRC

./idl/samples/ejb/hellohome.idl

Note that the Java, javax, and Samples modules in the IDL file add "Apusic" as the package prefix when generating code to avoid conflicts with the Java core APIs.

The Java code generated by the IDLJ compiler provided by JDK1.4.2 contains bugs that must be manually changed. Annotate or delete the _read and _write methods in the class _exception.java,createexception.java and Removeexception.java.

At this point, we compile the generated Java file according to the IDL compiler, provide the client implementation, and the code snippet for the main program is as follows:

Orb orb = orb.init (args, null);

Look up the hellohome, create a Hello and use it.

Namingcontextext NC =

Namingcontextexthelper.narrow (Orb.resolve_initial_references ("Nameservice"));

Hellohome home =

Hellohomehelper.narrow (Nc.resolve_str ("ejb/corbaclientsample"));

Hello hello = home.create ();

String str = (string) Hello.sayhello ("Apusic,corba client");

System.out.println (str);

System.exit (0);

From the above code we see how CORBA clients Find and locate EJBs in the CORBA name service, and how to access the EJB like ordinary CORBA objects.

Finally we compile and run the client. Note that we do not need to compile all IDLJ generated Java source files, as long as we compile the package APUSIC.SAMPLE.EJB and the client main program we write. The Java compiler automatically compiles the other classes referenced in the class based on the connection of the class.

Javac-d.. /build-sourcepath./Apusic\samples\ejb\*.java

Javac-d.. /build-sourcepath./Corbaclient.java

Verify that the EJB is deployed on the apusic and that the server is running properly. Start the CORBA client at the command line, telling the client the location and port of the Apusic by the startup parameter to ensure proper initialization of the client orb. Assuming Apusic is running on this machine, the port is 6888:

Java corbaclient-orbinitialhost localhost-orbinitialport 6888

If the previous steps are done correctly, we will see on the client screen: Hello, Apusic,corba client

This example simply demonstrates the business approach that CORBA clients have access to EJB components. In fact, the complexity of CORBA and EJB interoperability lies in transaction and security mapping, so developers are required to be more familiar with CORBA specification and development. And the Java to IDL mapping may encounter many problems, such as: ValueType mapping, the use of collections, etc., which makes CORBA client access to the EJB in many cases can not succeed. Even so, apusic support and CORBA interoperability, still for us to integrate the existing CORBA system, the development of heterogeneous environment distributed applications to provide a great help, but the technical requirements of developers is relatively high.