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.
About the Author
Jack Vaughan is former Editor-at-Large at Application Development Trends magazine.