Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / Web Services / July 2006

Tip: Looking for answers? Try searching our database.

Action Missing

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Oldman - 17 Jul 2006 17:20 GMT
I have a web service secured using WSE 3.0.  I have a client trying to
communicate to the web service and they are using WSE 2.0 SP2.
We are getting the following error:

Header http://schemas.xmlsoap.org/ws/2004/08/addressing:Action for ultimate
recipient is required but not present in the message.

Here is the beginning of the web request that is produced from WSE 2.0 SP2:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
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-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-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-a811-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>

Notice the action tag is specified.  However, notice that the wsa:Address
tag contains a different URL than
http://schemas.xmlsoap.org/ws/2004/08/addressing.
This and the fact that when using a WSE 3.0 client the wse:ID attributes
aren't used are the only differences in the soap messages.

Is that URL causing the problem and if it is how do I get it to use the
newer 08/2004 schema?
Oldman - 17 Jul 2006 18:06 GMT
Let me rephrase this question just a bit.
The fact that the WSE 2.0 uses a different namepsace for the wsa elements
seems to cause this problem.  Is there a way to get the WSE 2.0 client to use
the newer namepsace?

Thanks again,

Chris

> I have a web service secured using WSE 3.0.  I have a client trying to
> communicate to the web service and they are using WSE 2.0 SP2.
[quoted text clipped - 29 lines]
> Is that URL causing the problem and if it is how do I get it to use the
> newer 08/2004 schema?
Softwaremaker - 18 Jul 2006 04:13 GMT
It is not just a namespace change. The implemented addressing specifications
are different.
Signature

Thank you.

Regards,
William Tay
http://www.softwaremaker.net/blog
=========================================

> Let me rephrase this question just a bit.
> The fact that the WSE 2.0 uses a different namepsace for the wsa elements
[quoted text clipped - 18 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 - 6 lines]
> > Is that URL causing the problem and if it is how do I get it to use the
> > newer 08/2004 schema?
Oldman - 18 Jul 2006 11:18 GMT
You are correct.  That is what I was pointing out in lamens terms.
In any case, I have posted a bug to microsoft pointing out the fact that the
require action assertion for WSE 3.0 doesn't recognize the action element
when the client is using the 03/2004 specification for addressing.

> It is not just a namespace change. The implemented addressing specifications
> are different.
[quoted text clipped - 53 lines]
> > > Is that URL causing the problem and if it is how do I get it to use the
> > > newer 08/2004 schema?
Softwaremaker - 18 Jul 2006 22:08 GMT
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
programming model. For example, WSE 2.0 is designed to work with only the
03/2004 wsa specifications. You have to look at interoperability to get them
working. Unless you turn the headers off (or get them to have a
mustUnderstand=0 or something), if you need the wsa headers and they are of
different versions, it is unlikely you can get them to interoperate.

Signature

Thank you.

Regards,
William Tay
http://www.softwaremaker.net/blog
=========================================

> You are correct.  That is what I was pointing out in lamens terms.
> In any case, I have posted a bug to microsoft pointing out the fact that the
[quoted text clipped - 28 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 - 8 lines]
> > > > Is that URL causing the problem and if it is how do I get it to use the
> > > > newer 08/2004 schema?
Oldman - 19 Jul 2006 11:48 GMT
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?
Softwaremaker - 19 Jul 2006 23:11 GMT
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?

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.