Sun has been trying to figure out what to do keep pace with innovation in the Java space and especially in JEE. The current proposal adds profiles, which I generally like, since it moves JEE forward in one respect: JEE services a la carte and lighter weight application server technologies. My friend Rod Johnson thinks this is a really great thing and I expect to see Spring take full advantage of this trend.
On other fronts, Peter Kriens asks why Sun isn't leveraging OSGI to its full potential. Well, depends what you really mean there: most of his examples are for app server internals, which can use OSGI regardless of how oblivious the JEE specs are to OSGI standards. But still, with the Java module system being proposed, it does look like we may be in for a dose of infrastructure bifurcation. At a minimum, I'd like to see a coherent and comprehensible strategy in this area for Java.
And I am concerned that there is not a coherent plan for SCA integration into J2EE. In fact, I think the statement on using SCA in JEE is a travesty. What does the current proposal for JEE really mean? How will JEE application expose their interrelationships with other services? And will JEE applications be able to bundle SOA components like BPEL processes used for embedded workflows?
My view is that there are still some very fundamental things to be worked out. We can -- in fact we must -- do better.
3 comments:
Well said.
For embedded workflows in Java, I think we should be looking at jPDL instead of BPEL.
BPEL is great on an ESB, but Java deserves a dedicated lightweight process language.
Tom, fair enough: embedded workflows may not have been the best example. What I have in mind is the integration of non-Java technologies that are appropriate to the SOA domain. We'll see whether a lightweight process language will emerge as a ubiquitous "standard" in the Java space or not.
Post a Comment