BPEL Process Invocation from different UI's - Best Practices

In my previous thread I've talked about different tips & tricks when working with ESB, BPEL, ODI, Flex, etc.

One of these tips was tips & tricks on invocation of BPEL Processes when using different UI approaches.

A very understable explanation given by 'Hajo Normann' about this:

It is best practice to use the default ways to invoke a BPEL process –
create a WSDL that maps to WSIF binding in a controlled environment and to a
SOAP/HTTP binding in a more B2B type of scenario. A call to the BPEL API would
be a “custom” solution that needs way more governance to communicate with fellow
developers and to maintain properly, when compared to the straightforward
standard way.

So, I suggest to use the API only if you desperately need
to optimize and found the default implementations violating your SLAs.

Let’s have a look at the technical implications:

If you run your presentation logic in the same Java VM as your BPEL process, you would use the default mechanism of invoking the process with the default WSDL. Under the hood, the middleware creates WSIF bindings that
- are extremely memory friendly, because no redundant memory is allocated (the middleware passes a reference to the Java object)
- share transactions

In this scenario I see no advantage of calling the API.

If you run your presentation logic in an other Java VM as your BPEL process in a controlled environment, you would still benefit from using the default mechanism of invoking the process with his default WSDL. Under the hood, the middleware creates WSIF bindings that

- serialize the passed Java objects and, on the BPEL side, create the BPEL DOM
implementations that make up the BPEL instance variables. This causes a performance and memory penalty you have to pay
- share transactions

I haven't seen any benchmarks regarding this or haven't received more information of the Oracle Development Team so hopefully this will start up a big discussion ;o)