Contents

1.1 Overview of Distributed Programming using Orbix

1.1.1 Defining Interfaces

1.1.2 Clients and Servers

1.2 Overview of Java

1.3 Orbix/Java Integration

1.4 Constructing Applications using OrbixWeb

1.4.1 OrbixWeb Objects

1.4.2 Client Side

1.4.3 Server Side: Implementing an Interface

1.4.4 Servers and the Implementation Repository

The OrbixWeb Reference Guide expands on the information presented in this guide by giving complete information on syntax, switches, and configuration files and a comprehensive description of the OrbixWeb API.

1.1 Overview of Distributed Programming using Orbix

Distributed technology is designed to provide a communications infrastructure which abstracts low-level communications layers. Object-oriented distributed technology adds a framework for encapsulation and re-use which speeds application development and improves the potential for integration of diverse applications.

The Object Management Group's Common Object Request Broker Architecture (OMG CORBA) is a standardized specification for the creation of distributed, object-oriented software systems. This specification defines the functionality of an Object Request Broker (ORB). An ORB is a software layer which allows developers to define objects which can be accessed across a network through clearly defined, high-level interfaces. These interfaces completely abstract underlying application implementation details, such as programming language or operating system.

The standardised nature of the CORBA specification has important advantages. There are many ORB implementations available, and this diversity in itself could pose a problem if different ORBs were unable to communicate with each other. However, CORBA specifies that all compliant ORBs must support an ORB standard communications protocol (called the Internet Inter-ORB Protocol, or IIOP). Low-level ORB communications are largely hidden from application developers, but this protocol ensures that ORB implementations can freely interoperate.

OrbixWeb implements Orbix, IONA Technologies' full implementation of the CORBA specification, in the Java programming language. OrbixWeb enables Java programmers to build distributed applications using the CORBA standard framework for inter-object communications. These applications can interact across networks through an object-oriented interface and can, using IIOP, interact directly with similar applications implemented using other ORBs.

In Orbix, the components of a distributed program are objects–which have well defined interfaces and which may be accessed from any node in the distributed system. Each object is associated with a server–a server manages a set of objects with the same or with different interfaces. Each Orbix object internally has a unique system wide identifier, which can be used to locate it within the distributed system. Each server can have any number of clients that communicate with its objects.

In a conventional, non-distributed, program the usual mechanism to connect different components of the program together is the function, or procedure, call. This mechanism is well understood; thus, it is reasonable to expect that a facility for programming distributed applications should also allow function and procedure calls to be used to connect components together.

Orbix is an object-oriented system, so objects rather than isolated procedures are the components of distribution. A program running on Orbix can invoke methods on an object running on any node in a distributed system. A programmer can invoke a remote object by making a normal method call. This means that familiar programming paradigm and syntax can be used to write distributed programs.

As is normal in object-oriented systems, an application is constructed by specifying types (interface definitions), implementing these types, and then creating objects of these types.

1.1.1 Defining Interfaces

Having defined the interface to some object in IDL, the programmer is then, in principle, free to implement the object using any suitable programming language. Correspondingly, the programmer who wishes to use that object can, in principle, employ any programming language to make remote requests to the object. In particular, the programming language used to implement an object may differ from that used to implement a client using that object.

1.1.2 Clients and Servers

An Orbix programmer can choose to allow a server to be automatically activated (launched) if it is dormant when one of its objects is used. To facilitate this, a server should be registered with Orbix. However, servers which do not require automatic launch facilities do not need to be registered.

Clients can implement a subset of the functionality normally associated with servers and servers can act as clients. This is a feature which adds flexibility to Orbix applications. Objects are implemented as language level objects (for example, when using Java, objects are just Java objects) and they are contained within clients or servers.

An object is considered remote to a method caller if it is located on a remote network host or in another address space on the caller's host, although the latter is strictly inaccurate. The term is defined in this way because many of the same rules apply to inter-address-space and inter-machine operation calls (although inter-address-space calls are optimised).

The term service is sometimes used to refer to a facility provided to the rest of the system by the objects in one or more servers. For example, each of a set of servers may provide an object that can handle the same calls from different clients. Another example is that the set of objects, of the same or different interfaces, in a single server provide some overall service to their clients.

1.2 Overview of Java

Java allows secure and robust programs to be downloaded and executed without restrictions on the target platform. Moreover, Java implicitly supports the dynamic downloading of application classes as required during execution. These features empower components of a distributed system with high-performance mobility and, by presenting this as an inherent capability of applications, Java allows developers to concentrate on high-level application content. This improves the rate and productivity of development.

The flexibility of Java is enhanced by its foundation on an object-oriented paradigm. Java supplies all the advantages of object-oriented programming by supporting such features as encapsulation and inheritance.

1.3 Orbix/Java Integration

There are many advantages to this integration. In general, it improves the flexibility of Java applications and the level of complexity at which objects can interact. Using OrbixWeb, a Java application can easily communicate with CORBA objects located on remote hosts, across heterogeneous platforms, and implemented in a wide range of programming languages.

OrbixWeb supplements Java with standards-based support for a client/server application model. Dynamically downloaded Java applets can communicate directly with back-end services, without imposing limitations on the service implementation (such as hardware, OS, or language considerations). In this way, client-side development becomes decoupled from service implementation issues, giving developers increased freedom when coding each component.

The standardised approach to client-server interaction is a very important element in an application designed for the internet or an enterprise intranet. The CORBA infrastructure for distributed objects allows individual elements of a distributed application to be viewed as components connected (via IDL interfaces) to a standard, vendor-independent backbone. To this end, OrbixWeb supports IIOP for interoperability with other CORBA implementations.

1.4 Constructing Applications using OrbixWeb

As described earlier, OrbixWeb provides transparent access to objects distributed across networks. A Java program may invoke methods on remote objects with standard Java method invocation syntax. The Java program only needs to be aware of the public interface to the object, as specified in OMG IDL. An IDL interface consists of operation and attribute (property) specifications.

The OrbixWeb IDL compiler can be used to produce Java classes corresponding to each IDL interface. The compiler maps all IDL definitions to equivalent Java types.

The implementer of each IDL interface can use OrbixWeb to provide implementation functionality in Java (although client access to objects through an IDL interface is independent of the programming language used in the implementation). This implementation code will be run when the corresponding operations are invoked by a client.

Once an interface is implemented, the server-side developer instantiates any number of objects. These objects are available to any node in the distributed system. OrbixWeb programmers can then develop clients which access those remote objects via the well-defined interface, without knowing any of the server implementation details.

1.4.1 OrbixWeb Objects

• A unique name within its server; we refer to this name as the object's marker.
  
• Its server name, (in CORBA terminology, a server name is sometimes called an implementation name).
  
• The host name of its server.
  

OrbixWeb also supports object references which match the Interoperable Object Reference (IOR) format defined in the CORBA specification of IIOP. The Orbix object reference format forms part of an object's IOR.

In general, servers create OrbixWeb objects which are then made available to clients. An object reference may be made available in a number of ways. For example, a client which is aware of the server name (and optionally the host name or object marker) can use this information to bind to an OrbixWeb object. Alternatively, a server may publish the object reference for retrieval by a client. These and other approaches are described in detail in later chapters of this guide.

1.4.2 Client Side

Figure 1.1: An operation call on a proxy

A client can bind to an object by specifying its unique identifier. The bind call returns an object reference that the client object can subsequently use to invoke methods on the remote object, using normal Java method invocation syntax. The location of the object in the network is transparent to the programmer.

All requests made by the client will be forwarded automatically by the proxy to the remote object, as shown in Figure 1.1. Proxy objects are thus used to support the clients of a remote object, and the programmer of a client need not be aware of the existence of the proxy.

Proxy objects are Java objects; they run code generated by the OrbixWeb IDL compiler

1.4.3 Server Side: Implementing an Interface

Clients are not concerned with the implementation class. They are only aware of the IDL interface, as mapped to a Java class by OrbixWeb. This class is generated by the IDL compiler.

In fact, for a given IDL interface, it is possible to have more than one implementation class. This allows for the different implementations that may sometimes be required, or simply to allow for different space/time trade-offs.

1.4.4 Servers and the Implementation Repository

The objects which are managed by a server need not be of the same implementation class, or even of the same IDL type. Thus a server can support many different IDL interfaces–that is, it can be the server of objects which collectively support many different IDL interfaces.

Not all of the objects in a server need be visible to clients in the system. Some of the objects in a server can have IDL interfaces but nevertheless may exist only for direct use by the server itself. A server can also contain Java objects that do not have an IDL interface; such objects cannot be directly invoked by remote clients.

OrbixWeb provides an Implementation Repository, which manages the servers in the system. The Implementation Repository maintains a mapping from a server's name to the Java class which implements that server. The programmer of a server may choose to register its bytecode with the Implementation Repository in order to take advantage of the automatic launch facilities supported by OrbixWeb.

Bytecode registered in the Implementation Repository will be automatically forwarded to the Java interpreter by OrbixWeb when a operation invocation is made to any object whose object identifier names that particular server. If required, any number of different servers can use the same bytecode.

For registered servers, OrbixWeb provides a number of different launch mechanisms, or modes, giving the programmer control over how servers are implemented as processes by the underlying operating system. In the default mode, shared mode, there will be at most one process for any given server. A process will be started by OrbixWeb to run a server's code if an operation call is made on one of the objects managed by that server. That process can remain running indefinitely, or (in the default case) it can timeout so that servers which are not currently in use do not waste system resources.

In another mode, unshared mode, a server can be coded and registered so that there will be one process per active object–that is, each active object runs in its own process. Although this mode is not frequently used, it has some advantages. One obvious advantage is that the objects cannot interfere with each other's memory.

In a third mode, per-method-call mode, OrbixWeb will start a separate process for each operation call. When registering the server, a different, or the same, Java class can be specified for each operation.

OrbixWeb provides the putit command for registering servers. By default, putit registers a server in the shared activation mode. The putit command also supports a number of variations on the modes outlined in this chapter, and these variations are explained in Chapter 11, "Registration and Activation of Servers".

Individual server objects do not normally need to be registered in the Implementation Repository. However, individual objects may be registered in unshared mode, in particular those objects for which OrbixWeb should launch a new process (if an appropriate process is not already running).

A server which is not registered, or is registered in the default shared mode, can be started manually prior to any invocations on its objects. Subsequent invocations will be passed to the process.