Web Services
by
Don Estes
 |
| Moving the Enterprise
Toward Web ServicesLet's start with the last question first. If there is no other
message that you take away from this article, take this one: You don't have to rewrite
your applications to get on the Web. In fact, it is neither terribly difficult nor
expensive to do so, for most enterprise platforms. You may have sound reasons for
rewriting your applications, such as the business rules embedded in the application no
longer fit the business process well. If so then go right ahead, but interfacing with the
Web is not one of them. Java may be the de facto language of Web implementations,
something Microsoft is seeking to change, but your applications do not have to be
rewritten into Java to access the Web.
If your applications are properly serving the enterprise, then some relatively
straightforward adaptations can put you where you want to be. Just in the last month,
we've reviewed two sites with Jurassic computer systems that want access to Web Services.
One is a very high transaction rate application, all COBOL, operating on a non-standard
mainframe, accessing a highly tuned network database system, and using 30-year-old
programs. Most importantly, this was a high-risk application from both a technical and a
business perspective. Undetected faults introduced into this application during a re-write
to Java could conceivably result in billion dollar losses. Incredibly, over $100 million
had already been spent attempting to re-write it into Java, and the project cancelled
after three years because it was clearly not going to succeed. We could see where it made
sense to modernize the infrastructure of the application while enabling a Web Services
interface, including introducing a relational database management system. However, we have
difficulty seeing an expense of even $4 million for the modernization effort, and half of
that would be ensuring that absolutely no faults were introduced into the system. Enabling
Web Services in the application once modernized is effectively trivial. Unnecessary
re-writes can be dangerous to your wealth.
The other system was worse. Again, a very high transaction rate environment, all
mainframe assembler programs accessing a user written database system, and executing under
an ancient operating system built for the airlines in the 1960s, not for a bank in the 21 st century. And yet, these
applications provide the bank with a unique competitive advantage, and so the challenge is
to transition them into Web Services without breaking the bank in the process. Again,
there is a way to do so, not cheaply, but cost effectively. Of the costs incurred, the
least would be the cost of Web enabling; the greatest part would be ancillary
modernizations that arguably have been postponed for far too long anyway.
If we can Web enable these enterprises without rewriting, then you can Web enable your
enterprise easier still. The irony is that in some ways it is easier to Web enable legacy
mainframe applications than "heritage" client/server applications. The secret to
doing so is loose coupling. Mainframe application architectures, with rare exceptions, are
built on a loosely coupled messaging paradigm, supported by off-line batch processes. This
is mostly because the applications were designed before microcomputers existed, or at
least before distributed application paradigms began to be used significantly. We can take
advantage of this loosely coupled application infrastructure by logically wrapping the
applications with a layer of Java, and using XML messaging as the interface between Java
and the legacy language. |
|
|
