Frank Siebenlist wrote:
Savas Parastatidis wrote:
The argument that is being made is not that an implementation of WS-RF cannot exist on .NET. WSRF.NET demonstrates that this is possible.
The argument is about whether support for WS-Addressing is all that is required in order to interact with services built on top of WS-RF. I believe this to be an oversimplification. Support for WS-Addressing is absolutely required. However, it's not enough. The implementation of the semantics of the ResourceProperties and Lifetime related messages have to be provided. If they are not provided, a developer will end up implementing them.
So, WSRF.NET implements the support for RPs and Lifetime on *standard* .NET, such that developers will not have to implement the primitives, can easily deploy the great abstraction that they represent, and can instead focus on higher-level application code.
Furthermore, it will allow us to model the world the WSRF-way with the confidence that those developers do not face any impedance mismatch on the .NET platform.
The analogy I usually use is this... The interaction with an HTTP server requires TCP/IP. If you have socket-programming libraries you can interact with the HTTP server. However, in the process you'll be implementing a programming library for HTTP communications.
Those are only the masochistic-type of programmers who do not (want to) look for available http-libraries that implement the stack for them...
-Frank.
PS. (...be careful not to give arguments in support of wsrf and wsrf.net ;-) )
I am surfacing from the wondrous joy of editing XSD documents to join in this discourse. To an extent, MS are the gorilla-outside the room when it comes to WSRF. They dont embrace it, but they haven't come out publicly against it. There is a reason for that: they are busy with indigo. they have to convince all existing .NET developers that Indigo is the way to write distributed applications, and they have to make it look attractive to potential users in the java and C++ lands. The most pressing threat is the fact that REST is emerging as the defacto standard architecture in public APIs - Amazon, google, Flickr, making WS-* seem like a premium niche for enterprise systems that actually need things like transactions or ws-security. WSRF and grid architecture is probably a secondary issue compared to the.net2.0 and indigo story. Even if they did like WSRF, support for it is not on the roadmap for the next couple of years in the built in stack, till the .net 3.0 timeframe. Question is: does that matter? If the third party toolkits on top of the SOAP stacks are good -WSRF.NET, Apache Apollo, then not. A core issue is still the quality and arch of the underlying stacks, such as Apache Axis and .NET 1.1 WSE. I have issues with both those implementations, and the issues are WS-RF independent. What may matter more that as MS continue to issue WS-* specifications on a regular basis, the MS Specification stack and the WSRF spec stack will diverge. All the higher level WSRF specs (WS-N, WSDM, my forthcoming CDDLM deployment API,, etc), all depend on WSRF resources underneath. They are no longer orthogoal with each other. You cannot have a manageable web service using MOWS (ok, part2.xsd) unless that endpoint is a WSRF EPR. You also need consistent uses of WS-A versions underneath, consistent use of versions of WS-RF, WS-n, etc. Right now that is very hard to achieve, given that there is minimal consistency between the core OASIS-hosted WSRF projects. They dont even use a unified version of WS-A. The other subtlety is whether users of WSRF on the MS platform counts as successes "users of WS-* and .NET" or failures "not using the ms approved technologies". I think REST vs SOAP is the more significant ideological war being fought right now. WSRF users are effectively hardline SOAP users, as we not only embrace the SOAP philosophy, but WS-Addressing and what is implicitly a distributed object model on top. REST is winning over the public services *despite* the complete lack of REST support in any vendor's stack other than an http client lib and an XML parser. So presence of a stack or vendor support is clearly not essential. What does matter is immediate, tangible value, and ease of development. I will cover issues with defining a WS-RF based service another time. As Savas points out, the semantics of <wsrf:destory> are exceedingly complex. From my own personal perspective, the lack of fault tolerance in the current (last Friday's, I haven't checked since then) WSA EPR is a concern. The address in an EPR is meant to map to a URL, so unless you do failover in DNS, you don't have location transparent references. But again, this is not purely a WSRF failing. it is just that by mandating that every resource must be identifiable by an EPR, you end up losing location transparency with ever resource, no matter how fault-tolerant an individual stack's implementation of state is. -steve