What is a distributed application?

A distributed application is a program that runs on more than one computer and communicates through a network. Some distributed applications are actually two separate software programs: the back-end (server) software and the front-end (client) software. Back-end software runs on a shared system (such as a shared Unix or VMS system) and manages shared resources, such as disks, printers, and modems. The back-end software also contains the main processing capability for the application. The front-end (client) software runs on workstations. It is the software you see when you use the application. It handles user interface functions, such as receiving input from a keyboard and displaying output to a screen.

Distributed applications can be relatively simple, requiring a single client computer and a single server, or more complex, allowing many client computers and several servers.

For example, web browsers are distributed applications. Browsers require back-end software (servers on the World Wide Web) as well as front-end software installed on your workstation (e.g., Netscape Communicator or Internet Explorer).

TermsGIOP Generic Inter ORB ProtocolIIOP Internet Inter ORB ProtocolDII Dynamic Invocation InterfaceDSI Dynamic Skeleton InterfaceBOA Basic Object AdaptorPOA Portable Object AdaptorIOR Interoperable Object ReferenceIFR InterFace RepositoryMOF Meta Object FacilityRPC Remote Procedure CallDCE Distributed Computing EnvironmentOBV Object by ValueOMA Object Management ArchitectureOMG Object Management Group

ORB Core Feature Matrix as on May 7, 2000

Commercial ORBs

VendorLanguage bindings Protocols Core

IDL

C++

C StAda

JavaCOM

COBOL

IIOP

DCE

DII

DSI

IFR

BOA

POA

OBV

Expersoft Y Y - Y - Y Y - Y - Y Y Y Y - -

Sun Y Y Y - - Y 1Q97 - Y - Y Y Y Y - -

IONA Y Y - - Y Y Y Y Y - Y Y Y 2.x 20002000

Visibroker

Y Y - Y - Y ? '98 Y - Y Y Y 3.x 4.x 4.x

BEA Y ? ? - ? Y Y - Y Y Y Y Y Y Y -

PeerLogic

Y Y Y - - Y Y '97 Y - Y Y Y Y Y -

HP Y Y '97 Y -2Q97

Y - Y Y Y Y Y Y - -

IBM Y Y Y Y Y '97 Y Y Y ? Y Y Y Y - -

Chorus Y Y - - - - ? - Y - Y Y Y Y - -

OOT Y Y Y - - - - ? + - '97 - - Y - -

DNS Y - - Y - - ? - Y ? ? ? ? Y - -

Prism Y Y ? ? ? ? ? ? ? Y ? ? ? Y - -

SNI Y Y - - - - - - Y - Y Y Y Y - -

TRW Y Y ? ? Y ? ? ? ? Y ? ? ? Y - -

ParcPlace Y - - Y - + - - Y - Y ? Y Y - -

TIBCO Y Y Y - - Y - - Y - Y Y Y Y - -

Suite Y Y Y ? ? ? ? Y Y ? Y Y Y Y - -

Fujitsu Y Y Y ? ? Y Y ? Y ? ? ? ? Y - -

BBN Y Y Y ? ? ? ? ? ? ? Y ? Y Y - -

ANSA Y ? ? ? ? ? ? ? ? ? ? ? ? Y - -

SuperNova

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -

Camros Y Y - - - Y - - Y - Y Y Y Y - -

OIS Y Y - - Y - - - Y - ? ? ? ? ? -

Nortel Y Y Y Y - - - - Y - - - - Y - -

Nouveau Y Y Y - - Y Y - Y - ? ? ? - Y ?

ORBacus Y Y - - - Y - ? Y - Y Y Y - Y Y

VendorIDL

C++

C StAda

JavaCOM

COBOL

IIOP

DCE

DII

DSI

IFR

BOA

POA

OBV

Free ORBs

VendorLanguage bindings Protocols Core

IDL

C++

C StAda

Java

COM

COBOL

IIOP

DCE

DII DSI IFRBOA

POA

OBV

Electra Y Y - - - Y - ? Y - Y - - Y - -

U Colorado

Y Y Y - Y Y - ? Y - - - - Y - -

Xerox Y Y Y - - Y - ? Y - - - - Y - ?

JacORB Y - - - - Y - - Y - Y Y Y - Y -

TAO Y Y - - - - - - Y - Y Y - - Y Y

Jorba Y - - - - Y - - + - Y Y Y Y - -

omniORB

Y Y - - Y - - - Y - Y Y - Y soon soon

Mico Y Y - - - - - - Y - Y Y Y Y Y Y

Arachne Y Y - - - - - - Y - Y Y Y Y - -

ORBit Y - Y - Y - - - Y - + + + - Y -

VendorIDL

C++

C StAda

Java

COM

COBOL

IIOP

DCE

DII DSI IFRBOA

POA

OBV

Key

Y this feature is supported but not necessarily conformant to CORBA standards + real soon now- this feature is not supported? this information is not known 

7. Alternatives to CORBA

7.1. Other RPC Schemes

The notable predecessor to CORBA was DCE; Microsoft's COM system, their nearest equivalent to CORBA, was originally based on DCE.

OpenDCE

DCE is now available as open source under the LGPL

DCE FAQ FreeDCE

DCE RPC for Linux 2.0.30

XPCOM

XPCOM is a (built-for-Mozilla ) mimic of COM. Instead of mimicking Microsoft's nonstandard MIDL compiler, this uses a CORBA-compliant IDL compiler, XPIDL. It doesn't provide an RPC scheme; it really is intended for communicating between components within a process.

XPIDL

xpidl is a tool for generating XPCOM interface information, based on XPIDL interface description files. It is based on the GNOME library for ORBit, libIDL.

XPLC The Ensemble Distributed Communication System

A distributed communications system implemented in ML. Based on The Horus Project, the point of the exercise is to provide a generalization of TCP communication to groups of processes.

DCOP: Desktop COmmunications Protocol

This is used by the KDE project for local IPC.

D-BUS

D-BUS is a message bus system, a simple way for applications to talk to one another. D-BUS has no required dependencies, but includes Glib, supporting gtk , Qt , Python and .NET APIs to the D-BUS system, if you want to build those. The

list of projects using D-BUS is growing and they provide a wealth of examples of using the various APIs to learn from.

It has learned from the usage of CORBA by GNOME and DCOP by KDE . One of the major "use cases" is for policies that require an "interact with user" component.

It is intended to allow low latency, avoiding round trips and allowing asynchronous operation. It is low overhead, using a binary protocol (unlike XML-based systems like XML-RPC and SOAP). By using "messages" rather than byte streams, this eliminates a lot of the tough IPC issues, and is designed to make it easy to use some common existing object/type systems.

ZeroC, Inc.

Some of the makers of CORBA implementations have released a CORBA-like middleware system that offers a simpler threading model, asynchronous method invocation and dispatch, batched invocations, multiple transports, complete with cleaner C++ memory management.

It appears to be an attempt to create a CORBA successor that learns from CORBA whilst not shackling itself by trying to be compatible with it.

Red Plain redFOX

This is a "distributed objects" system for C++ ; by eschewing portability across languages, they can produce something smaller than CORBA.

7.2. Message Queueing Systems

There are a variety of libraries available for managing message queues on Linux. The following list orders implementations roughly in the order of how "heavyweight" the implementations appear to be, from the SystemV "message queue" implementation found in the Linux kernel to some Java-based implementations that might represent "monstrosities."

Message Queues - Docs for SysV queueing Synchronous Interprocess Messaging Project for LINUX (SIMPL)

Providing an IPC mechanism similar to QNX Syncronous/Asyncronous messaging.

BSD kqueue

Introduced in FreeBSD 5.0, kqueue() provides a generic method of notifying the user when an event happens or a condition holds, based on the results of small

pieces of kernel code termed filters. An kevent is identified by the (ident, filter) pair; there may only be one unique kevent per kqueue.

Applications need to be notified when an event occurs, or a specific condition holds. Kqueue provides a standard API for applications to register their interest in various events/conditions and have the notifications for these delivered in an efficient fashion.

Eljay Mailbox Library

This is sort of a MQ-Lite ; it is a small library to manage message queues, available in source code form for Linux (GPLed, I think).

An application would set up various queues, which are represented by sockets on a set of servers. Applications can send out messages to queues; there then need to be "listeners" attached to each queue, that have a set of callback functions (based on a C pointer implementation) to provide a set of functions that can be called when messages are received.

This should definitely be fast; robustness may be another question. For a really robust system, one might build a queueing system on top of this that does some logging of messages, with the ability to verify delivery, retrying if necessary.

Isectd Message-Oriented Middleware Uses the GPL o Introduction to Client/Server

o A New Definition for Client/Server (based on messaging)

The Ivy software bus

Ivy is a simple protocol and a set of libraries that allows applications to broadcast information through text messages, with a subscription mechanism based on regular expressions. Ivy libraries are available in C, C++, Java and Perl, on Windows and Unix boxes and on Macs. Several Ivy utilities and hardware drivers are available too.

OpenQueue

OpenQueue is consciously reminiscent of IBM MQSeries, providing a messaging system that provides a socket-based interface. At this point, the server software is implemented in Java , using MySQL ™ for persistent data storage.

Level8 Systems - Falcon MQ

Implementation of MQSeries, more recently reimplemented by Microsoft as their MSMQ system. Falcon MQ allows various Unixes to connect to Microsoft's MSMQ.

Level 8 have versions for Linux, SCO, HP/UX, AIX, VMS, Digital Unix, Solaris, AS/400, Tandem.

Note: This product requires that a host running Windows NT 4.0 and Microsoft MSMQ is present.

Ten Commandments of MQSeries

1. Thou shalt not use a queue as a database.

2. Thou shalt backup your pagesets, filesystems, and logs.

3. Thou shalt routinely apply maintenance to your MQSeries systems.

4. Thou shalt use MQCLOSE and MQDISC when terminating an application.

5. Thou shalt not use MQGET with WAIT UNLIMITED without specifying MQGMO_FAIL_IF_QUIESCING.

6. Thou shalt not create objects with long, drawn out names.

7. Thou shalt create standard naming conventions.

8. Thou shalt provide systems management tools for administrators and users.

9. Thou shalt not create an MQSeries network without mapping out all connections and object relations on paper first.

10. Thou shalt not attempt to apply asynchronous methods to all problems simply because MQSeries is a wonderful product.

MessageQ.Com - Communications Middleware Lots of Whitepapers

Publish-and-Subscribe

Publish-and-Subscribe describes a software architecture where individual applications, both information providers and information consumers, define the information they can deliver or wish to receive.

Publish-Subscribe Middleware - Talarian IBM MQSeries

IBM MQSeries : Introduction for SAP Consultants

Oracle Advanced Queuing AQ FAQ

It can communicate with IBM MQSeries and the Java JMS , and stores messages in the (hopefully robust!) Oracle database.

Talarian - MQexpress

MQexpress is another implementation of an MQ-Series -compatible system that uses a publish/subscribe model, and using Guaranteed Message Delivery rather than message queuing.

They have a Linux release of MQexpress / SmartSockets that is Apparently Rather Fast.

TIBCO TIBCO Rendezvous

Publish/subscribe middleware, available on many platforms including Linux.

BeOS does "pervasive messaging," as described below. Since it is so available, provided as a basic OS service, it is used everywhere, and reportedly represents one of the ways that BeOS is able to provide extremely fast user interaction. In an application, the programmer hardly ever writes code that waits for the user to do something; it merely queues requests...

So messaging, the way applications, the way we communicate with each other, the main way we use to communicate in the BeOS is the BMessage, because our messaging architecture is so pervasive, it's all throughout our interface kit, et cetera, it's really easy to do scripting using that, the same messaging architecture.

Simple Messaging Protocol

A messaging scheme intended to support thread-to-thread messaging atop IP, but independent of TCP and UDP.

Java Message Queue

Java Message Queue software implements the industry standard Java Message Service (JMS) 1.0.1 specification, which provides a standardized API and common messaging strategies for developers. Java Message Queue software supports traditional, address-based queues for message delivery, but also includes the speed and flexibility of the asynchronous Publish and Subscribe message

delivery model. In this model, messages are routed and delivered based on the properties of the message, not on an address or location. Client processes simply register an interest in a particular topic, allowing Java Message Queue software to intelligently and efficiently handle all the communication needs between application components.

SwiftMQ.COM

A free implementation of the Java Messaging Service

Progress SonicMQ - a fast, fully JMS compliant Internet messaging server. Useful Asynchronous Events and Messaging Middleware Research Links

XmlBlaster - Java and CORBA -based Open Source MOM system; also supports C and C++

Plumbing and Other Utilities

"Plumbing" is a message queueing system for Plan9 The design of the plumbing system is peculiar: a centralized language-based file server does most of the work, while compared to other systems the applications themselves contribute relatively little. This architecture is deliberate, of course.

Plumbing's rule language uses only regular expressions and a few special rules such as isfile for matching text. There is much more that could be done. For example, in the current system a JPEG file can be recognized by a .jpg suffix but not by its contents, since the plumbing language has no facility for examining the contents of files named in its messages. To address this issue without adding more special rules requires rethinking the language itself. Although the current system seems a good balance of complexity and functionality, perhaps a richer, more general-purpose language would permit more exotic applications of the plumbing model.

Flow Based Programming

J. Paul Morrison worked on various "flow-based" systems at IBM over the last 30-odd years, and has written a book describing this paradigm. This excerpt, entitled Cognates, describes various existing systems programming schemes that parallel this, notably the notions of Unix streams, where data can flow in parallel from process to process, as well as message queueing systems like IBM MQSeries, where flows are parallelized by submitting work into asynchronous "work queues."

MESSIP - Message Passing over TCP/IP MUSCLE - Multi User Server Client Linkage Environment

The MUSCLE system is a robust, somewhat scalable, cross-platform client-server solution for dynamic distributed applications under any POSIX-compliant operating system. Originally built for BeOS.

Spread is a toolkit that provides a high performance messaging service that is resilient to faults across external or internal networks.

Spread functions as a unified message bus for distributed applications, and provides highly tuned application-level multicast and group communication support. Spread services range from reliable message passing to fully ordered messages with delivery guarantees, even in case of computer failures and network partitions.

There are bindings to several languages:

o Introduction to Spread o Spread Module 1.2 for Python

Several interesting projects are already using and extending Spread:

o The Secure Spread Project o Postgres-R

Anasazi - Let's reimplement the wheel... or at least another GCS

Unfortunately, Spread doesn't scale, at least not when you try to use it for particularly high load tasks. It was designed as an academic system, not as a high grade "production" system; there is merit to creating something intended for heavy duty usage...

7.3. Distributed Object Schemes

GNU Distributed Objects

Patterned after NeXt Distributed Objects; uses Objective C

Scarab / Lightweight Distributed Objects (LDO): Open Source Communications Framework

Created for the Casbah project, this is intended as a fairly dynamic language-neutral lightweight object messaging system. The scope of LDO is similiar to CGI; it's targeted at the low-end of distributed computing, somewhere between HTTP and CORBA / HTTP-NG.

Self-Describing Binary Data Representation for LDO (LDO-Binary) describes a simple, self-describing, binary encoding for structured data. The base format defined here allows for nested values made up of dictionaries, lists, integer, floating point, and opaque 8-bit string values without arbitrary size limits. This document is an IETF Internet Draft.

The API is patterned after the NeXT Distributed Objects system.

Pyro Python Remote Objects

A basic "Distributed Object" system for use with Python . Fairly similar to Java RMI

RMI - Remote Method Invocation

A way of invoking Java objects remotely.

The Castor Project

The Castor Project provides integration tools to represent Java objects in a persistent manner, storing them assortedly as XML , JDO , and LDAP.

UNO - Universal Network Objects

This is the network infrastructure for the OpenOffice system. See their comparison of the UNO - CORBA object models.

Pyro

A distributed object system for Python. It includes a Name Server, Event Service, mobile objects, remote exceptions, dynamic proxies, automatic reconnection, and such...

7.4. Wired XML Schemes

Several proposals have come out whereby XML messages are layered atop some messaging scheme.

SOAP XML-RPC

Embedding RPC structures as XML, transmitted as an HTTP-POST request

Several additional implementations have sprung up:

o XML-RPC for Python.

o XML-RPC for Zope.

o XMLRPC-C - XML-RPC library for use with C /C++

A lightweight RPC library based on XML and HTTP. Also includes an XML-RPC HOWTO that demonstrates examples of the use of XML-RPC in a variety of languages including Perl, Python , C, PHP .

o CapnRPC - XML-RPC for PLT Scheme o Daemoncode::XML-RPC Emacs Client Implementation

o xml-rpc in Elisp

o Mulle XMLRPC

Framework for XML-RPC in Objective-C . Uses EDCommon / EDInternet , framework extensions for Foundation and AppKit.

developerWorks: XML zone : XML Matters: XML-RPC as object model IBM Application Development:XML Metadata Interchange Format (XMI)

XMI Standards Release from OMG

OMG MOF (Meta Object Facility)

XMI ( XML Metadata Interchange) allows metadata conforming to strict metamodels to be encoded as XML documents. The specification has two main parts:

1. A set of production rules for producing an XML DTD from any metamodel specification.

2. A parallel set of production rules for producing an XML document conforming to the DTDs from a model (i.e. a collection of metadata) that conforms to the above metamodel.

Appendices to the specification include example XMI generated DTDs for the interchange of UML models and MOF metamodels.

By basing XMI on XML , we provide implementors with an easy path into the world of metadata-based systems. An application does not need to "speak" CORBA to use XMI.

By basing XMI on the metamodelling technology of the OMG's Meta Object Facility, we make it feasible to avoid the effort of hand-crafting DTDs and the corresponding document producer/consumer software. The MOF/XMI framework can support and integrate all kinds of metadata and can be extended at will.

KDE 2 Architecture - The KDE XmlRpc Daemon Meerkat Open Wire Service

O'Reilly Network: Meerkat: An Open Service API [May. 09, 2000]

O'Reilly Network: Meerkat: The XML-RPC Interface [Nov. 14, 2000]

XML.com: Fat Protocols [Jan. 16, 2002]

Python XMLRPC

Python modules to transmit XML-RPC messages via Spread and Jabber.

7.5. COM and DCOM

For those looking to bind themselves to whatever Microsoft will allow them to do today, DCOM is a "reasonable" alternative to CORBA.

Software AG - EntireX - Frequently Asked Questions EntireX DCOM Download

DCOM and CORBA Side by Side, Step By Step, and Layer by Layer - Bell Labs article

COM at Open Group

Roger Sessions moves from CORBA camp to COM camp

This "Roger Sessions" character claims that CORBA is "doomed" because it will not scale. The claim is that CORBA will not scale because ORBs must spawn a new process to communicate with each client.

This appears to be an incorrect assertion; ORBs should be able to have their processes service multiple clients. And in any case, it would only be a desperate problem with OSes that are unusually inefficient at spawning processes such as VMS or Windows NT...

OpenCOM

A Detailed Comparison of Enterprise JavaBeans (EJB) and Microsoft Transaction Server (MTS) Models

7.6. InterLanguage Unifications or Foreign Function Interfaces

An important issue when working with multiple languages can be to try to invoke code written in one language when writing code in another language.

C is commonly used as a "lowest common denominator" in this regard; there are a number of other options as well:

g-wrap

G-Wrap is a portable tool for easily importing types, functions, and constants from C into Scheme interpreters. As of version 0.8.0, G-Wrap supports both Guile and RScheme.

SWIG Simplified Wrapper and Interface Generator

SWIG provides a way of easily connecting C and C++ code to the Python, TCL, Perl, and Guile interpreters. This allows one to link in highly optimized compiled code to add operators/functions that are much faster than they would be in interpreted form, as well as the possibility of linking to existing code written in or linkable to C/C++ code.

CLISP Foreign Function Call Facility The Common Lisp Cookbook - Foreign Function Interfaces

ASN.1: Wherefore Art Thou?

ASN.1 is for sending messages across a network. Each time a message is sent over the network, it will be ASN.1-encoded at the sender, and ASN.1-decoded at the receiver. So you need to add code to do the encoding and decoding. You can do this by hand, or have an ASN.1 compiler do it for you.

Informally, ASN.1 notation is something like a BNF grammar language. You have terminals and non-terminals, and a start symbol. ASN.1 is somewhat less abstract, however; this is important, because the need for interoperability is stronger for message passing than it is for programming languages. In addition, ASN.1 also comes with rules on how to encode messages that conform to a given ASN.1 notation.

Non-Distributed C++ Application 1: // File: account.cc 2: 3: #include <iostream> 4: #include <assert.h> 5: 6: using namespace std; 7: 8: // Implementation for interface Account 9: class Account_impl 10: { 11: private: 12: int _balance; 13: 14: public: 15: Account_impl () 16: { 17: _balance = 0; 18: } 19: 20: void deposit (int amount) 21: { 22: cout << "Server: deposit " << amount << endl; 23: _balance += amount; 24: } 25: 26: void withdraw (int amount) 27: { 28: cout << "Server: withdraw " << amount << endl; 29: if (_balance >= amount) 30: _balance -= amount; 31: else 32: cout << "Server: withdraw failed" << endl; 33: } 34: 35: int balance () 36: { 37: cout << "Server: balance " << _balance << endl; 38: return _balance; 39: } 40: }; 41: 42: int 43: main (int argc, char *argv[]) 44: { 45: int balance; 46: Account_impl* account = new Account_impl(); 47: account->deposit (700); 48: balance = account->balance (); 49: cout << "Client: balance is " << balance << endl; 50: account->withdraw (50); 51: balance = account->balance (); 52: cout << "Client: balance is " << balance << endl; 53: account->withdraw (200); 54: balance = account->balance ();

55: cout << "Client: balance is " << balance << endl; 56: 57: return 0; 58: }

Account IDL Specification 59: // File: account.idl 60: 61: interface Account { 62: void deposit (in long amount); 63: void withdraw (in long amount); 64: long balance (); 65: };

CORBA C++ Server 66: // File: server.cc 67: 68: #include <iostream> 69: #include <fstream> 70: #include "account.h" 71: 72: using namespace std; 73: 74: // Implementation for interface Account 75: class Account_impl : virtual public POA_Account 76: { 77: private: 78: CORBA::Long _balance; 79: 80: public: 81: Account_impl () 82: { 83: _balance = 0; 84: } 85: 86: void deposit (CORBA::Long amount) 87: { 88: cout << "Server: deposit " << amount << endl; 89: _balance += amount; 90: } 91: 92: void withdraw (CORBA::Long amount) 93: { 94: cout << "Server: withdraw " << amount << endl; 95: if (_balance >= amount) 96: _balance -= amount; 97: else 98: cout << "Server: withdraw failed" << endl; 99: }100: 101: CORBA::Long balance ()102: {103: cout << "Server: balance " << _balance << endl;104: return _balance;105: }

106: };107: 108: int109: main (int argc, char *argv[])110: {111: // Initialize the ORB112: CORBA::ORB_var orb = CORBA::ORB_init (argc, argv);113: 114: // Obtain a reference to the RootPOA and its Manager115: CORBA::Object_var poaobj =116: orb->resolve_initial_references ("RootPOA");117: PortableServer::POA_var poa =118: PortableServer::POA::_narrow (poaobj);119: PortableServer::POAManager_var mgr =120: poa->the_POAManager();121: 122: // Create an Account123: PortableServer::Servant account_servant =124: new Account_impl;125: 126: // Activate the Account127: CORBA::Object_var the_account =128: account_servant->_this();129: 130: // Write the object's IOR to a file131: CORBA::String_var ior =132: orb->object_to_string (the_account);133: ofstream of ("account.ior");134: of << ior;135: of.close ();136: 137: // Activate the POA and start serving requests138: cout << "Running." << endl;139: mgr->activate ();140: orb->run();141: 142: // Shutdown (never reached)143: poa->destroy (TRUE, TRUE);144: delete account_servant;145: 146: return 0;147: }

CORBA C++ Client148: // File: client.cc149: 150: #include <iostream>151: #include <fstream>152: #include "account.h"153: 154: using namespace std;155: 156: int157: main (int argc, char *argv[])158: {159: // Initialize the ORB

160: CORBA::ORB_var orb = CORBA::ORB_init (argc, argv);161: 162: // Connect to the Account163: ifstream f ("account.ior");164: string ior;165: f >> ior;166: CORBA::Object_var obj =167: orb->string_to_object (ior.c_str());168: Account_var account = Account::_narrow (obj);169: 170: // Deposit and withdraw some money171: account->deposit (700);172: cout << "Client: balance is "173: << account->balance () << endl;174: account->withdraw (50);175: cout << "Client: balance is "176: << account->balance () << endl;177: account->withdraw (200);178: cout << "Client: balance is "179: << account->balance () << endl;180: 181: return 0;182: }

CORBA Java Client183: // File: Client.java184: 185: import java.io.*;186: import org.omg.CORBA.*;187: 188: public class Client {189: 190: public static void main (String[] args) {191: // Initialize the ORB.192: ORB orb = ORB.init (args, null);193: 194: String ior = null;195: try {196: FileReader file = new FileReader (args[0]);197: BufferedReader br = new BufferedReader (file);198: ior = br.readLine();199: } catch (IOException e) { 200: System.out.println ("Could not open file '" +201: args[0] + '"');202: System.exit (1);203: }204: 205: org.omg.CORBA.Object obj =206: orb.string_to_object (ior);207: Account account = AccountHelper.narrow (obj);208: 209: account.deposit (700);210: System.out.println ("Client: balance is " +211: account.balance ());212: account.withdraw (50);213: System.out.println ("Client: balance is " +

214: account.balance ());215: account.withdraw (200);216: System.out.println ("Client: balance is " +217: account.balance());218: }219: }

CORBA Java Server220: // File: Server.java221: 222: import org.omg.CORBA.*;223: import org.omg.PortableServer.*;224: 225: // Implementation for interface Account226: class AccountImpl extends AccountPOA227: {228: private int _balance;229: 230: public AccountImpl ()231: {232: _balance = 0;233: }234: 235: public void deposit (int amount)236: {237: _balance += amount;238: }239: 240: public void withdraw (int amount)241: {242: if (_balance >= amount)243: _balance -= amount;244: }245: 246: public int balance ()247: {248: return _balance;249: }250: }251: 252: public class Server {253: 254: public static void main (String args[])255: {256: try {257: // Initialize the ORB258: ORB orb = ORB.init (args, null);259: 260: // Get a reference to the RootPOA and its Manager261: POA rootPOA = POAHelper.narrow(262: orb.resolve_initial_references("RootPOA"));263: 264: // Create an Account servant265: AccountImpl account_servant = new AccountImpl ();266: 267: // Activate the Account object

268: rootPOA.activate_object (account_servant);269: 270: // Write the object's IOR to a file271: String ior = orb.object_to_string (272: account_servant._this_object());273: java.io.FileWriter file =274: new java.io.FileWriter ("account.ior", false);275: file.write (ior+"\n", 0, ior.length()+1);276: file.flush();277: file.close();278: 279: // Activate the POA and start serving requests280: System.out.println ("Running.");281: rootPOA.the_POAManager().activate();282: orb.run();283: } catch (Exception e) {284: System.err.println ("Exception in Server " +285: "Startup " + e);286: }287: }288: }

COM Versus CORBA

Although CORBA and COM both allow applications to communicate in order to use objects, they do not accomplish this task equally well. The following comparison looks at the usability of COM and CORBA across the Object Web.

Comparison COM CORBA

Architecture, Definition, Specification

Lack of overall architecture

Multiple retargeting and redefining in order to promote Microsoft products

Opposed to public specifications

One constant vision since 1989

Architecture and individual specifications are vendor neutral

Direction and definition are public processes, including a broad cross-industry consensus

Specifications are available to everyone

Free rights to implement software using the specifications

Cross-Platform Support

Implementations work on Microsoft operating systems

According to Microsoft representatives, where specification and Microsoft implementations differ, Microsoft considers its own implementation to be definitive.3

Implementations support multiple platforms, including Microsoft.

Cross-Language Support

C++

Support for other programming languages is a problem. DCOM requires passing C-style memory pointers between applications.

Designed from the beginning to be language-neutral to accommodate a wide range of languages including:C, C++, Ada, Smalltalk, COBOL, Java, Visual Basic, FORTRAN

Maturity and Continuously changed Specifications published in

Deployment

specifications and code Key documents are

available in draft form only

Available to end-users in the last couple years

1991 Broad industry consensus

and support

Seven year use around the world

Support for WWW

Based on native machine code, requiring a separate version of every object control for every browser platform

Java mobile code easily deals with cross-platform support

Security - All distributed communication involves risk

Confidentiality (using encryption)

Authentification (confirmation messages came from objects entitled to issue them)

Compiled for C++ without any security restrictions

No confidentiality

No authentification

Java applets are insulated from direct contact with the host system by running on a virtual machine. This provides a "sandbox" around the applet that enforces security restrictions.

Confidentiality system Authentification system

Non-repudiation system ensures that users cannot deny their commitments later, accommodating international legal requirements for security auditing

Scalability

Not designed for large-scale networks

Uses reference counts that require programmers to manipulate them by hand

Uses keep alive messages (pinging) every two minutes. After six minutes of no response, the connection between client and server is severed.

Designed for Internet-scale applications from the beginning.

No reference counts necessary

No keep alive messages necessary

To sum up this comparison, COM was never designed for Internet-scale inter-object communication. It is merely an adaptation of an architecture originally designed for a single machine with non-distributed tasks. It falls short in efficiently handling the Object Web. Microsoft has tried to scale its architecture to the enterprise and internet to promote the use of Microsoft products.

Conversely, CORBA was primarily designed to support interoperability across network boundaries. The OMG has worked toward creating standards for object component software for the good of all who use these objects. By successfully creating interoperability of disparate systems, CORBA is helping the evolution of the Object Web.