29-1 Contrast Message Oriented Middleware (MOM) with the message passing we defined in Chapters 14 and 16. (Hint: consider the reliability of the transmission).

MOM has much in common with asynchronous message passing. In both, the transport system buffers messages and this decouples the sender and receiver. In both, a high level aim may be to transfer named, typed values yet implementations may transfer packets of bytes. In Chapter 16 we noted that, in a distributed system, a protocol is needed underlying any communication to allow for connection or node failure. This is also the case with MOM. A difference is the available products is that reliable transmission may be offered. This means that the implementation must store messages in transit in persistent storage until they are acknowledged as received. There are also differences in the message naming schemes, for example we might be offered only subject-based publish-subscribe (instead of attribute-based)

29-2 Contrast MOM with Object Oriented Middleware (OOM). List as many differences as you can.

MOM is asynchronous and senders and receivers are decoupled. The message transport system buffers messages. Senders and receivers need not be running at the same time. OOM is based on synchronous invocation; the invoking and invoked objects must be running at the same time.

29-3 What is meant by open interoperability? Contrast the approach taken by OMG CORBA with that of Sun?s Java and Microsoft?s DCOM.

CORBA allows components written in different programming languages to interoperate by providing language bindings to a common CORBA IDL (interface definition language). Java is a single language system. DCOM also defines an IDL and heterogeneous interoperability. It supports binary encapsulation and binary compatibility in that objects can communicate without recompilation, but this is at the expense of forcing developers to use a single common implementation strategy.

29-4 What interaction paradigm does a tuple space aim to support? What operations do the Linda programming language and JavaSpaces support. What problems would arise if a tuple space was to be distributed?

A tuple space potentially supports one-to-many communication in that many processes may listen for a given value to appear in a tuple, then read it, destructively or non-destructively, as specified. See Chapter 12 for Linda?s operations and Section 29.2 for Javaspaces within Jini. Jini assumes a single centralised tuple space. This does not scale to a widely distributed system. If a tuple space were to be replicated the problems would be similar to replicating the state of any writeable service: consistency and availability, see Chapter 22.

29-5 How is service naming and location supported in OMG CORBA and Java middleware?

The Java Naming and Directory Interface (JNDI) is a standard extension to the Java platform, providing Java applications with a unified interface to multiple naming and directory services such as LDAP. By this means services can publish their interfaces and locations and clients can look them up. The CORBA naming service allows a human-readable name to be bound to an object reference. The CORBA trading service supports name to location mapping. Use of a trader is similar to that described for ANSA in Chapter 16, involving export (advertisement) of interfaces to the trader by services, import by clients, then clients may invoke a service using the imported interface.

29-6 What is the purpose of an Interface Definition Language (IDL?)

To define object interfaces so that object interaction is independent of the programming languages in which the object and its invoking objects are written. Programming language bindings are defined for supported languages, mapping language types to IDL types. An IDL compiler creates at least two files: a client stub and a server skeleton. An ORB comes with an IDL compiler for each language it supports.

29-7 How have the OOM platforms been extended with asynchronous communication? Are these services equivalent to MOM services? To what extent has MOM moved towards the approach taken in OOM?

MOM is inherently asynchronous. It has moved from supporting untyped to typed messages; XML is becoming popular for this purpose. OOM is inherently synchronous and some of the early attempts to provide asynchronous interactions have built them above synchronous ones; that is, the interacting components must be running at the same time. An example is CORBA one-ways. CORBA AMI (asynchronous message invocation) still does not uncouple invoker and invoked objects but allows the invoker to leave a callback address or poll later for a result. OOM typically envisages a locally distributed, rather than a wide-area, scenario. A JMS interface has been provided for MQSeries MOM, thus supporting scalable, widely distributed messaging.

29-8 Contrast the approach taken in IBMs MQSeries MOM with that in the TIB/Rendezvous MOM. Contrast the design of names in the two systems.

Both use communications-style routing rather than naming, directory and location services. The names in MQSeries are of queues, supporting for example, the interaction of many clients with large databases. A queue name is used by a client to communicate with a known server. TIB/Rendezvous is a publish/subscribe system; names represent topics/subjects and comprise a sequence of strings. Subjects are assumed to be known statically.

29-9 How has the widespread acceptance of the Web affected the design of middleware? Give examples of how recent middleware is adopting the Web paradigm. What are the pros and cons of this?

Increasingly, a browser is becoming the standard client interface in distributed systems. An advantage is a widely accepted interface capable of running on any operating system. A disadvantage is that this has caused XML to replace the sophisticated type systems of O-O middleware for transmission (and even storage) of data.