[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ASAP, WS-Resource
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]