 |
|
|
 |
||
 |
||
 |
||
 |
||
 |
||
 |
 |
|
 |
||
 |
||
 |
||
 |
||
 |
||
|
||
 |
Your independent resource on business integration and network computing through middleware and message brokering
The rise of messaging middleware; the decline of DOLTP
Charles CC Brett President, C3B Consulting Limited and President of the International Advisory Board
Management introduction
The rise of messaging middleware is underway. At the same time the anticipated expansion of the Distributed OnLine Transaction Processing (DOLTP) market place has failed to materialize - and shows few signs of obtaining sufficient of a jump start to restore its prospects.
Why is this occurring? It is not because DOLTP is not needed. DOLTP is needed. Instead, as observed in the May, 1994 OTM Spectrum Report, transaction processing management software is losing out to apparently simpler, and therefore more understandable, initiatives. Most prominent among these is the continuing success of the merchant database vendors (notably Oracle, Sybase and Informix) in their efforts to persuade users (not IT) that data is all and that distributed systems are an unnecessary complication where consideration can be put off for years. Messaging middleware, with good reason, looks as if it is becoming yet another enemy of DOLTP.
Messaging middleware
This Report, therefore, concentrates on messaging middleware and on opening up several of its different dimensions. There is:
- an interview about TOP END which must be a prime (if largely unknown) candidate for messaging and distributed transaction management (page 9)
- an interview with the President (and Interim Chairman) of MOMA, the re-founded Messaging Oriented Middleware Association (page 17)
- an analysis of six of the most prominent players (COVIA, Momentum, IBM, Digital, PeerLogic and Suite Software) and their products when thinking about core infrastructure and messaging middleware (page 25)
- an examination of how transactional messaging can be considered one of the best technologies for distributed transaction processing in federated systems, and even for some partitioned ones (page 34)
- a description of the complexities with which SAP had to wrestle in order to provide its R/3 application suite with robust client/server transaction processing, plus a look at how messaging will enable R/3 to escape from its current, essentially host-like (single database) orientation (page 51).
Inevitably this mix does not make for the lightest of reading. Nevertheless the implications should be of ever increasing importance to IT managements.
Distributed systems are already a reality (even if many have yet to be connected to each other). What has yet to materialize are technologies to help simplify delivery of client/server and working, reliable distributed systems - whether transactional or not.
The case for messaging middleware
The case for messaging middleware's increasing popularity with IT managements is that it offers multiple ways to:
- connect different systems without having, necessarily, to redevelop existing applications
- decouple what have hitherto been insurmountable systems dependencies (for example overcoming the inherent blocking found in RPCs or APPC)
- open up application connections between increasingly mobile workforces who need temporary, flexible yet reliable methods of linking into home office applications
- exploit both existing IT investments and skills as well as introduce new ones
- provide implicit transaction integrity (because writing to/from queues and between queues can, in some systems, be deemed to be robust).
The essence of messaging middleware lies in putting messages on queues. This is the notion that an application on System A writes a message (of pre-agreed structure and characteristics) onto Queue A (on System A). System A's queue manager then opens up (immediately or later) an automated dialog with the queue manager on System B (and C and D or ...) in order to transfer reliably the original message to Queue B. At this point the intended recipient application on System B can take the message off Queue B and process it.
Conceptually this is very simple. It is also practical. It is not even new (TCAM, IMS, etc.) except across the heterogeneous environments which organizations possess today.
From the above description it is easy to see the attraction. If existing applications can write to a queue (say as a print stream) or receive from another queue (say as a terminal data stream), then existing applications can be linked to other existing ones, or to new ones. Similarly decoupling time dependencies removes the need for one system to wait for another (if either System B or Queue B are not available, Queue A can wait until they are or return a failed message to the originating application without that original application having to 'block' until a reply is received).
Not only does message queuing open up clients (say System A) to connect to server(s) but application development may be undertaken using existing skills. Server programmers do not have to possess PC or workstation skills, only an understanding of what goes onto, and comes off, each queue. For the PC developer the same is true.
Add to this the possibility of transactional message queuing (being able to rely on queue transfers, that only one message is transferred and that automated rollback/recovery is available) and implicit transaction processing becomes possible. It is this last which is likely to prove so wounding to DOLTP.
Management conclusion
However, as the various analyses in this Report demonstrate all too well, vendors can make messaging middleware extremely confusing with great rapidity. For example, one set of varietals includes simple messaging, inter-process messaging, non-persistent messaging, persistent messaging and transactional messaging. Telling the difference between each is not always easy.
You can add to this other arguments. Some believe that a whole core of services infrastructure is demanded beneath messaging. Others believe that it is the queuing mechanism which is all important (and that the other complementary services must be regarded as desirable luxuries whose need must not be allowed to slow down the exploitation of what messaging offers today). These discussions all too often become sterile. What OTM Spectrum Reports believes is that messaging is but one - if possibly the most important - dimension to a distributed middleware world which necessarily includes:
- ORBS, and the distributed OO environment
- distributed transaction management
- distribution of data access
- systems management across distributed systems.
Middleware, with its various complementary levels, is now assuming the lead role in enabling distributed computing. This was an area where we had anticipated open transaction management would take the initiative. The scale of change is now accelerating so fast away from DOLTP that our analysis is that we should be re-orienteering, even renaming, OTM Spectrum Reports in order to mirror the market.