Home > Articles > Networking > Network Administration & Management

  • Print
  • + Share This
This chapter is from the book


In the context of NDC, the middleware fitscape eases the task of designing, programming, and managing distributed applications by providing simple, consistent, integrated distributed programming environments. Middleware is essentially a distributed software layer, or "platform," which attempts to abstract complexities and even mask many of Deutsch's Eight Fallacies from developers.


Different middleware platforms support different programming models. One popular model is object-based middleware, in which applications are structured into (potentially distributed) objects that interact by location-transparent method invocation. Examples of this type of middleware are Common Object Request Broker Architecture (CORBA), from the Object Management Group, and Microsoft's Distributed COM (DCOM).[32] Both platforms offer an interface definition language (IDL) that abstracts the fact that objects can be implemented in a variety of suitable programming languages. Both also offer an object request broker, which is responsible for transparently directing method invocations to the appropriate target object, as well as a set of services including naming, time, transactions, and replication, which further enhance the distributed programming environment. A word of caution here, with reference to A Note on Distributed Computing: There are inherent differences between local and distributed objects that may not be so easy to ignore. While some work can be accomplished with models like DCOM and CORBA, other NDC applications designs may not so readily lend themselves to this type of approach. (Some of the limitations of DCOM and CORBA from a middleware perspective are discussed later.)

Other Paradigms

Not all middleware is object based. At least two other popular paradigms exist, as well as many derivatives, which are the subject of research and investigation. Event-based middleware and message-oriented middleware are both in use today. Both employ a "single shot" communications approach rather than the request-reply approach found in object-based middleware. Event-based middleware is particularly suited to the construction of noncentralized NDC applications that must monitor and react to changes in their environment. Examples include process control and Internet information channels such as stock tracking, sports score tickers, and the like. Event-based middleware proponents claim this paradigm has potentially better scaling properties than object-based middleware for such applications, which may be a reasonable claim given the less communications-intensive approach. Message-oriented middleware, on the other hand, is biased toward applications in which messages need to be queued and persistently stored. Workflow and messaging applications are examples.

Interesting areas of investigation include charming approaches like "mChaRM: Reflective Middleware with a Global View of Communications," which is a multichannel reification model being pioneered by Walter Cazzola of the University of Genova.[33] In computer science, reification (from the Latin re, "thing," to regard or treat an abstraction as if it had concrete or material existence) refers to the action by which information is transferred (read or copied) from an internal mechanism of a system into the domain within which it may be utilized as a processing entity. Reflection is the action by which information is transferred from the domain of such a system to its internals. The Java Core Reflection API, for example, "provides a small, type-safe, and secure API that supports introspection about the classes and objects in the current Java virtual machine. If permitted by security policy, the API can be used to

  • Construct new class instances and new arrays

  • Access and modify fields of objects and classes

  • Invoke methods on objects and classes

  • Access and modify elements of arrays[34]

Walter Cazzola's mChaRM as shown in Figure 3.8 is a reflective model that allows the system to reify multipoint communications instead of objects. Each method invocation can be reified into a multichannel, which can perform metacomputations about it before real activation need occur. In this way, classic communication semantics can be enriched with new behaviors and properties, and theoretically the flow of communications in an ensemble could be modeled before the ensemble is assembled, which could potentially be very powerful indeed.

03fig08.gifFigure 3.8. General distributed filesystem models: mChaRM, multichannel reification model (dsonline.computer.org/middleware/articles/dsonline-mcharm.html)

Middleware has been responsible for much of the contention, confusion, investment, and progress of NDC. It is also key to the future if progress toward global ubiquitous computing is ever to be realized.

  • + Share This
  • 🔖 Save To Your Account