MQ and the management aftermath
- By Elizabeth U. Harding
IBM more than any other company -- can benefit from successfully
connecting the diverse application platforms that have emerged over time. In recent years, IBM met the challenge
to connect multiple platforms as it redefined messaging middleware with its MQSeries software program. While much
attention has centered on the advantages that asynchronous, message-oriented MQSeries middleware brings to transactional
systems, IBM's first goal was more simple -- to provide a way of connecting legacy systems in heterogeneous environments.
Today, that is how many application development managers use MQ. In operations, managing this advanced technology
can be a challenge, and an assortment of familiar and new management software vendors are ready to meet this growing
After the pioneers
Messaging technology has been around for at least a decade. Among the vendors that pioneered messaging technology
are many that remained small, got bought or went out of business. "Pioneering vendors had good technology,
but they tried to appeal as technology," said Ed Acly, director of middleware research, International Data
Corp. (IDC), Framingham, Mass. "But the way you sell middleware is to sell solutions, [you need] medicine
for business problems, not elegant technology."
Application integration has been an issue since the dawn of computing, and IBM's MQSeries message-queuing engine
is aimed squarely at solving this problem. Industry watchers estimate that application integration costs can be
nine to 10 times as much as the original purchase cost of software. Often for corporate development managers, it
is a case that their company just acquired another company and they now have
to integrate one information systems (I/S) system into another and another. That's a huge cost. Or, they have
to integrate a system like SAP, Baan or PeopleSoft with hundreds of applications already around the company. Another
huge cost. Companies have often dealt with integration themselves rather than looking to a middleware product to
solve the problem for them.
"Developing a home-grown system is very complex, and you'll be spending a great deal of effort on developing
infrastructure glue," said Colin Osborne, IBM worldwide business unit manager for MQSeries stationed at the
IBM U.K. Hursley Lab. "That requires a very high degree of accuracy, and essentially, you'll be using your
application developers to write infrastructure rather than business code." A favorable alternative, from Osborne's
point of view, is to let IBM help via MQ.
The drive up into enterprise application integration will be a major push of computing over the next few years.
"With every company you talk to on the business level, the key issue they are struggling with is integrating
these functions to get greater efficiency," said Osborne. "And once you start talking about cross-enterprise
multiapplication integration, you're talking about the most complex computing environment known to mankind."
That said, the middleware market today is relatively small. IDC projects this market in 1997 to be around $289
million, but Acly said he wouldn't be surprised to see "a rapid growth in 1998 as people figure out how to
develop and deploy message-queuing technology." Although IBM began commercializing its product several years
ago, MQSeries is still relatively little known within much of the development community. MQSeries is currently
installed in about 4000 customer sites worldwide, according to Osborne.
One of the major strengths of MQSeries is that it runs on most major platforms and network protocols. MQSeries
will take you from Sun to Tandem, from DEC to NCR or from any one of these to IBM. It runs on 25 platforms and
supports most of the key network protocols. "In the new world of the Internet, companies face a challenge
-- they understand TCP/IP, but they don't know how to get from the TCP/IP world to the back office SNA world where
most of their corporate data is stored. MQSeries does that," Osborne said.
When IBM began to conceive MQ -- at the request of customers -- it decided -- again, at the behest of customers
-- to connect MQ to non-IBM platforms. According to Rob Levy, CEO of MQTech, a small consulting firm based in Glendale,
Calif., MQ has a major advantage by covering so many platforms. "A great number of MQSeries licensees do not
have IBM equipment," said Levy. "This is the first time that IBM has been able to successfully sell IBM
products to non-IBM sites."
IBM did not develop MQSeries from scratch. SSI (Systems Strategies International, a company that at one point
became part of Baby Bell Nynex) originally built a messaging engine called ezBridge in the late 1980s. SSI was
acquired in 1993 by Apertus. Building upon the ezBridge engine, IBM developed MQSeries Version.
Today's use of message-queuing technology falls in the following three areas according to Roy Schulte, vice
president of Research Advisory Services for Stamford, Conn.-based Gartner Group: one, for plain distributed application
support; two, for asynchronous applications that use a store and forward mechanism like E-mail; and three, for
connecting dissimilar applications.
Synchronous versus asynchronous
Figuring out how to develop and deploy MQSeries is not easy. In fact, messaging technology may impact the way
applications are being built. "Application developers should really be thinking of building applications in
an asynchronous way from design on up," said Osborne. Continuous synchronous links do not scale. "You
need to go asynchronous in terms of pure performance." Moreover, Osborne said that a synchronous link cannot
As companies go across their organizations to other organizations, they are less able to guarantee availability
of physical devices. MQSeries is guaranteed to deliver even when there is an interruption in the network.
"Database connectivity works extremely well in high-volume, locally assembled systems running on the same
CPU or cluster," said Osborne. "Once you move beyond that to a company in the Far East, for example,
you can't manage it because you may not know what system they are running, when they are up and when they are working."
I/S cannot manage this type of business situation with a continuous connection as in a synchronous link, said Osborne.
"You need a disconnected connection which is independent of the applications or the systems being available.
When you used messaging in the old days, you had one operating system and database synchronization was all straightforward.
The system took care of it. In the distributed world, if you try to do a database update in realtime synchronously,
you can run into serious problems."
"Asynchronous message queuing is the only way that guarantees that, at the end of a transaction, all the
databases will be synchronized," said Les Yeamans, president, NASG, a consulting firm headquartered in Scarsdale,
N.Y. "The database companies tried to make us believe that we needed client/server, and that all the applications
had to be synchronous. Ninety-eight percent of applications could be handled more practically by using asynchronous
message queuing." NASG provides information on this technology, and lets people know what users are doing
and what problems they are encountering at the Web site: http://www.messageQ.com
MQSeries can be pervasive, but it can become a management headache. "MQSeries is truly peer-to-peer,"
said Yeamans. "It's almost like a headless monster. There's no one place where you can get it all. That's
why third-party management products are so important."
To meet the need to manage, according to Osborne, IBM has currently struck partnerships with 85 vendors whose
products add value to MQSeries. "Because our customer sites are so different and many already have a systems
management tool in-house, we won't build [into MQSeries] a one-size, one-does-it-all systems management system,"
said Osborne. "There is no one system that can do it all. [The solution] may be too big for some, too small
Still, IBM has moved toward supplying at least one bundled management option. Addressing manageability needs
of MQSeries in the field, IBM and Candle Corp., Santa Monica, Calif., have announced the bundling of Candle's tools
with every shipment of MQSeries. (In 1997, Candle acquired the MQView product line from Apertus Technologies Inc.)
Available in Q3/'98, the Candle Command Center Admin Pac for MQSeries is a limited-version tool suite for message
development, configuration and availability management. Joining Candle among the ranks of large vendors offering
enterprisewide systems management for the MQSeries environment are IBM's Tivoli subsidiary, Boole & Babbage,
Computer Associates, BMC, Landmark and others.
Boole & Babbage, San Jose, Calif. launched its Command MQ product suite for monitoring the whole MQSeries
topology in the latter half of 1996. "We manage MQSeries and also the entire enterprise," said Mike Bunyard,
B&B senior director of product management. "If a management product focuses only on MQSeries and not on
the hardware and network devices, MQSeries often becomes a victim of a surrounding infrastructure problem."
According to Bunyard, customers want to manage the middleware piece just as they manage their transaction servers.
Companies with a mainframe-centric view (who use MQSeries to take information from the mainframe and put it out
into other environments) typically want to use 3270 terminals or PCs emulating a 3270 terminal whereas people responsible
for managing MQSeries in a more distributed environment want the ability to manage from a graphical user interface
(GUI). Bunyard said that Command MQ supports both 3270 terminal and GUI interfaces.
MQ on track
When Burlington Northern Inc. and Santa Fe Pacific Corp. merged their rail lines, they brought in MQSeries to
get their separate MVS mainframe systems to communicate and chose Command MQ to manage their systems.
"When we first implemented MQSeries about three years ago, we had to write our own tools, our own utilities,"
said Terry Meyer, senior systems engineer, Burlington Northern Santa Fe Railroad, Fort Worth, Texas. "With
Command MQ, Boole is providing the tools, and they also provide scripts for monitoring. We don't have to maintain
our own tools anymore."
Landmark Systems Corp., Vienna, Va., is offering tools focused on performance management not only from a production
but also from a life-cycle point of view. "Customers tell us that they don't want to deal with performance
during production," said Mark Knecht, Landmark vice president of marketing and business development. "They
want to plan for it during the development time frame. The Monitor is not a smokestack solution. It addresses performance
management from a life-cycle perspective." Landmark began shipping its PerformanceWorks' Monitor (TMON) for
MQ Series last December.
ABM/AMRO, a financial services company based in Chicago, needed a tool to be able "to get further under
the covers of MQSeries and see what's happening," said Gregory Korbecki, ABM/AMRO systems officer. Since ABM/AMRO
has been using Landmark products on the mainframe for MVS, CICS and VSE, Korbecki said the Monitor's look and feel
is comfortable and similar to Landmark's other products. According to Korbecki, ABM/AMRO is using MQSeries for
some smaller financial transfer applications and is in the process of developing a large call-center application
that will run on MQSeries.
Small is beautiful
The message management market is not only made up of large systems management vendors. Small startups like NasTel
Technologies Inc., Level 8 and others are ready to try their fortune as well. Among these startups are developers
that had an early hand in the formation of message queuing middleware. Some, such as NasTel, suggest that full-fledged
MQSeries implementations can be overkill in some cases, and that too many overly encompassing approaches to MQ
will cause "analysis paralysis" in I/S and slow the market.
NasTel, based in New York City, has become one of IBM's premier certified MQSeries service providers. "In
order to manage MQSeries, you need a certain amount of expertise of its internals," said Krish Shetty, NasTel
president. "Our people came from SSI and have a strong knowledge of MQSeries and middleware in general. Companies
generally underestimate the amount of expertise and time needed to take full advantage of MQSeries. There's quite
a bit of work to be done after you get MQSeries in house."
NasTel's product MQControl is a point solution compatible with other network management frameworks but does
not require an existing product set to operate. As such, MQControl can hook into any SNMP-based management platform,
such as HP OpenView, NetView, Tivoli or CA's Unicenter or work as a standalone non-SNMP tool. MQControl is said
to work well with other performance and systems management products. NasTel has relationships with vendors, such
as Boole & Babbage, which has licensed NasTel technology, and Landmark, which resells MQControl as a complementary
solution to TMON MQ product. "There's no question that MQSeries is the right solution for connecting various
systems and applications in today's distributed environment," said Shetty. "The challenge is starting
out with a system that does not cause future problems. If you want a support tool while developing which can grow
into a systems management tool, our tool is very effective."