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 even more things. Most application programmers prefer to keep that
black box closed. They'll 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 top-down view has led to a characterization or categorization of products
according to how they are accessed. Essentially, programmers define middleware
products by their APIs. This is like telling the difference between two
boxes by looking only at the handles. Yes, the handles
might indeed be different,
but underneath the suitcases might hold the same amount of clothes.
The current set of handles on the middleware boxes define the general API
differences between middleware products. Today, these middleware handles
include:
Message-oriented products
typically offer
a very basic set of commands with which to communicate over the network,
often as few as SEND and RECEIVE. Application developers then create application-specific
functions or routines built on top of these basic functions. As far as transports
go, the interface itself is even simpler than programming to a particular
network transport API like TCP/IP sockets, and the message-oriented API
is provided for whatever network transports are actually supported by the vendor,
not just for one single protocol.
RPC-based products
are procedure or function
oriented. Developers define functions using an interface description language
(IDL), and then compile that function into client and server stubs that
actually do
the networking. So, to call these functions, the developer uses
function calls within a development tool (3GL languages like C and 4GL products
like PowerBuilder.) The key for the developer is whether the RPC-based middleware
generates functions in the tool actually used to develop applications in.
While many 4GL tools can call C functions, it is easier if the functions
show up more natively. One might say that developers create their own APIs
using RPC-based solutions. For applications that have been multiuser system
based but are now being distributed, the RPC approach is very intuitive:
Each existing function can be split across the network as needed.
Data access products
offer data-oriented
APIs that reveal tables and data in them. Epitomized and standardized in
ODBC, applications that want access to data can get at remote data using
a standardized language called SQL. Each individual RDBMS vendor, however,
has its own proprietary API as well, since that lets them directly expose the
unique functionality of their RDBMS. If the application being developed
only needs to have its data distributed to database servers on the
network, then this API suits the application well. So far, most client/server
development has focused on this type of interaction, though this is more
restricting than other generic solutions. Here, only the data can be on another
node; with all the others, whole pieces of the overall application can be
split across the network to run on other nodes.
On the other hand, this is the only middleware solution that is directly
usable by the large army of ad-hoc developers at the average desktop. All
other middleware solutions need programmers on both ends. Data access middleware
just has data on one end and any kind of data access tool on the other.
The typical data access product does not provide a bidirectional interaction.
Servers can't contact clients out of the blue. They can only respond when
asked
. While the more recent development of stored procedures provides some
additional program execution across the network, this is still limited to
SQL data manipulation and RDBMS-product specific at that. Most data access
middleware is based on a synchronous request/reply model like RPC-based
products.
Distributed transaction processing (DTP) monitor
products
offer a middleware environment oriented toward handling
transaction semantics over a network. In addition to the SEND and RECEIVE
functions of the message-oriented products, transaction monitors add BEGIN
and END TRANSACTION commands to the list. Naturally, the DTP product had
better deliver the kind of control over those transactions required to assure
that the transactional semantics are enforced. DTP products are often message-oriented
or RPC-based products with added control functionality.
Finally,
object request broker (ORB) products
support network interaction between pieces of an application with
yet another programmer API: the object. Once the developer starts working
in an object-oriented tool (3GL like C++ or 4GL), the easiest middleware
to employ may well be middleware that directly networks the objects created
in the tool. An ORB just lets the developer of an application composed
of many objects easily partition those objects onto different network nodes.
It's like the RPC-based approach, except this time it's for object-oriented tools
and not function-oriented tools.
If the object-oriented developer does not get an ORB, the programming job
will be complicated by having to create links between objects and the functions
or other APIs offered by the other middleware solutions. That's more work.
The ORB world has many standards, most generically the Object Management
Group's Common Object Request Broker Architecture (CORBA) but also including
defacto standards like Microsoft's OLE (which is waiting for Cairo to gain
it's d
istributed functionality) and OpenDOC.
REPORTS
Analyize In-Line NAC strategies and products.
ANALYTICS Plan and design your enterprise blade server deployments
InformationWeek U.S. IT Salary Survey 2008
Salaries for business technology professionals are falling. Here's what you need to know in order to make good hiring decisions and personal career choices. Download Today
REPORTS
ANALYTICS
Follow 
