Columns

Max Dolgicer: Maneuvering in the middleware milieu

• By Jack Vaughan
• June 5, 2001

At the recent Component Development ’99 Conference in New York City, we
got up-to-date with the maven of all middleware mavens — Max Dolgicer,
director at consulting firm International Systems Group Inc. Managing Editor Jack Vaughan talked with Dolgicer.

Q. Max, you’re on the front lines of middleware. What are the obstacles
to implementation success today? Let’s start with CORBA.
A. I think one of the important issues is that people need to appreciate where CORBA products go and where they stop. You need to know what CORBA products don’t do for you — what you need to develop yourself. You see, CORBA really is sort of a plumbing. And you could have the best implementation of the plumbing and get disappointing results. Nothing replaces a good design.

Q. People sometimes talk about ‘wrappering’ as if it were an easy task.
A. Right! Wrappering is just a fancy word. You need to know how to do it. You can’t just draw a black box and call that legacy. You need to spell out in detail what the functionality is — what "the wrapper" needs to do; which technologies need to be used; what things need to be designed in-house.

Q. What architectural mistakes do people make?
A. People need to realize the capabilities of some of the CORBA products. An architect can’t work in a vacuum. The architect of the
system must be somebody who is close to the technology and has very clear deliverables. One of the things we feel is that people sometimes define an architecture that cannot be built using CORBA products or EJB
[Enterprise JavaBeans] products or both.

CORBA or EJB are not panaceas to all evils. They are middleware technologies that help you to do some things that you would otherwise have to do yourself.

One architectural issue is that you need to very specifically decide how you are going to deal with legacy systems. They come in different flavors and colors. They represent different approaches to building a system.

Q. Is it that the objects are too big or that there are too many calls in the implementation?
A. Sometimes, yes. Sometimes, it’s that and more. The question is what you use and for what. If you use CORBA for wrappering, you have to figure out what communication mechanism you are going to use to go, for
example, to the mainframe.

Because in most cases you won’t have CORBA on the mainframe, you will have it only on the application server tier.

Q. You’ve said that CORBA doesn’t scale well. I would hope at this point in ORB history that is no longer the case.
A. I believe that is still the case. Not too many very large-scale CORBA applications are in deployment today. It’s actually surprising how few of those examples vendors can actually give.

It leads me to believe it’s just not there yet from a scalability perspective. I don’t want to equate all products. Clearly, some ORBs scale better, some not as well.

Q. There are a lot of angles to load balancing. Is it too early to say
people have a handle on load balancing objects?
A. People don’t have much experience with object-level load balancing. Some products provide the infrastructure that helps you build it yourself, and some products do it. In my opinion, business application developers should not even know that load balancing exists. Middleware products should do it for them.

Q. How does a manager sort out the varied middleware application
servers?
A. Look at ones that provide quality services. Which are the ones that are the best at load balancing, fault tolerance, failover? It may not be important to you what development tools are built into the application server.

You may decide to use JBuilder or Visual Café or whatever.

That is very different from people that say 'We’re looking for the application
server with the best built-in development facilities.'

The second separation of application servers is clearly based on language focus and the infrastructure focus.


Q. Most of the servers seem to be in Java.
A. Some of them allow you to build business code in Java and C++; some of them, just in Java. That is an important issue because, in my opinion, everyone will not want to start writing in Java tomorrow.

We’re rushing far to quickly in dismissing C++.

Q. It seems like there were app servers, then Java app servers and now
EJB servers.
A. It’s just a reincarnation. All of the application servers were proprietary by nature —  most of them still are. Some are starting to implement EJB specifications. But they are different in their EJB implementations because some of the EJB specifications don’t say anything. Some servers are more proprietary, some are less proprietary. The major benefit of EJB today is that it brings you the runtime services and deployment services — it provides threading models and a lot of plumbing that you would otherwise have to code to. Someone might ask "Has anybody created anything better than CICS?" The answer is "We’re trying very hard." If you look at the EJB spec, it provides a container.

If you look at the CICS spec from 30 years ago, it’s sort of a container that takes care of some of the same things. EJB provides a component model that has a clear separation between roles — between who is doing component and application assembly vs. application developer vs. somebody who actually deploys the application.

Q. I know you’ve said there is no free lunch when it comes to details,
EJB still requires coding.
A. Some people feel that with CORBA you have to do a huge amount of
programming to get the system in production and with EJB you don’t. That’s a misconception. The EJB server takes care of things like threading and the life cycle of an object, while in CORBA you have to
build it or get it as part of a framework. But there are still a lot of details that have to be worked out. A business logic developer cannot just focus on business logic and have no other things to do.

Q. Just when we might be getting use to EJB, along comes XML.
How do you see XML in middleware, messaging or other areas?
A. To me, when it comes to messaging technology, XML is a well-defined
solution to a very well-defined problem. It’s a very complementary technology to products like MQSeries, particularly when it comes to
providing self-describing messaging capabilities. That clearly is a go, although there are some performance issues to be worked out. When XML goes on the wire, you obviously have much more payload. But overall, it is clearly complementary.

On the front end, as an add-on to an application/Web server, XML allows
you — without extra programming — to display different information. But
it is not yet clear to me where XML complements CORBA or COM in a very
clear and concise way. Meanwhile, there are a whole slew of products emerging, such as Excelon from Object Design Inc., that are sort of XML data servers. They have tremendous market potential. We do see them conceptually working in conjunction with application servers. Their claim to fame is to parse, maintain and persist XML structures very quickly, which obviously can get very complex.