The vendors strike back against Burton:
<<Bill Roth, vice president for the BEA Workshop Unit, summarizes the
position of the major vendors supporting the Java Enterprise Edition,
with a witty rebuttal of the Burton Group's report that the platform
is dying of complexity and is ill-suited for SOA.
"J2EE is like the Mark Twain of enterprise software," he said,
"reports of its death have been greatly exaggerated."
Roth, along with spokespersons for IBM, Oracle Corp., Sun Microsystems
Inc. and JBoss, now a division of Red Hat Inc., do not all dispute
Burton senior analyst Richard Monson-Haefel's argument against the
complexity of the platform, but none of them agree with him that Java
EE's case is terminal.
"Yes, there are problems with complexity, but it doesn't mean that
platform is dead," said Jim Knudson, IBM Java EE architect.
While he agrees that the Java EE platform is complex, he says some of
the complexity came about as the result of customer requests and to
that extent customers are getting what they want. He said IBM
customers contemplating SOA implementations are planning to build them
on Java EE 5.
"Customers we've talked to are anxiously looking forward to the
delivery of 5," the IBM architect said.
Ram Venkataraman, director of product management for JBoss, seconds
the contention that the Java EE platform necessarily has complexity
built into it because it is designed to handle everything from simple
Ajax-style Web applications making calls to relational databases to
financial services applications handling high-volume transactions.
However, he does agree that the programming model in J2EE was overly
complex, but he disputes the Burton contention that instead of
simplifying it, Java EE 5 makes it worse.
"JBoss as a member of the JCP (the Java Community Process responsible
for the platform's specification) took a close look at what the open
source community had done with Hibernate and POJO-based programming
and really brought that concept into the Java EE programming model,"
Venkataraman said. "Without sacrificing any of the enterprise-grade
characteristics of the J2EE platform, Java EE 5 tremendously reduced
the barrier to the development of enterprise applications, all the way
from the simple to the most complex applications."
Karen Padir, vice president for Enterprise Java platform at Sun,
asserts that two issues are getting mixed up in the debate over Java
EE 5. In her opinion, the acknowledged complexity of the platform is
confused with the programming model, which she also argues has been
made easier in the latest release.
"The platform is certainly complex," said Padir. "It's a specification
for application servers. And yes, application servers are very
complex." Thus she said that complexity exists primarily for
developers working on application servers, but developers of
applications do not necessarily have to deal with that complexity
because they can use only the tools required to get their job done.
"Developers can ignore what they don't need," she said.
Mike Lehmann, director of product management for Oracle Application
Server, agrees that there is confusion between application development
and the platform it is running on. "Building SOA on Java EE is
completely different from building it with Java EE," he said.
While Java EE may be a complex platform, he said, developers have
other language choices such as PHP and Perl, for developing SOA
applications that will run on the platform.
"Complexity creates a business opportunity to make things easier,"
says BEA's Roth. So BEA and other vendors are focused on offering
tools that bridge the gap between the complexity of Java EE and the
developers need for simple ways to build the applications that run on it.
Opening the Java EE world to language other than Java is the key to
its survival, according to Michael Cote, a Red Monk analyst, who isn't
ready to sign the platform's death certificate quite yet.
"Sure, if Java EE were frozen as it is now and never changed, it'd
become obsolete," he said. In his view it then might be replaced by
simpler and lighter-weight platforms, such as Ruby on Rails, once
those alternative platforms evolve more of the functionality required
for enterprise development. "However, if Java EE continues its goal of
simplifying and adds in support for more languages than just Java --
such as JavaScript, PHP, Ruby, Python, and/or Perl -- it can keep its
position as platform for developing enterprise applications and
services.">>
You can read this at:
<http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1201062,00.html?track=NL-110&ad=558338&asrc=EM_NNL_367703>
Gervas
--- In [email protected], "Gervas
Douglas" <[EMAIL PROTECTED]> wrote:
>
> Here is further comment from Joe McKendrick on this:
>
> <<A couple of thoughts here: Yes, CORBA is super-complicated, but
> there are still a lot of fully functioning CORBA implementations out
> there in the enterprise world. And, agreed that Java EE can also get
> pretty complicated, but implementations sit at the core of many newer
> implementations from large commercial vendors such as IBM and BEA,
> as well as open source platforms such as Apache and JBoss.
>
> Java EE is not for the faint-hearted, and not even for power end-users
> seeking to rapidly deploy just-in-time applications for their
> particular business needs of the moment. The framework is intended for
> enterprise development shops, with all the high-transaction and
> high-scalability requirements that go with it. Plus, at this point,
> there is a tremendous skills base built up around Java EE. Yes, other
> simpler, more rapid application development frameworks probably will
> eventually become more popular, but Java EE isn't likely to go away
> anytime soon, and this all has the familiar ring of years of
> predictions of the mainframe's impending demise.
>
> Of course, ultimately, in the scheme of all things SOA, it really
> doesn't even matter what happens to Java EE. The beauty of SOA is that
> it does not favor one particular platform or approach it doesn't
> matter if services come out of Java EE, .NET, Ruby on Rails, CORBA, or
> even COBOL.>>
>
> You can find the article in full at:
>
> http://blogs.zdnet.com/service-oriented/?p=658&tag=nl.e027
>
> Gervas
>
> --- In [email protected], Dan Creswell
> <dan@> wrote:
> >
> > Urgh there's so many holes in this it's unreal.
> >
> > Soundbites and shock value from people that should spend some time
> > actually building systems.
> >
> > Gervas Douglas wrote:
> >
> > [snip]
> >
> >
> > > Here is an article on Java EE and SOA which is germane to the
> discussion:
> > >
> > > <<Java Platform, Enterprise Edition (Java EE) is not going to
survive
> > > as a major standard programming model in the next five years,
predicts
> > > Richard Monson-Haefel, senior analyst with the Burton Group, and SOA
> > > is part of the reason.
> > >
> > > This past week, Burton set off a bombshell with the release of a
> > > report by Monson-Haefel titled "JEE5: The Beginning of the End
of Java
> > > EE." Like one of those prehistoric animals that went extinct because
> > > it got too big to live off the available foliage, the Burton analyst
> > > said that with the release this spring of JEE5, the Java EE platform
> > > has grown too complex to be workable for enterprise developers, who
> > > are increasingly looking at alternatives such as Ruby-on-Rails.
> > >
> > > Monson-Haefel's conclusion is as stark as any death certificate:
> > > "JEE5's failure to address complexity is a harbinger of the Java EE
> > > platforms' fall from dominance in the enterprise development
platform
> > > arena. Organizations should look elsewhere when considering new
> > > enterprise development and should plan for the eventual sunset
of Java
> > > EE as an enterprise solution."
> > >
> > > The Java EE platform will go the way of other once promising
> > > standards, such as CORBA (Common Object Request Broker
Architecture),
> > > which eventually fell out of favor and usage, he said.
> > >
> > > "In five years, Java EE will be the CORBA of the 21st Century,"
> > > Monson-Haefel quipped. "People will look at it and say, 'It had its
> > > time but nobody uses it any more because it was too complicated.' "
> > >
> > > He took pains to emphasize that he is only sounding the death knell
> > > for the Java EE platform and not the Java language.
> > >
> > > "The Java programming language is not threatened here," the Burton
> > > analyst said. "I think the Java programming language is going to
> > > continue to thrive and be the mainstay for most enterprise
development
> > > for years to come."
> > >
> > > Monson-Haefel is not the lone analyst predicting the demise of the
> > > Java EE platform or in viewing SOA as part of the reason.
> > >
> > > "Java EE's days have been numbered for a while now," said Jason
> > > Bloomberg, senior analyst with ZapThink LLC, who also sees the main
> > > culprit being the increased complexity that comes with each new
> > > version. "Clearly, every time a new version comes out or module gets
> > > added, it only adds to the complexity. Eventually, it'll simply
> > > collapse under its own weight. It's not like there will be a future
> > > version of Java EE that's more lightweight than its predecessor."
> > >
> > > Complexity aside, Bloomberg, who specializes with SOA and Web
> > > services, sees the Java platform as fatally flawed when it comes to
> > > moving into the service-oriented enterprise era.
> > >
> > > "The Java EE world is fundamentally not built for SOA," the ZapThink
> > > analyst said. "Now, you can build perfectly good SOA implementations
> > > on Java and many of the SOA implementations in production today
depend
> > > on their J2EE-based runtime infrastructure. In fact, Java is many
> > > things an object-oriented programming language, a virtual machine
> > > infrastructure and the Java EE flavor of Java is specifically a
> > > framework for implementing n-tier architectures. Unfortunately, none
> > > of these facets of Java, or any other virtual machine-based,
> > > object-oriented runtime environment for that matter, are ideally
> > > suited as a platform for SOA."
> > >
> > > Object orientation (OO) as implemented in Java EE does not fit well
> > > with the service orientation that is the heart of SOA, Bloomberg
> argues.
> > >
> >
> > Have you looked at J2EE - does that look like OO - data (entity beans
> > etc) separated from business logic/code (session beans etc)?
> >
> >
> > > "From the OO perspective, a service and a service instance are the
> > > same thing," he said. "The whole notion of an object instance as an
> > > individual thing provides little value in SOA."
> > >
> >
> > Service and service instance might be the same in the architectural
> > approach defined by J2EE but that ain't OO and there's nothing in
OO to
> > say that my service definition and service instance must be the same
> > thing. I can do it that way if I want but I can do it in other ways
> and
> > still be using OO.
> >
> > > Nor is the virtual machine in Java EE the right approach for SOA,
> > > Bloomberg argues.
> > >
> > > "The goal of the virtual machine is to provide for code portability,
> > > while in SOA, interoperability is far more important," he said. "Why
> > > go through all that trouble to build portable code, when in SOA, you
> > > want to leave the code where it is? Fundamentally, the virtual
machine
> > > approach to distributed computing is through the serialization of
> > > objects leading to remote method invocation, while SOA runs on the
> > > exchange of messages between services with contracted interfaces."
> > >
> >
> >
> > Forgot about dynamic code loading etc didn't we which I can use for
> > handling versioning issues, hot deployment/upgrades and all sorts of
> > other things. Want to try it with .so native libraries for 'C'
> > applications?
> >
> > As to the virtual machine being about serialization of objects via
> > remote method invocation of course - it's not like we do any kind of
> > messaging via oh, say, JMS or JavaSpaces or JGroups etc and of
course,
> > when we do use those technologies we _always_ pass serialized objects.
> >
> > Oh and it's not like I don't upgrade machines sometimes moving
from one
> > CPU architecture to another in the process - no matter I'll just
> recompile.
> >
> > Code doesn't "move", of course it doesn't.
> >
> > Your SOA endpoint/interface might not "move" but what it's backed
up by
> > might/will. In fact I'd very much like for that to be the case so I
> can
> > maintain service whilst I separately evolve my internal systems.
> >
> > >>From Monson-Haefel's perspective, the service orientation makes the
> > > need for a unified platform such as Java EE irrelevant.
> > >
> > > "SOA certainly diminishes the importance of a common programming
> > > model," the Burton analyst said. "Because it's not what's serving up
> > > the communications that's important, it's the communications itself.
> > > It's the data you're exchanging. It's the method in which you're
> > > exchanging the data that matters, not the programming model
behind the
> > > data."
> > >
> >
> > Yay, so we'll exchange lots of data - good that'll get things done -
> > err, except I have to do something with the data.
> >
> > > Java EE's primary benefit was in providing a common programming
model,
> > > but that isn't of primary importance when developing for the SOA
> > > world, Monson-Haefel said.
> > >
> > > "SOA and Web services diminished the importance of what you have
> > > running on the backend," the Burton analyst said. "They
emphasize how
> > > you interface with each other, which is XML and HTTP for Web
services,
> > > for instance. What's running behind the scenes is really less
> important."
> > >
> >
> > What's running behind the scenes is the thing that does the work that
> > leads to some value to someone in the organization or one of your
> > customer. I think it's way more accurate to suggest that no-one
cares
> > how the data moves that's why we have middleware and everyone
wants to
> > be able to ignore that stuff and get on with implementing business
> logic.
> >
> > I'm not saying that integration isn't important as well - it is
but the
> > polarized view presented above is misleading.
> >
> > > Finally, ZapThink's Bloomberg said the Enterprise
> > > JavaBeans/Servlet/Java Server Pages framework doesn't jibe with SOA.
> > >
> > > "You'll see that Java EE focuses on providing a framework for
scalable
> > > n-tier architectures like those that large, transactional Web sites
> > > require," Bloomberg said. "However, if you were to set out to create
> > > an enterprise-class framework for SOA, you'd build something quite
> > > different. You'd build a framework centered on enabling and
> > > maintaining the services abstraction layer so critical to SOA. So,
> > > while Java EE is well-suited for running platform-dependent
services,
> > > it is not built for SOA.">>
> > >
> >
> >
> > This bit I could agree with ^^^^^^^^^^^^^^^
> >
> > Dan.
> >
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
