"Ugo Corda" <> writes:
>
> Fine, so the WSIF client would not be able to manipulate the "Header"
> abstract message in my example (in other words, WSIF behaves the same
> way BPEL does).
>
> As I pointed out before, other WS frameworks do not behave that way,
> and they allow users to directly manipulate the "Header" abstract
> message in my example (I know for sure because a customer of ours
> brought us that type of example asking us to support it in BPEL).
You're right that this has nothing to do with WSIF.
> You might say that using WSDL 1.1 that way is a bad idea. I am not
> arguing with that. All I am saying is that it is perfectly legitimate
> to use it that way according to WSDL 1.1 (the spec actually explicitly
> calls out that case in sec. 3.7, when it says "The referenced message
> need not be the same as the message that defines the SOAP body").
I'd be the last person to say don't use WSDL .. :-). However, WSDL
suggest a certain separation of abstract behavior from binding-dependent
behavior. The point I'm making is that BPEL must *only* depend on
the abstract behavior of a Web service as defined by its portType and
not on anything else referred to in the bindings. That's the only
way to really enable the multiprotocol abstractions enabled by WSDL -
otherwise BPEL (or whoever is using WSDL) is intrinsically tied to
one binding ..
I don't think there's a way around this- BPEL can either adhere
to the principles of WSDL or not. I would obviously recommend that
it absolutely adhere to them. If its going to, there's no way to
allow a BPEL process to access/manipulate any binding-dependent
information as such information is simply not available until
much later in the lifecycle of process authoring/deployment/execution.
Sanjiva.
