I'm sorry but I disagree. Web services are all about interoperablility. And
the fact that the WSE 3.0 web service works just fine with a WSE 2.0 client
except for the builtin Require action assertion proves that it is a bug.
By the way, I did get around my problem by removing the require action
assertion and everything works fine now. However, I would like that check in
there. When I have time I might write a custom assertion that takes into
account both action elements.
> It is not a bug. WSE is a Web Service toolkit that supports a specific
> version of the WS-* stack ONLY unlike WCF, which, is a entire new
[quoted text clipped - 76 lines]
> the
> > > > > newer 08/2004 schema?
Hi,
I think you have misunderstood me. Yes, you are right in that web services
are designed with interoperability in mind. You are, however, talking about
Basic Profile compliant Web Services. If you inject the advanced WS-* goo in
there, they are still "Web Services" but you may have some difficulty
getting the different versions of the same platform to interoperate, much
less the different platforms. Basic Profiles are the specific mechanisms to
make sure the implementations DO interoperate. You will notice that some of
the newer WS-* specs are not there in the basic profiles unlike the more
matured WS-* ones such as WS-Security. Some of the WS-* specs out there to
add on top of the base stacks out there are still not ratified yet or are of
different versions (with the different toolkits) and therefore cannot
interoperate. WCF is supposed to solve that problem because of its
programming model. Microsoft's official stance from the start is that some
of the WSE versions will not interoperate with one another. See below.
If you had tried WSE1.0, you will know that it is impossible for it to get
its addressing headers to interoperate with WSE2.0+. WSE2.0 addressing
headers are not supposed to interoperate with WSE3.0 and likewise with WCF.
However, WSE3.0 addressing headers can interoperate with WCF but not with
WSE2.0. This is just the way it is designed. I have an article on how to get
specific interop scenarios b/w WSE2 and WCF here:
http://www.softwaremaker.net/blog/PublishedWCFInteroperabilityWithWSE20AndTheMig
rationIncentive.aspx
Note that, I didnt include WS-Trust or WS-SC scenarios in there. So, if you
need both the advanced security or policy specs, they will not interoperate.
The fact that you have to turn off addressing headers to get them to work
just means that wsa headers between those 2 endpoints does not interoperate.
This may work in your specific instance but if you need to put a WSE3.0 SOAP
intermediary in between (such as this newsgroup posting:
news:CEC76416-7CEC-464F-950C-A502B33EF494@microsoft.com...), this will mean
injecting wsa headers in there and this will not interoperate between WSE2.0
and WSE3.0.
Note that Microsoft states that:
WSE 3.0 and WSE 2.0
Because of changes in the underlying specifications for WS-Addressing,
WS-Trust, and WS-SecureConversation, WSE 3.0-enabled applications do not
interoperate with WSE 2.0-enabled applications. However, WSE 3.0 and WSE 2.0
client applications can run side-by-side with the .NET Framework 2.0. You
can host WSE 3.0-enabled Web services and WSE 2.0-enabled Web services on
the same computer, but they must be in separate virtual directories for
ASP.NET or separate applications for Windows Forms applications.
It is theoretically possible to develop Web services using WSE 2.0 in such a
way that they can interoperate with WSE 3.0 (and WCF) by using only a
reduced set of specifications-specifically, SOAP 1.1, WSDL 1.0, and
WS-Security 1.0. However, Microsoft does not support interoperability in
this situation. The safest way to plan for interoperability with WCF is to
upgrade the WSE 2.0 code to WSE 3.0.
Source:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/WSS
_Appx_InteropCons_WSE30.asp
I hope this clears up some confusion.

Signature
Thank you.
Regards,
William Tay
http://www.softwaremaker.net/blog
=========================================
> I'm sorry but I disagree. Web services are all about interoperablility. And
> the fact that the WSE 3.0 web service works just fine with a WSE 2.0 client
[quoted text clipped - 52 lines]
> > > > > > xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> > > > > > xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing"
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecuri
> > > > ty-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurit
> > > > y-utility-1.0.xsd">
> > > > > > <soap:Header>
> > > > > > <wsa:Action
wsu:Id="Id-8e3d449c-436a-4568-8def-07eea3196e4c">http://convergencedata.net/
> > > > CreateItems</wsa:Action>
> > > > > > <wsa:MessageID
wsu:Id="Id-c6e0068f-6cf7-4428-96fd-4475e5449f28">uuid:bddc46ec-1787-4c18-a81
> > > > 1-2593fc87ad07</wsa:MessageID>
> > > > > > <wsa:ReplyTo
> > wsu:Id="Id-1a746231-bf96-483d-88a9-45f208c8c7db">
<wsa:Address>http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous
> > > > </wsa:Address>
> > > > > > </wsa:ReplyTo>
[quoted text clipped - 10 lines]
> > the
> > > > > > newer 08/2004 schema?