2001 Issue of Enterprise Systems Journal | Middleware Goes
Britt and Tom Moore
expansion of middleware can help your company Web-enable its applications
for e-commerce and other Internet-related functions.
that catch-all term within the enterprise, is seeing a resurgence
as enterprises work to connect new Web-based systems with diverse
legacy back-ends. And although the need for a middleware connection
layer is widely apparent, many companies have yet to fully incorporate
middleware technology – mostly because it can be complex and expensive.
has been used within the enterprise for several years to connect
similar databases to different types of systems. Today, companies
need technologies that will Web-enable their applications to take
advantage of e-commerce and other Internet-related functionality.
That might mean integrating WAP or TCP/IP with C++, COBOL, and many
other languages and technologies.
to Forrester Research, 72 percent of big businesses realize that
successful e-commerce depends on integrating both internal and external
applications and systems. Yet, only one quarter of these businesses
have actually taken the necessary steps toward integration. The
primary reasons? Cost and complexity.
the height of the Internet economy obsession, most companies focused
on business-to-consumer interactions. "Last year, everyone was focused
on having the slickest, easiest-to-use Web sites," explains John
Sheaffer, CEO of Sysix Technologies. "Now, the focus is on business-to-business
e-commerce. Businesses buy online to save time, but they also want
to make sure that these [front-end purchasing] systems work with
their back-end systems."
middleware product can do everything. Most companies will
need to implement multiple types of middleware, each for particular
applications. "Good middleware for some users may not be good
middleware for other situations," says Dan Foody, chief technical
officer for Actional Corp. "Some [programs] have good reliability
but slow throughput, while other middleware is much faster
but less reliable."
need to remember that "middleware is just a means to an end,
not an end in itself," Foody cautions. "Just because it works
in one area of a company doesn't mean the company should use
only one [middleware technology] throughout the company. In
fact, I can't think of a single large company that is standardized
on only one middleware package."
is to select the most flexible, scalable and adaptable system.
For example, political news providers thought their systems
would need to support high volumes only until the November
4, 2000 presidential elections. But with the disputed Florida
votes, they - and their middleware - had to scale to support
as much news during the weeks after Election Day as before
B-to-C to B-to-B
dotcoms built their technology from the ground up. Integration with
other systems wasn’t a concern, because the systems – like the companies
– were brand-new. Surviving companies have refocused on traditional
business principles. They want to make sure that disparate front-
and back-end technologies work together seamlessly. They need to
extract the most efficiency from their internal systems and provide
greater economies throughout the business supply chain.
are moving middleware beyond the core of their own computing infrastructures
to encompass more aspects of the network and, in some instances,
to include suppliers, vendors, customers and others outside of the
company. "Companies are implementing e-business models across multiple
systems," says Assaf Kedem, director of product marketing for Intercomp.
"Companies need to tie everything together to operate as a whole."
major barrier to cross-company integration isn’t technology, however,
it’s people. Unless both sides perceive value in the integration,
it will be nearly impossible to implement. Adam Griessman, CEO of
Universal Data Interface Corp. (UDICo) agrees. "The hardest thing
to do is to change a customer’s behavior."
XML to the Mix
introduction of eXtensible Markup Language (XML) has helped bring
middleware technology to the Web. "A year ago, most companies were
developing their XML strategies," explains Hugh Tamassia, chief
technology officer for middleware provider ESPS. "Now, they are
starting to implement those strategies."
Java Beans and J2EE (the second version of Java Enterprise Edition)
are also being used in conjunction with XML to provide better connectivity
between disparate systems. "Prior to XML, trying to get Microsoft’s
COM applications to communicate with Java was a nightmare," Tamassia
created an XML-based middleware technology that maps non-XML information
to the XML format. Using this technology, companies can gather information
from disparate back-end systems and display it on their Web storefronts,
WAP phones or handheld devices.
need to connect mixed programs was also one of the driving forces
behind Simple Object Access Protocol (SOAP), developed by IBM to
permit better communication between various programming objects.
continues to mature, some business-to-business exchanges will
merge or fade away. For example, as companies adopt eXtensible
Markup Language (XML) and other Web-based standards, procurement
will become more automated. This will reduce the need for
companies to go through third-party exchanges.
XML is a Web-based middleware enabler, it's a relatively recent
technology that's still evolving to meet some of its promises.
The protocol is still somewhat slow, and it has yet to reach
the efficiency level that companies need in middleware.
XML drawback is that it doesn't guarantee delivery of the
communication. Expect to see further integration of XML and
Java 2 Enterprise Edition (J2EE). This would enhance the sharing
of business programming objects and better communications
between systems from different vendors.
evolves, future middleware will help companies integrate and
distribute applications with business partners. The next generation
of middleware will better support distributed corporate architectures
and offer more processing capabilities and inherent intelligence.
Companies and Systems
mergers and acquisitions also drive the need to connect disparate
systems arises not only from the acquisition of new technology but
also from company mergers and acquisitions. Corporations must either
link the technology of the pre-merger firms or rebuild everything
from the ground up, which is an expensive solution.
is this more true than in the financial services area, where the
more than 12,000 U.S. banks of just a few years ago have shrunk
to approximately 8,000 today, with further consolidation expected.
The remaining companies must merge their formerly separate hardware
and software while pushing everything online, where the most profitable
financial services arena uses its own version of XML, called XFS,
to communicate from internal banking systems to customers and employees
using browsers to access data.
use of middleware reduces the integration time of the disparate
technologies and cuts the development time of new [applications],"
explains Steven Lund, vice president of worldwide sales for Nexus
Software Inc., a software provider specializing in open retail banking
solutions. "Financial institutions are using XFS to Web-enable non-traditional
products (items other than basic checking and deposit products)
and to provide one-to-one marketing capabilities," Lund adds.
in Action: Anglo Irish Bank Corp.
Irish Bank Corp. Plc, a major European bank traded on the
London and Dublin stock exchanges, was facing a challenge
in upgrading its legacy COBOL applications. Over the years,
these applications had simply become outmoded.
written in ACUCOBOL, an outdated dialect of COBOL that few
programmers know. The data tier was based on the heritage
Indexed Sequential Access Method (ISAM) for organizing and
retrieving the bank's data. This method simply could not perform
at the required level.
and complexity of the bank's applications posed maintenance
problems for the staff, most of whom lacked the necessary
understanding and knowledge to address system overhaul initiatives.
decided to install an application based on a more common dialect
than ACUCOBOL. It would offer more functionality able to interact
with other programs and tiers and ease the software maintenance
and development burden on the staff.
also decided to transform and restructure its existing ISAM-based
data systems into a relational-type database schema. This
would increase database efficiency and performance, while
overcoming the current system's scalability limitations and
Anglo Irish Bank decided to centralize its data to enable
easier access from various sources, such as FTP and messaging.
After analyzing its options, the bank decided to work with
task was to analyze the bank's 2.5 million lines of code within
five weeks. Intercomp also had to convert the bank's business
rules from the ACUCOBOL dialect of COBOL to the MERANT Micro
Focus dialect of COBOL. Finally, Intercomp set about migrating
the existing DBS to DB2.
used Intercomp's AnalyzeIT tool to survey the legacy application
and its environment and provide a detailed analysis and documentation
of the program code. This automated process saved the bank
the time and expense of manual analysis, and it documented
the flow of data between applications. In addition, AnalyzeIT
helped the bank examine the impact of changes on its software
and assess the COBOL dialect transition initiative.
the bank used Intercomp's MineIT tool to identify and extract
the business rules that defined the bank's operations and
functions. MineIT was also able to zoom in on the business
rules of the code, which are arguably the most critical. In
the process, MineIT also facilitated the improvement of the
bank's code semantics, coherence, readability and structure,
for creating more manageable source. Finally, the bank used
MineIT to regenerate ACUCOBOL in Micro Focus COBOL.
initial project completed, Anglo Irish Bank has begun leveraging
the DB2 database for extracting and querying data, reporting
and other tasks. The bank is considering modernizing its presentation
layer for Internet/intranet deployment and may also redesign
its overall architecture to create a more distributed computing
of the middleware in use today does only part of the job, according
to Kedem. While one middleware system might take a back-end application
and map it to a graphical user interface (GUI), it may not be able
to go to the next step of recognizing multiple GUIs that share the
same context and tying them together.
example, a customer applying for insurance online may have to click
through several screens to complete all of the necessary information,
because different parts of the application come from different back-end
resources. A truly efficient middleware solution would tie together
these back-end engines and show the user a seamless GUI on the front
it would do is take the data from the legacy layer and refine the
layout structure before presenting the information to a front-end
device," Kedem explains. "Without this step, middleware is often
a bottleneck rather than a facilitator of end-to-end efficiency."
some middleware follows a "one-to-one" approach, connecting one
type of front-end to one backend. Other middleware applications
can make different front-end programs look alike to the back end,
or make various back-end software appear similar on the front end,
but, again, only on a one-to-one basis.
is still evolving to address the ever-wider range of user requirements.
"Middleware technology will have a powerful impact when it gets
fully integrated," says Collazo. "But, it’s only a tool, and like
any other tool, it has to perform within the business to give the
enterprise the edge."
Britt and Tom Moore are freelance writers for the Washington News
Bureau. They specialize in technology reporting. Reach them at email@example.com.