Middleware Technologies [MCA II Yr, Anna University] by Roy Antony Arnold

HOW CAN CORBA ENABLE CLIENT/SERVER COMMUNICATION?

A server is defined as an Interface in CORBA IDL. Data passing between the client and the server is defined as IDL structures, sequences, etc. The IDL is compiled with an IDL compiler and the generated code is included within the client and server processes. The server implements a particular interface. The implementation is the distributed object. Clients communicate with the object through an object reference. When an operation is performed on the object reference, network communication occurs, operation parameters are sent to the server and the actual distributed object executes the operation. It then returns any appropriate data to the client.

DO ANY CLIENT/SERVER LIMITATIONS EXIST WITH CORBA?

Depends on the specific vendor and product offering, but there is nothing in the standard that you will find terribly onerous.

Some applications want to make distributed requests, but not wait for the response. Ideally, they want to be notified when the response is available. Threads can be used to allow applications to make more than one request or to continue performing other tasks while waiting for a response, but the thread making a request is blocked until the response is available. CORBA communication is basically a synchronous request/response. This is true for all static invocations. Dynamic invocations do support a deferred request response. This means that an application can issue a request and poll for the response. CORBA communication can be used to notify applications when responses associated with earlier requests are available. This can lead to a more complex application architecture.

I NEED A CORBA ORB? WHERE CAN I GET ONE?

Before you can use CORBA to client/server communication you must either implement your own request broker that supports portions of the CORBA specification including IIOP (not suggested) or you can obtain an object request broker that implements the CORBA specification. Many companies sell object request brokers that implement all or some of the CORBA specification, including various parts of the CORBA 2.x and 3.x specification, CORBA services, and other third-party integrations. Links to their company web sites are included (alphabetically) below:

• ATT omniORB.
• BEA M3.
• DSTC fnorb.
• Expersoft CORBAplus.
• Franz Orblink.
• IBM ComponentBroker.
• Inprise VisiBroker.
• Iona Orbix.
• MICO.
• Object Oriented Concepts ORBacus.
• Objective Interface ORBacus.
• ObjectSpace Voyager.
• PeerLogic DAIS.
• RogueWave Nouveau.
• Xerox ILU.
• Washington University TAO.

Additional information can be found at: * OMG List of free stuff.

• List of ORB vendors maintained by CETUS Links.
• List of free ORBs.

ARE REMOTE INVOCATIONS BLOCKING OPERATIONS?

The CORBA specification makes no specific statement regarding the blocking behavior of remote invocations. It does require that static invocations be synchronous. This means that an application will not proceed to the next line of code following a remote invocation until the remote invocation returns, either normally or abnormally. A non-blocking, or dispatching remote invocation will allow event processing for the duration of the remote invocation. This means that ORB or non-ORB events can be processed while an application is “waiting” for an invocation to return. ORB events could be object connection requests or object invocation requests. Non-ORB events might be GUI events such as mouse clicks, signal handling, or raw file descriptor activity. The CORBA specifications allows the CORBA vendor to decide on the blocking or dispatching behavior for remote invocations. CORBA products that use blocking transports such as the DCE RPC are un-able to support non-blocking remote invocations.

CAN DEAD LOCKS OCCUR BETWEEN CORBA SERVERS?

Dead-locks can occur between two or more CORBA servers. Dead-locks can only occur under certain conditions. First of all, a cyclic or looping relationship must exist between the servers. For example: one server must make invocations on the second server which is in turn implemented to make an invocation upon the first server. This situation is referred to by some as nested call-backs. While cyclic relationship between servers might seem easy to avoid, it often arises, if CORBA is being used to support the combination of client/server request/response and server/client notification. If a cyclic relationship exists and a remote invocation blocks a process, a dead-lock will occur. Blocking can occur upon remote invocation if multiple threads are not used and the CORBA product does not dispatch events while remote invocations are being performed.

I USE MICROSOFT PRODUCTS; WHY SHOULD I USE CORBA AND NOT DCOM?

DCOM is a Microsoft specific distribution solution. CORBA products are available from over 20 different vendors. CORBA products support Microsoft and non Microsoft operating systems. CORBA is an excellent mechanism to bridge between Microsoft desk tops and UNIX servers.

MUST I CHOOSE BETWEEN DCOM AND CORBA?

No. Distributed applications can be developed using both CORBA and DCOM. For example, a client application might be developed to access a set of OLE automation objects, and OLE automation objects might in turn access CORBA objects running on a non-Microsoft platform such a UNIX. The OMG has defined a COM<->CORBA interworking specification which standardizes this sort of bridging.

IS CORBA MORE MATURE THAN DCOM?

CORBA has existed since 1990. Commercial implementations have been available since 1992. DCOM was made available in beta form in 1996. CORBA has had more time to mature. There are also a large number of different companies developing CORBA ORBs. This level of competition increases the robustness of CORBA solutions on the whole.

WHAT ADVANTAGES DOES DCOM HAVE OVER CORBA?

DCOM is well suited to front-end application development. If entire distributed application runs under Microsoft platforms, DCOM might be a good choice. DCOM can also be used with CORBA.