Hi Van, While keeping in mind that BPEL was designed to solve the "programming in the large" problem, there are multiple approaches to carrying "cheap" compute operations in BPEL:
1) Using XPath function extensions (Note that your functions should ideally not have any side-effects.) 2) Using an integration layer that supports in-VM code invocation Both JBI and Axis2 integration layers allow you to do this (although both require in-memory XML representation) 3) Extending the language with custom activities (e.g., BPEL4J) 4) Extending the language with custom expression language (We already support XPath 1.0/2.0 and call-outs to XSLT 1.0/2.0) So far, my experience is that using #1 and #2 is best for most environments. If you're thinking about #3 and #4, it's often worth revisiting your SOA architecture first and making sure you are correctly following the design principles (e.g., coarse-grained services, loose-coupling, etc.). The benefits of extending the language need to be judiciously weighted against the loss of portability of your processes as well as creating and sustaining a toolset that supports language extensions. regards, alex On 7/19/07, Van Caesar <[EMAIL PROTECTED]> wrote:
Here a conceptual problem about ws-bpel troubles me. In my thought, as a language, bpel is based on web service, so it can describe process with the partnerlink's operations released to web service. We all know, web service need more system resource, therefor, most time we need to use local operations which are not released to web service, such as the classes stayed in internal memory. Bpel is an advanced computer languge, what I want to know is that whether it complete some lower functions or not. Now, we want to use apathe ode to make business process come true. -- Van Caesar
