Top
Return
to Yazoo City Return
to DS 420 Projects Page
In its broadest definition, middleware is any piece of software that links two other software components (such as databases or customer information systems) across some type of border or boundary. The border could be a wide area network, a local area network, or it could be the memory inside your PC.
More specifically, it may refer to software that sits on a middle tier between an object residing on one server machine and any number of clients that want to access that object. Middleware provides a programming interface that allows the object to be accessed. The object will run in as many different computer environments as the middleware runs in.
Everybody wants the latest applications, running on several different computer platforms, often geographically scattered. The trick is how to link them together via a private or public data network, find a common language so they can talk to each other, and create a common framework so they can work together productively. That's what middleware is all about. It's the enabling technology that allows you to bridge and communicate with all the various players in a diverse computing environment.
The purpose of middleware is to accomplish this task in such a way as
it is hidden from the user and, to some degree, the programmer. For many
programmers, middleware is like a "black box". Middleware helps get the
job done more quickly and keeps the programmer from having to worry about
the complexity involved with what is happening. Most application programmers
prefer to keep that black box closed. They will learn how to make calls
to the box and get results back, but they won't try to understand what
goes on in the box. This is the important idea to know -- the function
that middleware provides is hidden. The complexity is removed so that applications
and information can be smoothly and easily accessed across distinct architectures,
protocols and networks.
A company's success depends on flexibility. It must have an information
system that can respond to changing business requirements. Distributed
and component-based architectures, tools, and systems have been the tactic
used by companies to stay flexible in the recent past. However, without
some form of "plumbing" to connect them, these architectures are no different
than the cumbersome, island-like systems that they were before. Middleware
provides the bridge system required to connect existing systems. When implemented
properly with middleware, distributed systems are as reliable and robust
as mainframes, but promise a higher degree of flexibility and scalability.
Thus, middleware contributes to a company's overall success.
For discussion purposes, middleware can be divided into five categories: database middleware, remote procedure calls (RPC), object request brokers (ORB), transaction-processing (TP) monitors, and message-oriented middleware (MOM).
Database middleware - Middleware that performs only database
access; it does not transfer calls or objects. Database-oriented middleware
includes those middleware products that enable applications to communicate
with local or remote databases. Database middleware is the way to go if
you only need to enable your client systems to communicate with one or
more databases. Database middleware represents more than half of the entire
middleware market.
By using RPC, the complexity involved in the development of distributed processing is reduced by keeping the semantics of a remote call the same whether or not the client and server are located on the same system. However, RPC increases the involvement of an application developer with the complexity of the master-slave nature of the client/server mechanism.
RPC increases the flexibility of an architecture by allowing a client
component of an application to employ a function call to access a server
on a remote system. RPC allows the remote component to be accessed without
knowledge of the network address or any other lower-level information.
Most RPCs use a synchronous, request-reply (sometimes referred to as "call/wait")
protocol, which involves blocking of the client until the server fulfills
its request.
Limitations
ORBs fall into two main categories: those products that conform to the CORBA (Common Object Request Broker Architecture) standard and Microsoft's COM/DCOM technology.
CORBA is a set of specifications published by the Object Management Group (OMG); an industry consortium whose mission is to define a set of interfaces for interoperable object-oriented software. These specifications establish the way objects are defined, created, dispatched, invoked, and how they communicate with each other.
The Microsoft equivalent to CORBA is COM/DCOM. At the core of COM/DCOM Microsoft component architecture is the Component Object Model. It supports the creation and destruction of objects, as well as the ability to define and to dispatch objects, and to traverse and interrogate object interfaces.
An additional, newly-emerging ORB model is Remote Method Invocation
(RMI). This is part of the Java language virtual machine. RMI allows Java
objects to be executed remotely.
In some environments, it is essential to ensure that every transaction
goes through, that it does not go through more than once, and that your
machine informs you if a transaction fails for any reason. For this type
of application--the automated teller machine is a classic example--a TP
monitor guarantees delivery of each transaction or immediate communication
of its failure. For many operations, TP monitors are most useful in synchronous
operation, which means that the machine waits for each transaction to be
completed before beginning another.
MOM increases the flexibility of an architecture by enabling applications
to exchange messages with other programs without having to know what platform
or processor the other application resides on within the network. The messages
can contain formatted data, requests for action, or both. MOM systems provide
a message queue between interoperating processes, so if the destination
process is busy, the message is held in a temporary storage location until
it can be processed which guarantees message delivery. MOM is typically
asynchronous and peer-to-peer, but most implementations support synchronous
message passing as well.
Limitations
It is difficult to categorize middleware into these distinct technologies,
because the environment and needs of the company demand interoperability
among different technologies. For example, once you start looking at specific
middleware packages, you'll find that most products encompass at least
two and often three of these categories, and the trend is heading toward
products that include features from all types of middleware.
As middleware is a relatively new and quickly evolving product, an in-depth discussion of vendors may become out of date quickly. In a brief discussion, it is worth mentioning that BEA, Inc.'s Tuxedo is a very popular TP middleware item. IBM's MQseries is an extremely successful MOM item.
Below is a link to a site that lists several middleware providers and gives a link to their web pages.
http://www.dbmsmag.com/9709d141.html - Directory of Middleware Providers