Hello. As you may have seen in this post of mine (clicking on it is optional): PostID=1022444&SiteID=1

I have not been able to write a WCF client to consume our java-based web service. And I'm wondering, is WCF replacing the WSE-approach to writing WS clients Or is WCF just another layer that is supposed to make things "easier" for developers I am able to write a client using either WSE 2.0 and 3.0. Maybe not being able to use WCF is not such a bad thing. Or is it In other words, is it a MUST that a web service is consumable by a WCF-based client Is WSE being obsoleted

Thanks in advance for your inputs.


Re: Windows Communication Foundation (Indigo) Is WSE going away?

Mark Fussell

This pull=/library/en-us/dnwse/html/newwse3.asp#newwse3_topic6 explains the relationship between WSE 3.0, WSE 2.0 and WCF.

WSE, as a product, is a precursor to WCF and although WCF should be considered as the replacement going forward, that does not excluded still using WSE. Another way to consider this it that WSE 2.0 has the same support agreement lifetime as .NET 1.1 and WSE 3.0 has same support agreement lifetime as .NET 2.0, both of which are 10 years from ship date.

Also there are organizations who have an investment in ASP.NET Web Services for which WSE provides an easy way to layer security protocols on top of.

The primary platform for Web service development on Windows is WCF, so it is important that you get WCF clients talking to your Java service. If you have achieved this with a WSE 3.0 client then it should be straightforward with a WCF client as both of these support the same standards specifications.

Thanks. Mark Fussell

Re: Windows Communication Foundation (Indigo) Is WSE going away?


Hi, Mark. Thanks a lot for your reply. I really appreciate it. The complaint that I have in the transition from WSE 2.0 to WSE 3.0, then to WCF, is that instead of making it easier and faster to implement my client, I find that it's actually harder.

For example, the java web-service that I need to talk to, while it requires the request's soap body to be signed, it itself does not sign the response. With WSE 2.0, that was very straightforward. All I had to do was uncheck the "Signed reply" (the exact wording escapes me right now) checkbox in the wizard when I created my policy.

With WSE 3.0, the pre-built bindings (or policies again, the exact term escapes me at this point) that ship with it do not support this signed-request-but-unsigned-reply scenario. So, I had to write my own policy and assertion classes for it. But I was able to do it nonetheless.

And now, with WCF, obviously, I have not found a way to make it work. Add to that the requirements that the web service be accessed via https and that the request be using SOAP 1.1. I just could not find the right mix of knobs to satisfy ALL those requirements.

I am really hoping you or someone would look at my other post: PostID=1022444&SiteID=1

and tell me how to implement my client (even in general terms), given the 4 requirements that I listed there. I trust that someone who knows WCF inside out would know right away how to approach it. Otherwise, that's not a good sign. My current honest assessment of WCF is that although, in writing, it is flexible enough to cover all sorts of scenarios, it's hard to know what to tweak when you've got an "uncommon" scenario.

Thanks again, Mark. I look forward to hearing from you again... or from anyone else.