Mastering Enterprise JavaBeans™ and the Java 2 Platform, Enterprise Edition - Roman E

310 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

The Interface Repository

As we’ve mentioned, the ORB is responsible for facilitating distributed object communications. CORBA clients deal only with interfaces to object implementations. To help the ORB process the objects that clients work with, CORBA introduces the notion of an Interface Repository. An Interface Repository is a repository in which interface definitions are stored permanently. It’s an aggregation facility for storing the interfaces that clients deal with.

The ORB itself makes extensive use of the Interface Repository internally. For example, the ORB uses the Interface Repository for performing type checking of signatures when performing invocations. It also uses it to help verify the correctness of inheritance, and it assists with interoperability between different ORB implementations.

As a CORBA client, you can also make use of the Interface Repository. For example, you can use it to manage how your interfaces are distributed and installed.

The Implementation Repository

Just as an Interface Repository stores interface definitions, an Implementation Repository stores the code that implements the logic defined by the interfaces. For example, an Implementation Repository might be a folder on a hard disk where class files are kept. Implementation Repositories do not have a well-defined interface to them (yet).

OMG’s Interface Definition Language

The cornerstone of CORBA is the Object Management Group’s interface definition language (OMG IDL). OMG IDL is a language that CORBA uses to define the interfaces between clients and the objects they call. When you write a CORBA object implementation, that object implementation must have corresponding IDL that defines the interface for that object implementation. By programming with OMG IDL, you are forcing a clear distinction between interface and implementation—you can vary your implementation without changing the interface your clients use. The IDL concept is shown in Figure 11.2.

Another great benefit to OMG IDL is that it is a language-neutral interface for object implementations. You can write your IDL once and then define your object implementations in any language that CORBA supports, such as C++ or Smalltalk. And because IDL is language-neutral, client code that calls your object implementations can be written in any language that CORBA supports as well. Thus, IDL enables you to have a deployment mixing heterogeneous languages.

Go back to the first page for a quick link to buy this book online!

CORBA and RMI-IIOP 311

Pricer.java

Pricer

Pricer.idl

IDL defines the interfaces between components written in different languages

Fulfillment

Billing

Figure 11.2 The Interface Definition Language concept.

IDL is also inherently platform-neutral, allowing clients and object implementations to be deployed in different platforms. For example, your clients can exist on a Windows NT box and be talking to business objects deployed on a Silicon Graphics IRIX box.

OMG IDL is only one flavor of IDL. Microsoft has its own IDL as part of COM+. In this chapter, we’ll assume we’re using OMG IDL.

Go back to the first page for a quick link to buy this book online!

312 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

You should think of IDL as a “middleman” language—a common ground that is, in theory, independent of language change. IDL allows you to write a distributed application with the illusion that it’s all written in one language.

Here is a sample snippet of IDL:

module com { module wiley {

module compBooks { module roman { module corba {

interface HelloWorld {

string sayHello(in string myName);

}

}}}}}

As you can see, IDL is very similar to C++ and Java.

There are many different types in IDL, including basic types (such as short and float) and constructed types (such as struct and enumeration). You’ll find that if you know C++, learning to use OMG IDL is pretty straightforward. If you’re a Java programmer, you should not have too much difficulty using IDL to define your object’s interfaces either because Java’s syntax is similar to C++.

We only briefly describe IDL in this chapter. Most CORBA books will have a section explaining IDL fully. And if you’re serious about CORBA, take a look at ftp://www

.omg.org/pub/docs/formal/98-02-08.pdf, which details OMG IDL rigorously.

OMG IDL Maps to Concrete Languages

IDL is only a descriptive language in that it describes the interfaces to your objects. You cannot “execute” IDL. Neither your CORBA object implementations nor your CORBA clients ever see IDL. You program your clients and object implementations in whatever language you’re using, such as Java or C++. But how, then, do you refer to CORBA objects? The answer is the OMG IDL maps to specific languages, such as Java or C++. If you go to the OMG Web site (www.omg.org), you’ll see that there are specifications detailing how OMG IDL maps to various languages. For instance, there is an IDL-to-Java mapping specification that defines how IDL maps to Java. With the IDL-to-Java mapping, the string type in OMG IDL maps to the java.lang.String object in Java.

Thus, it’s important to realize that, although IDL is a language, it is more of an abstraction because you never write client code or object implementations that

Go back to the first page for a quick link to buy this book online!

CORBA and RMI-IIOP 313

use IDL files. Rather, you use IDL to define the interfaces to your objects and then map that IDL into your particular language using an IDL compiler. For example, an IDL-to-Java compiler would take as input an IDL file and generate Java interfaces for your object implementations. Once this is done, you can implement those interfaces in Java. You could then map the IDL to a different language, such as C++, by using an IDL-to-C++ compiler. This would allow you to write client code in C++ that calls your Java object implementations.

For the sake of brevity, we do not cover the IDL-to-Java mapping here. You can download the complete IDL-to-Java mapping specification for free from ftp:// www.omg.org/pub/docs/formal/98-02-29.pdf.

Static Invocations

As we’ve said, the ORB facilitates client/server communications, simplifying client networking needs. But how does a client invoke a method on a remote CORBA object? The answer is via a local method call, which gets translated into a remote method call across the network. This is quite analogous to how networking is accomplished in Java RMI.

The conventional way of performing distributed computing in CORBA is to have the client invoke locally on a pregenerated stub. The stub is a proxy for the real object implementation, which exists elsewhere on the network. The stub is responsible for going through the client-side ORB runtime, which channels the request over the network via IIOP.

The receiving server-side ORB runtime receives the IIOP request, then calls a skeleton to handle the request. The server-side skeleton is a pregenerated file, just like the stub. The skeleton is responsible for delegating the invocation to the actual server-side CORBA object that will service the request. The skeleton is also responsible for coordinating with the object adapter (which we mentioned earlier in this chapter) to activate objects in case they don’t exist already. This process is shown in Figure 11.3.

Both the stub and skeleton are pregenerated files. They are usually generated from the IDL file that defines the server-side CORBA object’s method signatures. They need to be pregenerated for two reasons:

CORBA objects are inherently cross-language. This means you need to pregenerate the stubs and skeletons in the particular language you’re using. You’re free to use any language to which IDL maps.

Stubs and skeletons contain specific syntax about your particular CORBA object’s method signatures. Thus you must generate them for each of your CORBA objects because each object will have different method

Go back to the first page for a quick link to buy this book online!

314 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

Client

CORBA Object

Implementation

CORBA Object Interface

Network

via IIOP

Figure 11.3 Calling a method in CORBA.

signatures. By generating them, you can simulate an environment where clients can invoke on proxies using the actual method signatures of the real object, located elsewhere.

The above invocation mechanism is called a static invocation because you’re statically binding your client code to stubs at compile time.

Dynamic Invocations

There is another way for you to invoke on CORBA objects: dynamically. Dynamic invocations allow you to invoke on CORBA objects that might not be available when you write your client code. With dynamic invocations, your clients dynamically discover CORBA objects at runtime. This mechanism of invoking dynamically is CORBA’s Dynamic Invocation Interface, or DII.

The DII is a very powerful idea, and it has a number of benefits, such as plugging in new objects without recompiling client code. Because everything is dynamically discovered at runtime, you don’t need to pregenerate stubs and skeletons, as you do for static binding. And if you want your invocation to be

Go back to the first page for a quick link to buy this book online!

CORBA and RMI-IIOP 315

asynchronous (that is, you perform the invocation, go off and do something else, and then come back later for the results), the DII can accommodate you.

There are also several drawbacks to dynamic invocations. For one, the runtime discovery of objects is a performance hit. When you precompile stubs and skeletons with static binding, you’re performing all necessary “discovery” in a preprocessing step. When you are instead operating dynamically, you’re making the ORB figure out which method to invoke, which slows things down.

If you are a COM programmer, you will find that using dynamic invocations in CORBA through DII is much like using dynamic invocations in the COM world through COM’s IDispatch interface. Similarly, static invocations in CORBA are much like the virtual function pointer table binding in COM.

CORBA’s Many Services

In addition to enabling objects to communicate over the network, the Object Management Group has published a set of CORBA Object Services (known as CORBAServices or COS) that give your networked objects additional capabilities. These services are optionally provided by CORBA vendors. Most serious CORBA products will give you one or more services to aid development.

Let’s take a look at a sampling of these services. There are many more services than we’re listing here, and even more will surely be developed over time. As you’ll notice, some of these services are very similar to those that EJB provides. Indeed, much of EJB was based on CORBA’s services.

The Naming Service

The CORBA Naming Service (or COS Naming) is a CORBA service that allows you to look up CORBA objects by name. This allows you to identify the locations of objects across the network by a human-readable string.

COS Naming is a similar technology to the Java Naming and Directory Interface (JNDI), which we review in Appendix B. In fact, there is a service provider plugin for JNDI that allows JNDI clients to access CORBA Naming and Directory services. JNDI is much more robust than the CORBA Naming Service because JNDI can look up arbitrary resources on a network, not just CORBA objects.

The Event Service

The CORBA Event Service allows for asynchronous communications between CORBA objects. Asynchronous communications allow for parties to send or process events at their leisure. An object can send an event to another object

Go back to the first page for a quick link to buy this book online!

316 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

without suspending (or blocking) the calling thread. Events support a much looser form of communication between objects: peer-to-peer rather than client- to-server. Using the CORBA Event Service, your objects can subscribe to certain types of events and be notified when an event of that type is generated.

The Object Transaction Service

CORBA’s Object Transaction Service (OTS) enables CORBA objects to perform transactions. The Transaction Service is composed of two pieces: a low-level set of interfaces between transaction participants (such as a Resource Manager, a Transaction Manager, etc.), and a high-level interface for demarcating transactional boundaries.

The Concurrency Control Service

The Concurrency Control Service allows for multiple clients to concurrently interact with a resource. Clients concurrently access resources by obtaining locks on those resources. For example, I can request a read lock on an object, which does not allow any other client to write to the object while I hold the read lock. Other clients that also hold read locks can still interact with my object, however, because they’re simply reading, not modifying the object. I can also request a write lock, which disallows any concurrent readers or writers. There are five different lock modes, allowing for a wide variety of interactions. The Concurrency Service works together with CORBA’s Object Transaction Service.

The Security Service

The CORBA Security Service adds secure functionality to your CORBA system. The Security Service yields mechanisms to do the following:

■■Identify and authenticate users and objects

■■Perform authorization and access control, ensuring that clients are qualified to perform desired operations

■■Enable confidentiality, ensuring that only authorized users can view object contents

■■Create audit trails and perform other needed security functions

CORBA Components

As we go to press, several OMG participants have issued a revised specification for CORBA Components. This specification adds component features to CORBA objects, allowing them to function similarly to enterprise beans. This means that CORBA now has a proposal that allows for true components to be developed in the CORBA world.

Go back to the first page for a quick link to buy this book online!

CORBA and RMI-IIOP 317

If you browse through the specification (available at ftp://ftp.omg.org/pub/docs/ orbos/98-12-02.pdf), you’ll see that it’s almost identical to Enterprise JavaBeans. This was done intentionally so that CORBA Components and enterprise beans can reside together. One goal of CORBA Components is to integrate with enterprise beans. Thus, it should be possible to do the following:

■■Make a CORBA Component appear as though it were an enterprise bean

■■Make an enterprise bean appear as though it were a CORBA Component

This will definitely be an interesting standard to keep an eye on as EJB and CORBA evolve. If you’re curious, take a look at Chapter 11 of the CORBA Components specification, which details how CORBA Components and Enterprise JavaBeans can be mapped.

We’ve just scratched the surface of CORBA’s services here. A great reference for CORBA’s services is The CORBA Reference Guide by Alan Pope (Addison-Wesley Publications, 1998, ISBN #0201633868). Take a look at this book if you want to understand CORBA’s optional services at a high level but you don’t want to read the formal OMG specifications.

RMI over IIOP

Now that you’ve seen the basics of CORBA theory, let’s compare Java RMI to CORBA. RMI is an alternative mechanism for performing networking in Java, fully covered in Appendix A.

We’ll first see why people use RMI and CORBA. Next, we’ll look at the semantic differences that must be overcome in order to merge CORBA and RMI. Finally, we’ll look at how the industry is merging RMI and CORBA with a standard known as RMI over IIOP. This standard is the key to EJB-CORBA compatibility.

The Need for RMI-CORBA Interoperability

RMI and CORBA are very similar technologies with slightly different goals. One technology is not better than the other—it all depends on what kind of development you’re doing.

CORBA is a robust distributed object standard that allows for language interoperability. RMI, on the other hand, was built for very simple distributed object communications in Java. While RMI does not contain CORBA’s cross-language support, it is well suited for pure Java development due to Java-specific features such as distributed garbage collection (see Appendix A).

While both RMI and CORBA are intended for distributed object communications, neither technology contains high-end middleware services, such as persistence

Go back to the first page for a quick link to buy this book online!

318 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

or transactions. CORBA programmers can gain those middleware services by leveraging CORBA’s optional services that we described earlier. RMI programmers can gain those middleware services by leveraging the Java 2 Platform, Enterprise Edition suite.

Unfortunately, although RMI and CORBA are similar in nature, they have historically been incompatible technologies. When you program code with Java RMI, you need to write your code to the RMI API. Similarly, when you program code with CORBA, you need to write your code to the CORBA API. This is terrible for code reuse: If you write code in either RMI or CORBA, you’ll need to rewrite major pieces of your code if you want to switch networking technologies.

Ideally, we’d like a world where we could perform the following:

Combine client-side Java RMI with server-side CORBA. We should be able to write an object implementation to the CORBA API and write client code to the Java RMI API that calls that CORBA object. This is shown in Figure 11.4.

RMI Client

CORBA Object

Implementation

RMI Remote Object Interface

Network

via IIOP

Figure 11.4 An RMI client calling a CORBA object implementation.

Go back to the first page for a quick link to buy this book online!

CORBA and RMI-IIOP 319

Combine client-side CORBA with server-side Java RMI. We should be able to write a remote object implementation with the RMI API and have a client written to the CORBA API call that object. This is shown in Figure 11.5.

Combining RMI with CORBA

What strategy should we use to combine the CORBA world with the Java RMI world? To begin to answer this, let’s compare how CORBA and RMI work behind the scenes:

■■Both CORBA (except in its dynamic communications mechanism) and RMI use pregenerated stubs and skeletons for performing network communications.

■■Behind the scenes, CORBA uses IIOP as the protocol for performing client/server communications. This occurs beneath the stub/skeleton layer.

CORBA Client

RMI Remote Object

Implementation

CORBA Object Interface

Network

via IIOP

Figure 11.5 A CORBA client calling an RMI remote object implementation.

Go back to the first page for a quick link to buy this book online!