Oracle8i CORBA Developer's Guide and Reference Release 3 (8.1.7) Part Number A83722-01 |
Library | Service | Contents | Index

## About CORBA

CORBA stands for Common Object Request Broker Architecture. What is common about CORBA is that it integrates ideas from several of the original proposers. CORBA did not just follow the lead of a single large corporation, and it is very deliberately vendor neutral. The CORBA architecture specifies a software component, a broker, that mediates and directs requests to objects that are distributed across a network (or several networks), which might have been written in a different language from that of the requestor, and which might be (and in fact, usually are) running on a completely different hardware architecture from that of the requestor.

Note: This section provides a short introduction to CORBA, and should give you some idea of how you typically use CORBA in the Oracle8i server environment. Providing a complete introduction to CORBA is beyond the scope of this Guide. See the references in "For More Information" for suggested further reading. This first section gives a very high-level overview of CORBA itself.

CORBA enables your application to tie together components from various sources. Also, and unlike a typical client/server application, a CORBA application is not inherently synchronous. It is not necessarily typical that a CORBA requestor (a client) invokes a method on a server component and waits for a result. Using asynchronous method invocations, event interfaces and callbacks from server object to the client ORB, you can construct elaborate applications that link together many interacting objects and that access one or many data sources and other resources under transactional control. .

CORBA offers a well-supported international standard for cross-platform, cross-language development. CORBA supports cross-language development by specifying a neutral language, Interface Definition Language (IDL), in which you develop specifications for the interfaces that the application objects expose.

CORBA supports cross-platform development by specifying a transport mechanism, IIOP, that allows different operating systems running on very different hardware to interoperate. IIOP supplies a common "software" bus that, together with an ORB running on each system, makes data and request transfer transparent to the application developer.

Although the CORBA standard was developed and promulgated just before the advent of Java and is a standard focused on component development in a heterogeneous application development environment, incorporating systems and languages of varying age and sophistication, it is perfectly possible to develop CORBA applications solely in Java. CORBA and Java are a good match.

For CORBA developers, JServer offers the following services and tools:

- a Java Transaction Service (JTS) interface to the OMG Object Transaction Service (OTS)

- a CosNaming implementation used when publishing objects to an Oracle8i database, retrieving the object references, and activating objects

- a version of the IIOP protocol that supports the JServer session-based ORB, which is compatible with standard IIOP

- a wide range of tools, which assist in developing CORBA applications, that do the following:

  - load Java classes and resource files to the database

  - drop loaded classes

  - publish objects to the CosNaming service

  - manage the session name space

### CORBA Features

CORBA achieves its flexibility in several ways:

- It specifies an interface description language (IDL) that allows you to specify the interfaces to objects. IDL object interfaces describe, among other things:

  - The data that the object makes public.

  - The operations that the object can respond to, including the complete signature of the operation. CORBA operations map to Java methods, and the IDL operation parameter types map to Java datatypes.

  - Exceptions that the object can throw. IDL exceptions also map to Java exceptions, and the mapping is very direct.

    CORBA provides bindings for many languages, including both non-object languages such as COBOL and C, and object-oriented languages such as Smalltalk and Java.

- All CORBA implementations provide an object request broker (ORB), that handles the routing of object requests in a way that is largely transparent to the application developer. For example, requests (method invocations) on remote objects that appear in the client code look just like local method invocations. The remote call functionality, including marshalling of parameter and return data, is performed for the programmer by the ORB.

- CORBA specifies a network protocol, the Internet Inter-ORB Protocol (IIOP), that provides for transmission of ORB requests and data over a widely-available transport protocol: TCP/IP, the Internet standard.

- A set of fully-specified services eases the burden of application development by making it unnecessary for the developer to constantly reinvent the wheel. Among these services are:

  - Naming. One or more services that let you resolve names that are bound to CORBA server objects.

  - Transactions. Services that let you manage transaction control of data resources in a flexible and portable way.

  - Events.

  CORBA specifies over 12 services. Most of these are not yet implemented by CORBA ORB vendors.

The remainder of this section introduces some of the essential building blocks of an Oracle8i JServer CORBA application. These include:

- the ORB--how to talk to remote objects

- IDL--how to write a portable interface

- the naming service (and JNDI)--how to locate a persistent object

- object adapters--how to register a transient object

  Note: The Java code examples in this chapter are available on line. You can study the complete examples (see Appendix A, "Example Code: CORBA"), compile and run them, and then modify them for your own use. All examples are installed in the $`ORACLE_HOME/javavm/demo/demo.zip` file.

### About the ORB

The object request broker, or ORB, is the fundamental part of a CORBA implementation. The ORB makes it possible for a client to send messages to a server, and the server to return values to the client. The ORB handles all communication between a client and a server object.

The JServer ORB is based on code from Inprise's VisiBroker 3.4 for Java. The ORB that executes on the server side has been slightly modified from the VisiBroker code, to accommodate the different Oracle8i object location and activation model. The client-side ORB has been changed very little.

Note: The VisiBroker ORB functionality supplied with JServer is only licensed for accessing Oracle8i servers.

In some CORBA implementations, the application programmer and the server object developer must be aware of the details of how the ORB is activated on the client and the server, and they must include code in their objects to start up the ORBs and activate objects. The Oracle8i ORB, on the other hand, makes these details largely transparent to the application developer. As you will see from the Java code examples later in this chapter and in Appendix A, only in certain circumstances does the developer need to control the ORB directly. These occur, for example, when coding callback mechanisms, or when there is a need to register transient objects with the basic object adapter.

| Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
Library | Service | Contents | Index