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...