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

[Steve Loughran]

Ian Foster wrote:
>>  First, please allow me to say something about my claim that the OGSA WG
>> mandates WSRF, a claim which you have questioned. I may have
>> misunderstood the group's intentions, in which case I apologise, but
>> discussions with various people and minutes from meetings directed me
>> and many others towards making that conclusion (this was raised by
>> several people at the UK-OGSA meeting). Also, the current draft of the
>> OGSA Basic Profile, to which I assume all high-level services will have
>> to adhere, is described in terms of WSRF. 
> 
> 
> Savas:
> 
> What I meant about "mandating" (which upon reflection I suspect is what 
> you meant too):
> 
> A profile typically says simply that IF you use something, THEN this is 
> how you must use it. It doesn't say you MUST use it. Thus, the OGSA Base 
> Profile doesn't say anything about whether WSRF should be used or not, 
> it just says how you should use it if you do.
> 
> Where, then, is WSRF "mandated"? At present, nowhere. However, moving 
> forward, it would seem likely that when OGSA WG considers say a 
> management specification for inclusion in some future "management 
> profile", it will look kindly on one that uses WSRF conventions to 
> access remote state, rather than making up its own custom ones, because 
> that is viewed as enhancing interoperability. It would then also want to 
> see that WSRF is used in a way that adheres to the OGSA Base Profile.
> 
> On the other hand, when considering specifications that have nothing to 
> do with state (e.g., naming), there would be no reason for WSRF to come 
> into the picture. The draft OGSA Naming Profile that Andrew Grimshaw is 
> developing does not use any WSRF mechanisms. It *could*, but this hasn't 
> been seen as particularly useful, so it doesn't.
> 
> And (the point I was harping on, probably too much), there is nothing to 
> say that you must use WSRF conventions when developing your own services.
> 
> So, I guess WSRF is "mandated" in some places, and not in others.

The moment you say 'manageable' you embrace WSRF. More to the point, the 
moment you embrace WSDM1.0, you also embrace WS-Addressing 2003/03 for 
WS-Notification, and WS-Addressing 2004/08 for 
mows-identity-reference-type.

It  takes about two to eight hours to fix up a set of WSRF 
specifications so that both namespaces co-exist in a set of documents 
without XML spy complaining, though I suspect the modifications made to 
the WSRF-1.2-draft0.1 documents to achieve this consistency may actually 
violate the OASIS copyright terms.

This is the policy we have had to come up with to address versions in 
the CDDLM working group:

1. We will use 1.2-draft-0.1 of the OASIS versions of WS-RF, WS-N for 
our WSRF schemas.

2. We will use wsa: to refer to WSA 2003/04 everywhere . Our addresses 
will be compatible with the draft of WS-N

3. We will declare the wsa2004: alias to the WSA 2004/08 namespace. This 
will only be used in returning MOWS identity references and wherever 
else WSDM needs it.

4. We intend to update this stuff when the underlying specifications are 
standardised. Specifically, once WSA becomes a W3C release, and the 
WSRF, WSN, WSDM specs are updated to reflect that change, then we will 
move too.

5. We will keep copies of the specifications we use under SCM in the 
sourceforge project that hosts the schemas. This is the only way to 
ensure that the specifications will remain available and consistent. 
Already bits of draft-0.1 are missing, even though WSDM is based on it.

I don't know about Dave Berry's idea of irony, but the current set of 
WSRF specifications are not, well, convenient to work with at the XML 
level. Because WS-A is itself a moving target, everything built on it is 
also built on specific, draft, releases, leading to potential for 
interop problems.

This is an issue regardless of whether you use WSRF, or whether you use 
WS-* with WS-Addressing. There is not enough stability in specification 
or implementation to be able to say "this is our code, we guarantee that 
it will continue to work for 5 years". Only REST services built on 
HTTP1.0+XML1.0 can pull that off, at the expense of no structured fault 
mechanism other than http error codes, no security other than HTTPS 
and/or HTTP basic/digest auth, etc etc.

I am attaching the latest draft of a paper I have been co-authoring, in 
which Ed Smith and myself argue that existing SOAP stacks, especially 
the JAX-RPC implementations, are the wrong platform for implementing web 
services that take full advantage of the XML structure in the message. 
This is independent of whether you use WS-* or WS-RF. Axis2 and XSUL 
work  Alexsander Slominski and colleagues at Indiana University seem to 
be heading in the right direction.

Some time in the next few weeks, we will do a quick postmortem of our 
experiences designing a WSRF based architecture/message set, 
highlighting what works, and what doesn't. I need to do a bit of 
implementing first, however.

-steve






-------------- next part --------------
A non-text attachment was scrubbed...
Name: jaxrpc.pdf
Type: application/pdf
Size: 48382 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-wg/attachments/20050304/7a2261d5/attachment.pdf