ASAP, WS-Resource

[John Fuller <jfuller@wernervas.com>]

OGSI-people:  correct me if I misunderstand my reading
ASAP people: what do you all think we should do?
In light of the WS-Resource specifications,as we review our ASAP draft,

If I read the WS-Resource documents correctly, if our factory were to 
be a WS-Resource
factory, should our current communication of URIs be replaced with 
WS-Addressing endpoint references?
Our ASAP list has already had some discussion about Dr. Fielding's 
paper and the
benefits of letting URIs do the work for you in the existing web 
environment.
WS-Addressing certainly offers structure to explicitly distinguish 
communication endpoints
and targets they reference.  If this structure is useful, I suppose 
another concern is whether
our document working within a standards body should build on a 
specification that hasn't been submitted to a standards body.  I know 
there were qualms about this in WS-CAF, but I
also see WSDM is looking at moving toward the WS-Resource approach.

If we use WS-Resource, to what extent should we replace our existing 
messages?
Our document already uses the term "resource properties" for the 
factory, observer, instance
(and activity), should their properties be expressed as 
ResourceProperties?
There's a bit of added complexity in supporting XPath for querying the 
properties
rather than just returning the ones we know we need, though the benefit 
is a common interface.
Since these properties are extensible, they seem like they would 
provide a way to
provide a way to represent associated variables that represent an 
abstract state
which would be useful for complicated subsystems.

If we use WS-Resource for our factory and the properties, people could 
choose to use
WS-Notification for their service instances.
Since we define the observer role anyway, should we use WS-Notification
for our state changes?  For our completion request?
Again, there's a bit of added complexity with Topic spaces and the 
associated expression language, and additional roles to potentially 
support in the publish-subscribe model...
We could say that our observer is a subscriber and notification 
consumer,
and our instance is the producer and publisher.  There's also the 
addition representation of the subscription itself and its management 
to deal with.

I believe our original goals were to provide a simple SOAP extension 
for asynchronous service access, and I worry about creeping complexity. 
  On the other hand there seems to be obvious conceptual overlap here, 
and it would be hard to ignore it.

OGSI-people:
I'm working on a C++ open source implementation of ASAP, and I know 
Globus is working on a WS-Resource implementation.  It would be nice to 
collaborate as possible in light of the additional functionality and 
infrastructure potentially required with WS-Resource.