And here's what I'm curious about (haven't had time to play with any of this in the past year or two, but plan to look into it now):

I've always constructed my asmx web services to accept and return simple datatypes, such that they are compatible with different platforms ... IOW, they can be consumed by non-.NET applications. Consequently, when I returned a DataSet, I did *not* return a serialized DataSet class, but returned the data itself, serialized into XML ... return MyDataSet.GetXml(); ... which is simply a string of simple XML that can be read and utilized by any app, not just a .NET app.

Given the above scenario, and assuming that I want the same sort of interopability with other platforms, I'm assuming that the main thing that WCF gives me is the flexibility of using my service in different ways (Remoting and queuing) ... even if I want to keep my simply datatypes. Is this a fair assumption to make?

~~Bonnie


>Hi,
>
>OK. Thanks for clarifying. So WCF includes its own implementation of web services that replaces the ASP.NET one.
>But, if we are limiting the discussion to web services, then I'm not convinced that the WCF model is, overall, an improvement over the asmx version.
>For instance, having read http://msdn.microsoft.com/en-us/library/aa738737.aspx, it seems that although WCF gives you better control over *what* gets serialized (I like that) it doesn't offer much control over *how* the XML is shaped.
>
>On the state management front it looks as if WCF doesn't give much flexibility in how this can be stored (unless you stick to asp.net compatability).
>
>It sort of feels as if all this is aimed at making .NET more clever in talking to itself but doesn't help much in the wider web services context....
>
>Best,
>Viv
>
>
>>It basically replaces ASMX, but can also be used for other types of messaging. For example, it also replaces .NET Remoting (which replaced COM+, which replaced DCOM) and it can also be used for queuing.
>>
>>>I'm not really the one to ask :-{ but my understanding is that WCF just provides a general architecture for message transfer. If might use web services (or remoting, message queues or whatever) so, as such, if doesn't replace web services - just sits on top of them.