CORBA-Enabling Allegro CL Applications with Allegro ORBLink

Introduction

Allegro CL® applications have always provided a level of flexibility, evolvability and scalability far beyond applications built in other programming environments. Now, with the introduction of Allegro ORBLink™, these applications can also interoperate with other heterogeneous applications across the internet, corporate intranet, and enterprise computing environments through a native implementation of the Common Object Request Broker Architecture (CORBA).

With Allegro ORBLink, Allegro CL applications can:

• Invoke methods on objects on remote machines
• Receive remote invocation requests from other processes
• Interoperate with objects written in Java, C++, C, COBOL, Smalltalk and other CORBA-compliant languages
• Access common CORBA services
• Access remote databases and COM objects
• Interoperate with other commercial ORBs such as ORBIX™ and VisiBroker™

This White Paper presents an overview of the CORBA model, and discusses how Allegro ORBLink enables Common Lisp developers to easily create CORBA-compliant applications using Allegro CL that take advantage of this distributed object functionality.

What is CORBA and How Does it Work?

The Common Object Request Broker Architecture (CORBA) is a standards-based distributed computing model for object-oriented applications developed by the Object Management Group (OMG), a group of 700 vendor and user members including HP, Novell, Sun, IBM, and Digital. Franz Inc. is also a member of the OMG, and fully supports the CORBA architecture for distributed objects.

CORBA is an architecture which uses an Object Request Broker (ORB) to send requests from objects executing on one system to objects executing on another system. The ORB allows objects to interact in a heterogeneous, distributed environment, independent of the computer platforms on which the various objects reside and the languages used to implement them. For example, a C++ object running on one machine can communicate with an object on another machine which is implemented in Common Lisp.

CORBA-compliant applications typically comprise a client and a server. The client invokes operations on objects which are managed by the server, and the server receives invocations on the objects it manages and replies to these requests. A Common Lisp object, for example, can either use CORBA services available over the network (as a client), or it can publish services to other components in the application (as a server). The ORB manages the communications between client and server using the Internet Inter-ORB Protocol (IIOP), which is a protocol layer above TCP/IP.

The objects in a distributed CORBA application, regardless of the language in which they are implemented, can communicate with the ORB through an interface written in the CORBA Interface Definition Language (IDL). The CORBA IDL is a language included in the CORBA 2.0 specification which is designed to describe the interface of objects, including the operations that may be performed on the objects and the parameters of those operations. The behavior of an object is thus captured in the interface independently of the object's implementation. Clients need only know an object's interface in order to make requests. Servers respond to requests made on those interfaces, and clients do not need to know the actual details of the server's implementation.

To implement an interface, CORBA IDL is compiled into the source code language with which the client or server is implemented. On the client side, this code is called a stub. On the server-side, this IDL code is called a skeleton.

In order to request a service from the server, the client application calls the methods in the stub (moving down the protocol stack from the client to the stub to the ORB). Requests are then handled by the ORB, and enter the server via the skeleton (moving up the protocol stack: i.e. an upcall). The server object then services the request and returns the result to the client.

Third-party ORBs such as ORBIX™ from IONA Technologies and VisiBroker™ from Inprise provide common CORBA services such as name services and transaction services. A name service allows a client to initiate contact with a remote object. The client asks the name service for a connection to the remote object by name. The name service works with the stub code to return a connection, permitting the client to call methods on the remote object. This work by the name server might include actually starting up the server which implements the remote object.

Writing IDL stubs and skeletons for Allegro CL applications -- enabling them to communicate with other distributed CORBA-compliant objects -- is made possible by Allegro ORBLink. Users do not need to know low-level details such as the IIOP protocol; Allegro ORBLink handles the mapping for them so that they can write regular CLOS code to make their applications fully CORBA-ready and interoperable with other third-party ORBs.

Allegro ORBLink: Adding CORBA-Compliance to Allegro CL

Allegro ORBLink is an add-on product for Allegro CL which comprises an automatic mapping of the CORBA IDL into Allegro CL. This mapping is fully IIOP-compliant, and it permits Allegro CL users to write CLOS code that takes advantage of CORBA services or that publishes CLOS services to other application components as described above. Fully compatible with other third-party ORBs, Allegro ORBLink enables Allegro CL applications to take advantage of common CORBA services such as name and transaction services.

Features of Allegro ORBLink include:

• Complete IIOP compliance
• Automatic exception handling
• Support for all IDL data types
• Open support for industry standards on a variety of hardware and operating system platforms
• Integration with existing systems written in any other CORBA-compliant programming language
• Interoperability with other CORBA-compliant objects and services
• Full compatibility with common object services defined in CORBA, including naming, events, and transaction services available through third-party ORBs such as Orbix from Iona and VisiBroker from Inprise.

In the next section, we take a look at an example of a CORBA-compliant distributed application containing a Common Lisp component developed in the Allegro CL environment, and a Java component such as a graphical user interface. We will see how Allegro ORBLink works to enable interoperability of the Common Lisp component with the Java object in a distributed architecture.

An Example CORBA-Compliant Distributed Application

The following diagram illustrates a simple client-server banking application with a server component written in Common Lisp and a client (say an ATM terminal) written in Java. The file containing the CORBA interface definitions is in this example called "bank.idl". Here is the IDL source code in this file:

module Bank(
	interface Account {
		float Balance();
	};
	interface AccountManager{
		Account open (in string name);
	};
}; 

The "bank.idl" file is compiled into two pieces: it is compiled by a Java CORBA compiler into a Java stub on the client side, and it is compiled by Allegro ORBLink into a CL skeleton on the server side.

The classes Bank:Account and Bank:AccountManager constitute the CL skeleton. The skeleton also includes methods on these classes which deal with marshalling, events, IIOP, etc.

The user code for the skeleton extends the skeleton classes and implements the methods using def-corba-method.

(defclass Account (Bank:Account)
	(balance :accessor get-balance))

(def-corba-method balance ((account Account))
	(get-balance account))

(defclass AccountManager (Bank:AccountManager)
((accounts 	:accessor get-accounts 
    	:initform (make-hash-table :test #' equal))))

(def-corba-method open ((mgr AccountManager) name)
	(gethash name (get-accounts mgr)))

The AccountManager class has an open method which takes an account holder's name and returns the account for that account holder. The Account class has a balance method which takes an Account object and returns a balance.

Def-corba-method uses all of the "hidden" skeleton methods automatically where needed (for marshalling, IIOP, etc.). The programmer does not need to manually invoke them. As such, Allegro ORBLink makes it easy to write skeletons and stubs with no requirement to manually handle details of the underlying protocols.

Conclusion: An Enterprise Middleware Solution for Allegro CL

Many Allegro CL developers seek an integrated solution for developing, deploying and managing distributed applications containing Common Lisp components and applications written in other languages. They need a complete end-to-end solution that ensures full integration of the Dynamic Objects environment of Allegro CL with the industry-standard CORBA distributed object computing infrastructure. Allegro ORBLink is their solution.

Allegro ORBLink enables truly interoperable distributed applications with open support for diverse platforms and existing systems. Together, Allegro ORBLink and the CORBA framework provide a standards-based enterprise middleware solution for Allegro CL. This solution enables Common Lisp software components to work with networked objects written in other languages such as Java and C++, and interoperate with legacy COBOL and C systems in a reliable, dependable and scalable manner. Allegro ORBLink makes Allegro CL the ideal environment for building dynamic object-oriented CORBA applications that can scale to deal with large volumes of users and data, adapt to ongoing changes in technology and business requirements, and interoperate with heterogeneous distributed objects across the internet, corporate intranets and enterprise networks.

CORBA References

For more information about CORBA, please visit the OMG website at http://www.omg.org, which includes all of the official CORBA standards. For more information about using CORBA with Allegro CL, please contact Franz Inc. at 1-888-CLOS-NOW or [email protected].