Lesson 1

When you are given a system, either to implement or to access, it is very important to have well-defined interfaces between system elements.

Well-defined interfaces allow for solid encapsulation of implementation and modular development practices. All you need in order to write part of a system are the interfaces to that part of the system and the interfaces to the other parts of the system that your part uses. The language, patterns, and vendors you use from there on should be up to you, the implementer.
It is important to be able to see the interface in a common form and to know how to use it with respect to the language and vendor choices you have made. In practical terms, to use an Interface Definition Language (IDL) interface, you must map the IDL interface to an interface, class, or whatever is appropriate in the chosen implementation language. Some of these language mappings have been standardized by the Object Management Group (OMG). In this course, we will cover the OMG IDL mapping to Java. In this module, we will cover the most basic elements of the mapping, mainly from the viewpoint of an application client implementer.

By the end of this module you will know how to:

1. Describe the mapping of an IDL module in Java
2. Describe the mapping of an IDL constant in Java
3. Describe the mapping of an IDL typedef in Java
4. Describe the mapping of interface operations with in, out, and inout parameters in Java
5. Describe the mapping of interface attributes in Java

Services are typically decomposed into several distinct interfaces that provide different views for different kinds of clients of the service. For example, the Event Service is composed of PushConsumer, PullSupplier and EventChannel interfaces. This simplifies the way in which a particular client uses a service.
A particular service implementation can support the constituent interfaces as a single CORBA object or as a collection of distinct objects. This allows considerable implementation flexibility. A client of a service may use a different object reference to communicate with each distinct service function. Conceptually, these internal objects cooperate to provide the complete service. As an example, in the Event Service an event channel can provide both PushConsumer and EventChannel interfaces for use by different kinds of client. A particular client sends a request not to a single “event channel” object but to an object that implements either the PushConsumer and EventChannel interface. Hidden to all the clients, these objects interact to support the service.
The service designs also use distinct objects that implement specific service interfaces as the means to distinguish and coordinate different clients without relying on the existence of an object equality test or some special way of identifying clients. Using the event service again as an example, when an event consumer is connected with an event channel, a new object is created that supports the PullSupplier interface. An object reference to this object is returned to the event consumer which can then request events by invoking the appropriate operation on the new "supplier" object. Because each client uses a different object reference to interact with the event channel, the event channel can keep track of and manage multiple simultaneous clients. This is shown graphically in Figure 2-1.

The graphical notation shown in Figure 2-1 is used throughout this document and in the full service specifications. An arrow with a vertical bar is used to show that the target object supports the interface named below the arrow and that clients holding an object reference to it of this type can invoke operations. In shorthand, one says that the object reference (held by the client) supports the interface. The arrow points from the client to the target (server) object. A blob (misshapen circle) delineates a conspiracy of one or more objects. In other words, it corresponds to a conceptual object that may be composed of one or more CORBA objects that together provide some coordinated service to potentially multiple clients making requests using different object references. In the next lesson, you will learn how to describe the mapping of an IDL module in Java.