> * If what we mean by "client API" is a method of invoking (that is > delivering messages to) BPEL services from /diverse/ client applications > (something an web-app developer might write) then we want to stick to > existing technologies (such as AXIS). I see little point to providing > yet another method for such clients to invoke a BPEL service.
I'm on the same page with this -- it makes sense to keep the engine as small as possible and use existing packages to layer on orthogonal functionality (like SOAP handling), but I'd also like to be sure that we maintain a reasonable level of purity and isolation -- using AXIS as the default SOAP protocol stack shouldn't preclude the clear integration of something like XFire or an application server's JAX-WS stack by another user. Just the same, the core engine should be have the absolute minimum number of library dependencies to maximize the possibilities for integrating it into other runtimes. -- Paul
