Recalling the discussion in Native Java Code (POJO) Invocation incorporating WSIF is technically possible but has not been done so far. Apart from other priorities such as covering the BPEL specification and integrating with the designer, WSIF is a Java framework, intended to deal with Java objects, not XML info items.
It is not clear to me what requirements WSIF would address. These days, with EJB3 and JSR-181/JAX-WS, it is trivial to turn a session bean or a plain object into a web service. Performance is another word that is mentioned. However, as explained in the topic referenced in the previous paragraph, the real performance hit comes from XML binding.
From the perspective of a (standard) BPEL process having XML-typed variables, the best performing invocations occur with partners able to process XML directly or with minimal transformations, compared to partners that require complex binding to an object graph.
Local vs. remote invocations are a separate issue outside the scope of the BPEL engine. It depends on the underlying web service implementation and network stack.
If you could shred some light on what your requirements are for WSIF, it'd be great.
We do not have particular requirements to WSIF , but we are looking for "some way" to improve BPEngine-WS interop in light our performance and transaction requirements.
As I understood so far WSIF (to be handled by Jbpm-Bpel) requires additional DOM-Java provider-serializer-bridge , that will not improve performance.
So WSIF actually only turns things worse.
We can't wait for http://jira.jboss.com/jira/browse/BPEL-135 to be implemented, so we will meanwhile research other opportunities.
I 'm not adherent of this Bpel-plain java coexistence and I'll be happy to encourage my managers to probe other opportunities, but main problem is lack of other BP management "de-facto" standard....
anyway, thanks for your answer.