Ron Zahavi: Keys to Enterprise Application Integration
Defining middleware has become an almost
impossible task. The term has evolved from describing a relatively simple piece
of database connection software to one that is used to describe a smorgasbord
of systems. Ron Zahavi, director of distributed object technology at Concept
Five Technologies Inc., stays in the middle of the middleware jungle by defining
the distributed object focus of his services firm's efforts to build and deploy
Enterprise Application Integration (EAI) systems. Zahavi discussed the evolution
of middleware and the emergence of EAI with ADT Editor Mike Bucken.
How do you define middleware?
Middleware probably started out in the earlier days more like a database middleware.
[Later on] when some of the distributed object technology came out, some people
started calling that middleware. So the question is: Which middleware are we
talking about? Middleware, in my mind, is technology, or a set of technologies,
that provides some level of abstraction for whatever it is people are trying
to abstract. That's why there are different types of middleware. Database middleware
is used to take some syntax, such as a query, translate it to the different
database products, act on that, and then take the output and potentially do
a join or something else.
The ORBs, regardless of whether it's CORBA [the OMG's Common Object Request
Broker Architecture] or DCOM or anything else, are also seen as a certain type
of middleware. We look at [ORBs] more as a technology, more of the connecting
of different systems, different operating systems and different platforms. Then
the applications can sit on top of that middleware to exchange information.
We see that as somewhat different from EAI [Enterprise Application Integration],
which gets into other requirements.
How do you categorize middleware products?
This is something we spend a lot of time on because there's a lot of confusion
out there. There are different types of products out there. There are the application
servers. There's a group that tends to be the message brokers. There are also
the ORBs/ OTMs [Object Transaction Monitors]. They all have slightly different
features and purposes even though all the vendors will tell you, 'Sure, we do
Web-to-legacy integration.' It's very confusing for the people looking at the
technologies to figure out what [Web-to-legacy integration] actually means.
I'll just try and characterize them at the highest level of differences we see.
Application servers are very good at bringing information together from different
sources, developing new logic to go with that information and presenting it
to things like the Web. But they do not necessarily do a lot of the legacy-to-legacy
integration. They're good at developing applications and services, but are they
the ultimate solution for the enterprise? Probably not, but they are a piece
of that. The same can probably be said of all the other technologies.
If we look at message brokers, we can say that they are very good at integrating
systems through other systems. They support a lot of the asynchronous capabilities;
guarantee delivery, messaging and transformation and routing of messages; and
they also guarantee the transformation of the information and formats. Neither
application servers [nor message brokers] are really standardized. There are
not a lot of standards in those areas.
So how do you get one of those systems to talk to the other?
Maybe the application servers lend themselves very well today to the Web and
to components, but the messaging brokers don't necessarily do that well. They're
concentrated more on the back-end messaging infrastructure. Again, you sort
of need both capabilities, but there's really no single product out there today
that wraps all of these enterprise application issues together.
ORBs and OTMs add standardization with CORBA. These give you object-oriented
capabilities and abstraction. So they provide some of those services. They also
give you the multilanguage, multiplatform capabilities. But again, you don't
see any such products today that can give you all the capabilities that the
application servers and the message brokers provide.
We define EAI as features that cut across all those categories. I think you
will see today that a lot of EAI vendors are trying to move from their area
of strength into more of a middle ground. You might see a message broker application
trying to add more of the Web and component and Java capabilities [of an application
server]. You might see an application server address transaction capability
and security to be more of an enterprise platform. We see EAI today as a term
applied to integration that requires multiple features. EAI is not necessarily
a middleware thing by itself, it is a way to apply those different technologies.
How are EAI products/technologies used today?
We are looking at implementing EAI using distributed object technology and
security. We look at that as being the key to doing EAI. There are other organizations
that might just look at messaging or something else. We're looking at combining
features so that you can do messaging-like things
using distributed objects, frameworks and things like connectors to legacy systems
and objects and components that are composites across those to add business
logic, which starts to require some of the application server capabilities.
That's how we're applying and using middleware and distributed objects, as well
as some of the other features in EAI.
One of the reasons consulting companies are thriving these days is that there's
a lot of confusion. It takes groups that have expertise, especially on the architecture
side, to apply these technologies. I see a lot of the problems today related
not to specific technologies, but to the fact that people are trying to apply
them to distributed systems, which are very complex. Developers building a distributed
system have to deal with a lot of different issues regardless of the technology
they are using. They all face scalability and performance issues, how to divide
logical architecture from physical architecture, which languages to support,
which versions of the OS to support, and how to prevent loops from
occurring. Deadlocks and things like that are not easy problems. These are not
skills that are easily developed.
What about security?
Because objects have very well-defined interfaces and classes, we were able
to develop the security to manage those entities and group them into domains
and policies. It is a much more sophisticated model, and we view that as critical
to being part of the enterprise. This is something that needs to scale; it also
needs to support intranets and extranets. They all require potentially different
policies. From our perspective, that is how we see the core of EAI. We see the
ORB having to work with the application servers. In reverse, many of the application
servers make use of the ORB. We also believe -- and this was one very important
piece that was missing -- EAI systems must be able to support messaging.
How important is the OMG's joining of
CORBA and Enterprise JavaBeans? [See "Sun, OMG building EJB-CORBA platform
for app servers," p. 56, ADT, May 1999.]
The last thing we see -- and what we like about CORBA and what's happening
with the distributed objects in general -- is the component specification that's
coming out. The specification maps things like EJB to CORBA components. There's
a lot of dedication to be able to write gateways and bridges between the technologies;
working with just one of the other certain types of application server, or just
with EJB or just with messaging, potentially ties you to a vendor or language
for the enterprise. What we see is that everybody usually has one of everything
-- different languages, legacy systems and platforms. We see that the distributed
objects standard space solution is one of the only solutions today that can
cut across all of those [lines]. That is a strong case for infrastructure.
How far along is the promise of EAI?
What we have seen is a great demand in the marketplace for enterprise application
integration. You don't have to go far to find large companies that have different
internal departments that all somehow relate to the customer. Then you realize
that you can never get all of those internal departments to agree on what that
[relationship] means, and how to develop software that cuts across lines. In
reality, when you get into the enterprise, the model where you look at integration
across loosely coupled applications is going to work and scale very well.
What we saw in recent years is that messaging software showed up at the proper
place in the market, and everyone latched on to a solution that does that very
effectively. You take information and you ship it around, and that works very
well between these loosely coupled applications. Messaging software by itself
does most of the messaging and infrastructure. On top of that we see some vendors
adding capabilities to do filtering, transformations and value-added things.
The problem we see as we look at key issues like security, is that you don't
have a very high level of abstraction.
We believe that messaging provides two different things. One is to underlie
things like CORBA messaging, which gives the ability to do asynchronous communication
using an ORB. Another is to develop some frameworks or higher level interfaces
that are in the distributed object space but which give similar capabilities
and messaging benefits.
We see a need for each; by themselves, each has a lot of positives but cannot
do what is needed by EAI. So we look at those things working together.
Can anybody bring it together in a single product? Do you think it is possible?
Everybody is working on these capabilities.We see some companies working on
a Java-only solution that does both. But we obviously think that it needs language
support of other things. So there are going to be various products that are
trying to put it together. I think we're going to see this developing over the
next 18 months.
Interestingly, the success of [IBM's] MQSeries has spawned other kinds of messaging
products that do very similar things. One of the effects has been that the competing
products and MQSeries are not standardized. Success means that there is a lot
of competition and choice, but it also means that you have to potentially tie
into a specific one.
We also saw a change in the market from doing a lot of rewriting of code in
the 1980s -- a process that is very costly -- toward integrating existing applications
and making them work together.
Does the entry of Microsoft and Microsoft Transaction Server [MTS] and MSMQ
MOM middleware advance EAI at all? Should the Microsoft products matter to IT
I prepared a presentation for a conference on DCOM vs. CORBA. It goes through
some of the pluses and minuses of both and then I sort of threw in a surprise
slide saying 'They're part of the enterprise.' It's not an either/or [issue];
you're going to need both. The fact is that Microsoft is there, and we're seeing
a growing number of organizations using NT. We're also seeing a greater number
of organizations using Linux. The issue is that they're going to be there; they
have a solid product with MSMQ; they have a solid product with MTS. But we don't
necessarily see them as still playing a very strong position in the back end
and in the enterprise. They are a key part of it, but the scalability and the
robustness that organizations demand is still not there.
The other issue that we see today is how they play with Java. They were moving
toward that, and now they are potentially moving away from that once again.
I think there's some big questions as to how that's going to play out.
I guess the way to characterize the Microsoft strategy, or anyone's strategy,
is that to work in the enterprise the software cannot be based on 'I can add
all the features so I do everything' and that's your replacement. It has to
be coming more from the direction of 'Can fit and I can interoperate,' and that's
not something that I think -- looking at Java -- they're technically or politically
able to execute on. They are part of the enterprise, and I think that people
will still have to work with Microsoft. But their strategy of 'We can replace
all the Unix, and all the Linux; we can do messaging and transactions and you
don't need anything else other than our platforms,' is just not going to work
with most organizations.