 |
|
|
 |
||
 |
||
 |
||
 |
||
 |
||
 |
 |
|
 |
||
 |
||
 |
||
 |
||
 |
||
|
||
 |
Your independent resource on business integration and network computing through middleware and message brokering
The rise and rise of Middleware
Charles C C Brett, President, C3B Consulting
President of the International Advisory Board, MIDDLEWARESpectra
Management introduction
In the past decade a major upheaval has occurred. It encompasses the rise and rise of middleware.
Ten years ago the emphasis was still very much on hardware. While connecting different systems was a goal, it was not a high priority one. Most systems existed in parallel and, when intercommunication was needed, it was reluctantly provided via some form of gateway, usually with poor performance and reduced capabilities.
By the late 1980s much had changed. The arrival in quantity of PCs was happening. More significantly two simultaneous changes of orientation were happening:
- connecting heterogeneous platforms
- had become a priority business
- expectation (although not a functional reality)
- software had taken over - from hardware -
- is the prime point of focus.
In 1992 another event occurred (according to IDC). Dollar revenues from standalone systems exceeded those from multi-user systems sales. Not only had the PC matured but it had motored past its more traditional siblings. It has never looked back. In 1993 more PCs/workstations were sold worldwide than automobiles, a statistic that will be repeated in 1994 and probably for ever after.
What does this have to do with Middleware? The answer should be self-evident, even if the delivery is not that simple. Tens of millions of clients (PCs and workstations) need to communicate. They need software to 'be in the middle' - between two or more clients (and not just to servers). At the same time these clients need additional services - which could be provided by traditional hosts, minis, servers, etc. or by clients acting as servers (displacing traditional IT provision).
A need exists. It is for middleware which works, for middleware oriented at first to the worktop and then to existing IT. But this middleware is unlikely to be provided by traditional suppliers in the way that systems and software have been created in the past.
The demise of the common API approach
In 1987 IBM announced SAA. Within weeks it was followed by Digital's NAS, Hitachi's HAA and - over the next five years - an assortment of descriptions aimed at enabling heterogeneous platform interaction. The approach chosen to deliver this was what can be called the 'common API approach' (see page 16 of this Report for a fuller examination). This was intended to establish common interaction with common Application Programming Interfaces (APIs) on all participating platforms. Middleware, as we think of it today, did not matter.
This approach failed. As Bill Laing of Digital comments (page 10), 'it has not proved practical to expect the same programming environment and API at each end ... where developers would be liberated by having to write for only one interface'.
One example of this failure is OSF's Distributed Computing Environment (DCE). While DCE is architecturally and conceptually attractive it has not caught on - neither with users, nor software vendors nor even system vendors (except in marketing hype). One problem has been that progress has been snail-like. At the same time it, DCE, was really only designed for a UNIX-dominant world. The evidence for this is in DCEis complete ineptitude, when PCs are introduced into the equation.
DCE's tragedy is not in its thinking or its technical basis. It is that it was born after its time. System vendors (like HP, Digital, IBM, Bull and others) assumed that the world would want a Distributed UNix Competing Environment. Unfortunately the 100 million plus PCs sold in the past five years have put paid to that notion, and to any idea that the PC can be ignored or sublimated to the requirements of the UNIX visionaries.
In effect DCE is the latest, and possibly last, of the common API approaches which originated on conventional systems. DCE (and OSF) are now failing, despite the cacophonous upbeat messages emanating from system vendor marketing departments. But what is manifestly not there is public support from hundreds of software application vendors.
This is the final indication that the time for the common API approach has passed. It did not deliver the goods needed for the middleware that is demanded now.
Inverting the model
One factor has always dominated the software world. It is the number of platforms sold. In 1980 IBM's platforms were the most important because they had the largest base. This is what attracted developers and entrepreneurs. In 1994 it is estimated that some 35M-40M PCs/workstations (probably worth over $100B) will be sold. By comparison traditional systems (from hosts to minis to the new large servers models) will sell less than 2M systems.
Software developers understand numbers. What they see in the platform world is:
- a potential audience of from millions to tens of millions
- an audience that is massively distributed, physically, and open to (middleware) connectivity
- an opportunity where selling to as few as 2% means millions of units
- a conventional IT customer base where obtaining a 60% (always near impossible) penetration - despite higher unit prices - is still an insufficient reward.
Workstation numbers act as a magnet for the large majority of software investment. Development dollars are poured in - are still being poured in and will continue to be poured in - to create new software for the distributed desktop - for the tens of millions of clients who are now the single dominant force in the industry. That software now includes middleware.
What has happened, and is happening, is a reversal of the common API approach - which started from the server and aspired to reach out to the client. Today, middleware developers focus on the desktop first - for interconnecting with other desktops; only then, when this is satisfied, do they broaden their interoperability to link into conventional systems.
Furthermore it is these developers who will most likely be successful. By making their middleware accessible and installable - across all the categories shown in Figure 1 - they seize the middleware initiative. They become the important players of tomorrow.
At odds with the past
This will result in a very different slant on middleware to that which IT (and its vendors) has been anticipating. It is, in part, the rationale for this publication. Whereas traditional IT has expected to be the arbiter of middleware (middleware, after all, connects to its systems), the future is likely to be very different to that which was sought two, never mind five, years ago. However, the likelihood is that, with middleware, it will also be easier to handle the new, de facto, distributed world.
While client software has not been noted, so far, for its distributed excellence - this is changing. Client softwareis strength has always been ease of use - and installation. Take these attributes, take the attractions of offering products for distributed processing oriented out from clients, and we can expect products to proliferate across a distributed middleware melting pot as diverse as:
- distributed transaction management
- multiplatform workflow
- heterogeneous database access
- asynchronous application execution
- multifaceted object request brokers
- multiple parallel communication modes
- mobility
- combinations of two or more of the above.
As Paul Hessinger points out (page 4) the Internet is just one working proof, albeit limited, that distributed heterogeneous systems using multiply sourced software can work together. While the Internet is relatively simplistic by comparison to conventional transaction processing and distributed transaction management, it is the mass model which indicates the way forward. It is also where concepts like I-TP (Implicit Transaction Processing - see pages 29 and 35) and Object TP (page 42) will come into their own.
Management conclusion
Middleware is a must for working distributed processing. The question is not if it will be developed, but who will develop it.
In this Report, and in future Reports, there will be analyses of the factors embodied in Figure 1. None is a complete answer. All add a part of the solution to distributed processing.
Those who think (wish may be more accurate) that the 'grand architectural solution' will become available are in for an infinite wait. In contrast, those who look to use existing client sourced (and thereafter evolved) middleware products will be the ones making progress. As Figure 2 demonstrates there is already a wealth of working software waiting to be used - but only when applied in the right places (rather than wishful ones) will successes emerge.