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