A requirements story
The case of a large bank provides a good example of how middleware emerged as a business requirement:
The bank had stored all its customer details on its large mainframe since the 1960s. This mainframe remained in heavy use and underwent several upgrades.
Although ground-breaking in its day, the mainframe's usefulness to the bank’s staff diminished as the bank introduced new, separate applications based on personal computers (PCs), allowing the bank’s staff to offer customers new services that the mainframe could not support.
One of the early stages, a member of the WebSphere family from IBM, WebSphere MQ (formerly MQSeries) is the most popular system for messaging across multiple platforms, including Windows, Linux, IBM mainframe and midrange, and Unix. WebSphere MQ is often referred to as "MQ" or "MQSeries"
The above paragraph seems to have inserted a inapplicable sentence on IBM MQ Series in the middle. It should be re-structuredItalic text
An ideal situation would allow the PC-based application to link to the older mainframe application and allow the mainframe and the PCs to share each others' data. Accessing the mainframe’s data offers two advantages:
1. new front-end PC applications can replace the old user-unfriendly mainframe terminals
2. PC-based systems can use the data from the mainframe in new ways — previously impracticable due to the constraints of the mainframe’s software
Up until the late 1980s systems builders had no easy way to link these different applications together. Developers faced several challenges:
1. the developers would have to construct a separate software ‘adapter’ on both systems to translate data from source applications into a format that the destination system could understand (and vice versa).
2. the processing speed of each system would constrain the other system. For example, if the mainframe ran slowly, the PC-based application would have to wait until the mainframe caught up, thereby slowing down the PC application. Conversely, processing that had been offloaded to distributed servers for cost reasons would run slowly and the mainframe would have to wait until the server caught up.
3. communications programmers would need to install a network gateway system to form a bridge between the mainframe’s network and the PC network if the different systems used different network protocols. The gateway would translate the network packets from the source system and pass them on to the destination system using the destination system’s protocol.
Such issues made integration between applications difficult. Much of such integration also required re-engineering every time two applications on disparate platforms needed linking together, as every situation differed to some extent. By devoting effort to linking together applications on different systems, IT departments started to spend nine or ten times the amount spent on original development per sub-system.
Developers apparently needed a separate piece of software that would literally sit in the middle of two or more applications and would handle all the ‘plumbing’ between the two systems. Such software needed the intelligence to handle different platforms, different programming languages, various network protocols and diverse hardware. Developers allegedly wanted to remove themselves from the complexities of the underlying computing infrastructure so that they could focus on functionality within actual applications.
Towards the end of the 1980s middleware began to emerge that attempted to address these issues. Initial middleware offerings addressed specific handfuls of platforms or languages and thus had limited usefulness. Over time, however, middleware products have become more and more advanced, supporting multiple platforms, languages and protocols.
The ability of middleware t
Answered by
ani
at
8:11 PM on December 17, 2008
