| 2.2 Second Generation
Re-Use Via Middleware Presuming that
re-use of legacy applications is the best technical and business strategy, conventional
wisdom has it that middleware is the short-term solution of choice, despite the burdens it
brings, because it works as soon as the interfaces can be defined. However, we consider
middleware to be a first generation solution to the problem of application integration.
Arguably, the quick start from middleware may be true in many
circumstances, but we also see that middleware perpetuates and even exacerbates the
problems of cost and inflexibility that, rightly or wrongly, are commonly associated with
many legacy applications. With regard to cost, many sites are getting sticker shock, and
looking for alternatives, which are more affordable, both for the initial license fee and
on-going annual maintenance fees.
A hidden element of cost is the added burden to maintenance
programmers. Consider how a typical mainframe program interacts with supporting tiers of
system software. An on-line CICS/DB2 application must interact with two other tiers of
software, the TP monitor and the database, but there is a single point of maintenance.
When the program is changed, it passes through the CICS and DB2 precompilers before
reaching the 3GL compiler, but this is largely transparent to the application programmer
and has little if any impact on his or her productivity. By contrast, a change to a CICS
program involved with a middleware product must also change the middleware specifications
at the same time, in concert, so that there are two points of maintenance that must be
coordinated. This increases both the time spent and the probability of a program failure,
as well as decreasing the responsiveness to a request for change. Those requesting the
change may perceive this as an increase in inflexibility.
A more significant argument against middleware involves the
fact that it is always a proprietary solution, while the advantages of the Internet and of
XML flow directly from the adoption of open, non-proprietary standards. Proprietary
solutions may offer technical advantages, particularly in the near term, but their
shortcomings over time are a major reason why the industry has been driving toward open
standards and away from proprietary standards. A proprietary XML middleware solution may
limit or complicate the extensibility that is part of the very reason we want to embrace
XML.
As we review many IT shops, we see the results of past
"quick fixes". In the 1980's, we saw the introduction of 4th generation
languages, often with concert with proprietary databases, which purported to solve the
programming problems of the day. In the early 1990's, we saw a drive to replace
centralized mainframe applications with decentralized client/server applications,
frequently using proprietary "quick fix" technologies. Now, resolving the
problems posed by this hodge-podge legacy of obsolete, dead-end technologies from past
"solutions" are among the central issues preventing those shops from readily
embracing the web.
The most significant argument, however, is that middleware is
simply unnecessary. We have one demonstration where we bring up a CICS application on a
green screen. Then, we switch to a browser and show the same presentation and the same
information, followed by the same information with the presentation in French instead of
English. Finally, we show the same information on a Palm Pilot. The same COBOL program
running under CICS produces all these outputs. However, if you look at the program, what
you will see is standard CICS logic if the input is from a character-based device, and XML
encoding/decoding logic otherwise. The presentation specification, be it the English,
French or Palm Pilot versions, is all controlled locally on the device using the
presentation specifications given in an eXtensible Stylesheet Language (XSL) stylesheet
linked to that XML document. The XML logic in the COBOL program was introduced
automatically, with only the minimal effort of defining the data tags to be used for the
local XML dialect and linking these to the program data fields from which the XML document
will be created. This is the work of a few minutes after being trained and, once done, it
need not be repeated.
This is a second-generation re-use solution. The programmer
continues to have a single point of maintenance, in a way similar to CICS and SQL
interfaces in program sources. The XML logic will provide the greatest flexibility and
robustness in the application, and the costs are much more attractive than middleware.
Finally, the application will involve open standards at all times. |
