[ogsa-wg] RE: GRIDtoday Edition: Tony Hey: 'Challenging Times for GGF & Standards'

[Steve Loughran]

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