The design of jBPM BPEL considered the sublanguage extensibility. At the moment we only
support XPath 1.0, tough. Support for XSL transformations is on the works.
On the other hand, embedding Java in a BPEL process is far more than a technical
challenge. It is a matter of design principles. Here are some objections:
In BPEL, variables are XML fragments. Do you really want to access and manipulate
variables using Java? XPath and XSLT, despite their limitations, seem much more
appropriate
The BPEL spec does not require support for Java. Therefore, any process with embedded Java
snippets is nonportable.
Adding a new sublanguage to BPEL requires a definition of the relationship between the
sublanguage and the BPEL engine; for example, how to bind the process variables into the
snippet.
Even if most vendors supported Java, it is likely each will come up with different,
incompatible relationship definitions. A past initiative called BPELJ tried to define the
relationship in the context of BPEL 1.1. BPELJ not only allowed Java snippets but also
variables and partner links of Java types. It did not go far, tough.
Perhaps this work will rise again when WS-BPEL 2 goes final. This discussion will make a
lot more sense at that time.
A related topic, Native Java Code (POJO) Invocation discusses the problem of tighter java
integration from the perspective of java components described in WSDL.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3966592#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...