Tuesday, March 30, 2004


Connectivity not Functionality

Nice presentation from Jean-Jacques Dubray posted yesterday.  Lots to chew on, but for reasons of discussions we have been having around SOA recently, I particularly liked this cliche line that is likely used by every integration vendor on the planet but still rings true in this space:

"Today value is not defined as much by functionality but by connectivity"

Check it out: http://www.ebpml.org/csfsoa.ppt



comment []
1:20:10 AM    

BPELJ - One More Comment

It seems like BPELJ, IBM/BEA's submission to facilitate JSR 207 discussion has brought out a chorus of voices opining about whether it is good or bad - Paul Brown, Edwin Khodabakchian, Phil Wainewright, Howard Smith, The Register and many more ... shock, disbelief, outrage and much more.  It doesn't get much more exciting in the world of Web services.

I think the general agreement outside of IBM/BEA is that embedding Java in BPEL is generally not a "good thing" but I also think a number of folks, including myself (though I can't say I am representative of the opinions in Oracle), wish there was some variation of the "window in the glass bottomed boat" that Paul Brown calls BPELJ ... but with some more restrictive rules on its usage rather than the wholesale tight coupling provided by the BPELJ proposal.

There are clearly many BPEL friendly ways to hook Java in to BPEL ranging from simply working with Java as Web services to giving more native access through frameworks like WSIF.  Yet at the same time, having some well-defined hooks for native languages, not just Java, because of idiosyncracies in your BPM project, seems like something that vendors will naturally provide anyway. 

Avoided by thoughtful project managers - just like proprietary J2EE extensions - those same managers will be happy they are there when they need them, treating them with caution as they rightfully should.  Further, perhaps, while the analogy may be weak, just as JSP scriptlets turned into tag libraries which resulted in JSTL, usage patterns and best practices of a more constrained and thoughtful BPELJ-like feature set may in fact turn into well-considered general changes to the underlying BPEL specification over time.

Others are more dogmatic that BPELJ is an evil idea for which, analogously, we will end up paying the multi-year standards evolution price we paid to get to the reasonably usable CMP EJB 2.0 solution (with EJB 3.0 to fix it even better!) which is fair enough.  Hopefully given this is being discussed in at least two relatively open standards forums (OASIS, JCP) unlike other proprietary specifications, both sides will be accomodated.  Whether it resolves in something useful for users rather than something that vendors will use to promote proprietary implementations remains to be seen. 

For insight into the jockeying and general user opinion on this, it is worthwhile to peruse the OASIS BPEL mailing list.



comment []
12:39:31 AM