OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [wsbpel] Issue - 87 - Optional SOAP Headers

Hi Yaron,
Thank you for creating a new issue separated from 77. I think it will simplify our discussions. Intermediaries have always been a favorite subject of mine, so I'll give you my feedback on this one ;-).
I can understand this issue in two different ways:
1. The issue is not limited to SOAP headers and to the presence of SOAP intermediaries.
This is just the way WSDL 1.1 is defined. Any part of an abstract interface is optional when it comes to binding (and limiting the definition of abstract interface to the portType, by the way, does not change this fact a single bit).
I am not sure we need to do anything here. BP 1.0, sec. 5.3.3, gives a specific recommendation in the case of portType parts (but, as I mentioned in the past, it is just a SHOULD, so even BP 1.0 compliant deployments can have this problem). So we could say that if a WSDL/BPEL designer follows BP 1.0, then the problem would not appear with parts from the portType. Otherwise, the developer must be prepared to have undefined/unused parts at runtime.
2. The issue should be understood only in the specific context of SOAP intermediaries.
In other words, because of the existence of intermediaries along the SOAP path, some headers are not intended for a particular end point (either a service port or a service client) and are never going to appear at that end point (they are only used in other segments of the path which do not touch that end point).
This is a manifestation of a much serious problem with WSDL 1.1: it simply cannot handle SOAP intermediaries in the general case. Whenever intermediaries are present, there is simply no way to specify in WSDL to which segment of the overall SOAP path a binding refers to. This issue applies to intermediaries as they are described by the binding, but it also applies to the protocol chosen by the binding and to the address associated with the port. (The protocol and address problems, of course, do not appear at the BPEL language level, but they are part of the same basic problem WSDL 1.1 has when dealing with intermediaries).

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]