Rationale for BPELJ?
Last week IBM and BEA announced a varient of BPEL4WS called BPELJ to add to the medley of business process/choreography/Web Service composition standards already out there.
Ostensibly, BPELJ is a 'a combination of BPEL with the Java language' to enable 'programming in the small' as opposed to BPEL4WS which allows for 'programming in the large'. My take on BPELJ from a brief reading of the specifications:
- BPELJ allows for Java code snippets to be embedded with BPEL process definations. For portability and maintainability reasons alone, IMO, this is a bad idea. I also dont see why this is required- surely the programming logic in the Java code can be encapsulated into another Web service?
- Another bad idea, for similar reasons is allowing Java variable types in addition to XML scheme types.
- What takes the cake is allowing Java interfaces to be specified as 'Java Partner Links' in addition to WSDL port types. What was the problem with wrapping the Java class as a Web service?
- The part that did seem interesting was allowing the use of transaction support in a J2EE application server from BPEL. I can see that this could be useful as a stop-gap measure in early deployments till WS-AtomicTransaction matures and gets integrated into BPEL4WS implementations
It would be interesting to know what
BPEL4WS's co-author Microsoft thinks about all this!
Posted by vivek at March 30, 2004 02:33 PM
| TrackBack