I'm not a Guru by any stretch of the imagination but here it goes...
I presume you are referring to the Burton Group Report "JEE5: The Beginning of the End of Java EE" as reported by
SearchWebServices.com and
serverside.com. This can be seen as a culmination of what has been going on on RMH's
blog. And before you despair too much also see this quote:
The Java programming language is not threatened here, I think the Java programming language is going to continue to thrive and be the mainstay for most enterprise development for years to come."
So what is threatened here is Java EE, NOT Enterprise Java.
And before we even go into that part of the discussion, I'd like to make one observation. In my opinion, if SOA is being developed to realize the vision as described in
SOA antipatterns, then it ultimately will suffer a similar fate to EJB and possibly Java EE as it ultimately collapses under the weight of its own complexity that only very few (well-financed) organizations really need. As far as web services go (IBM's) SOA represents the overly-complex extreme end of the spectrum that counterpoints the other extreme of over-simplified attempts of using web services as a means of RPC and object-remoting. The true value of web services is somewhere in the middle (with the document-oriented
exchange of data).
The success of Spring as microcontainer and Hibernate as an ORM solution over the past two years (or so) is a testament to the fact that J2EE has traditionally put "might" over "will", i.e. satisfied the needs of a minority of well-financed IT-departments at the cost of burdening the majority of its IT-departments with complexity that they individually derive no benefit from. In order to address the needs of that majority (my guess is probably about 80%) Java EE would have needed a sub-specification stripped of the overall complexity but with a functional feature set similar to the one that can be derived from a web-container/Spring/Hibernate combination (without the marketing-hooks of: "With our full-blown specification you could have xxx feature"). JDO may have been a good replacement for persistence EJB for such a sub-spec, but JDO was neglected in favor of EJB and now Hibernate has the upper hand (though the jury is still out on whether linking Hibernate's future with
JBoss will be of benefit in the long term).
As far a JAX-RPC/JAX-WS goes - so what if they are replaced by something like
XFire or something that has yet to emerge? As a web service developer
you should be primarily concerned with WSDL, XML, XML Schema,
SOAP, various WS-* spec (despite what some toolmakers may lead you to believe) - information that applies to web services on all platforms. At the same time you need to be aware of the SOAP vs REST battle. (IBM's) SOA needs SOAP and vendors "love" WSDL/SOAP for its tool-ablity - however if SOA fails to address the needs of the majority of IT-departments (like EJB apparently did), then much of SOAP's complexity has little benefit, and an approach like REST or another successor that addresses the true needs of the majority may yet prevail.
