Columns

Ron Zahavi: Keys to Enterprise Application Integration

• By Michael W. Bucken
• June 7, 2001

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 development managers?

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.