Fellow JUG
Members,
I received the premiere issue
of a new publication (Queue) from the ACM a few days ago. The
feature topic of the issue is Building Web Service. One of the feature
articles is an interview with Adam Bosworth conducted by Kirk McKusick.
Parts of the article (see Interview
Excerpts below) directly address the J2EE vs. .NET
issue. The comments should be of great interest to the Java
J2EE community. To read the complete
interview transcript, visit http://www.acmqueue.com/ and click the
Interview link.
Introductions
Adam Bosworth
(AB) was in senior manager at Microsoft in the late
90's and became one of the people most central to the effort to define an
industry XML specification. While at Microsoft, he also served as
General Manager of the company's WebData organization with responsibility
for defining Microsoft's long-term XML strategy. Now, as Chief Architect
and Senior Vice President of Advanced Development at BEA System, Bosworth is
much more involved in shaping the future of Web Services.
Kirk McKusick
(KM) managed the development and release of 4.3BSD and 4.4BSD
and is renowned for his work on virtual memory systems and fast file system
performance. In recent years he has achieved prominence as one of the
leaders of the Open Source movement.
Interview
Excerpts
[Question/Answer 14 -- This is
just for lead-in to the good stuff.]
KM How does
BPEL fit into the scheme?
AB Well, it
turns out that the advent of message-driven paradigms is driving the requirement
for workflow. BPEL basically allows you to script that workflow. And to
understand why that's important, let's look at Visual Basic for an
analogy. One of the great strengths of Visual Basic is that if gives you
something almost anyone can use -- a form designer. And something something
a programmer, or even a non-programmer can employ to indicate how an application
would work.
Likewise, to
design and control workflow, you need a visual designer that even mere mortals
can use but which also incorporates some solution that systems programmers can
use to extend these models (creating what we call "adapters"). But the question
is: What happens when messages come back to say that some additional procedural
action is required? How can mere mortals be expected to deal that that? Our
customers want an answer there because that would effectively make work flow
available to the mass market. But first we have to have a standard. And
that's very tricky because ultimately you're describing something that will
extend the whole programming model. BPEL is the result of an effort by
Microsoft, BEA and others to start solving that problem -- which is to say: how
to provide a standard model for writing workflow?
In terms of
implementing that, the plan here at BEA is to essentially use metadata to drive
the required extended programming for workflow semantics so that the programming
language for our customers will still be Java. An that's because we don't
think our customers really want a another programming language -- let alone one
described in XML grammar.
[Good stuff begins
here.]
KM How does
that compare the the .NET approach? My sense is that the .NET philosophy might
best be summarized as "any language, one platform," where as the Java approach
is more a matter of "one language, any platform."
AB Back when I worked for Microsoft, I built
complex infrastructures for customers. I was quite proud of the work
because I felt we'd secede in bringing together all the tools our customers
needed. We'd given them Visual Basic to build forms, and we'd given
them active server pages, and we'd given them XSLT to do conversions between XML
and HTML. And we'd given them C to write code, and so and so
forth.
But then I had an
opportunity to meet with a lot of customer, who explained that it's incredibly
hard to train people and -- all thing being equal -- they'd just as soon train
people in only one language. And almost without exception, they told me
that's just exactly why they found Java so appealing. They said that, in
their view, Java had finally gotten to a point where it had enough power to
satisfy the average systems programmer. And yet, it also managed to hide most of
the complexity that's historically made something like C a very tricky
language. Garbage collection, for example, is something that Java just
automatically handles for you. The same thing holds true for multiple
inheritance. So that effectively gave them one comprehensive solution, and they
just loved that.
At the same time, I don't
know many of our customers that have just one platform. So it would be
arrogant for us to say we didn't feel we needed to make out product
cross-platform. The value of cross-language, on the other hand, is much less
clear. In fact, for most of our customers, it's as much a curse as a
blessing. And that's because issues tend to arise when all your programmers are
using different languages in different ways. Now if Java were intrinsically
a hard language, or an inherently limited one, I think there would still be
a good argument for having multiple languages. But Java is intrinsically a
pretty easy language. The hard thing about learning Java isn't Java
itself. It's J2EE and all the plumbing required to build scalable
transactional applications. And frankly, we've bee investing a lot of our time
here trying to make it a lot easier.
So the .NET idea about
many languages being a good thing, I believe, is quite open to debate. Now, bear
in mind that I come from Microsoft and still have the highest respect for the
engineers who built .NET. But I've yet to hear of a customer problem that was
solved as a consequence of having multiple languages. And I've heard of
plenty of customer problems have been caused by having multiple languages. So, I
guess you'd have to consider me a bit of a skeptic.
KM Well let's say you're
right about that. But .NET does come from Microsoft, and Microsoft does exercise
a fair amount of market clout. Can't they just essentially ram .NET down
people's throats?
AB Microsoft doesn't drive
the market when it comes to enterprise computing. What they've really done is
create an alternative, which I consider healthy. It's making the J2EE people
over at Sun wake up and evolve their capabilities a lot faster. For the
customer, this is nothing but good news. In any case, what it really all
comes down to is how you handle the Web Services stack. And the truth is both
J2EE and .NET still have a room to grow on the account.
What might be more
germane to you question is that, for all the clout Microsoft wields, they're
still trying with mixed success to extend their reach into the enterprise world
from their long-established stronghold in the desktop world. J2EE, on the other
hand, is already widely used by almost every Fortune 500 company to deliver just
about every mission-critical application you can imagine. And we also know that
enterprises are using J2EE on their Unix and Linux and mainframe platforms,
because they're certainly not using .NET for that. In fact, I think you have to
wonder what will become of .NET if Linux should someday become
ubiquitous. As you suggest, history has shown that at the end of the day,
there tends to be only one winner in the software standards wars. And right now,
while BT is obviously a huge factor in the enterprise computing space, it's my
sense that Linux is growing much more rapidly. And if that continues to be
the case -- with J2EE being a natural partner to Linux -- I'd have to think that
.NET is perhaps in a world of trouble.
[Question/Answer
19]
KM But what are you going to be most
closely identified with? It's obvious to everyone that5 Microsoft promotes
.NET and Sun pushes Java. But what flag is BEA
waving?
AB We are the poster-child of
J2EE. We're the original J2EE application server and we're still by far and
away the best J2EE application server. IBM is waving the J2EE flag as well. But
what sets us apart is that we're focusing on innovations required to make a
easier. There are roughly speaking 10 million people today who write code and
probably less than a million of them are really productive in J2EE right
now. We're changing that by seeing to it that everyone who's a developer
can actually work with it.
[There is more, but that's enough for
now.]
Dennis Laws
