On 9/7/07, Assaf Arkin <[EMAIL PROTECTED]> wrote: > Well, it is a header that's only applicable to some protocol, so it's no > longer utilizing the WSDL protocol abstraction, it fixes the abstract > message usage to the actual protocol bindings. And you need as many of > these as there are authentication protocols.
Not at all. It's perfectly acceptable for wsdl to have policy which doesn't translate easily to any particular binding. In this case, a username token does bind reasonably well to http auth, but you could certainly create a policy which just calls for a credential which is delegable, use that with the bpel, and bind it however you like. Your binding layer just has to be smart enough to do the mappings. A magical authentication context just doesn't make any sense with bpel. If I send my credentials to invoke the stereotypical dsl provisioning service, why would the service I called presume my credentials would a) be technically delegable b) have been granted my permission to delegate them or c) have any meaning with some other partner in the process at all, especially with a credential as simplistic as a username/pw? If any of those things are actually true, then they are part of the both process logic and the service interface and should be reflected in the wsdl initially. -d
