On Wed, 2006-06-14 at 13:25 -0700, Marvin Theimer wrote:
Hi;
I still don't understand what you're getting at here. I don't see this as the two interfaces are mutually exclusive. I just don't see any point of having identical operations for both the BES/activity factory service and the activity service. If the factory and activity service were the same, then fine. If they are two distinct services then tailor the interfaces. You mentioned "keeping them in sync". I still don't understand your concern here. What is it that frightens you about the BES group being able to keep the two (which are intimately related) in sync?
I’m just trying to advocate good software engineering principles here: I would prefer to avoid having to keep two interfaces in sync with each other across two different specifications. It’s not a big deal and I’m religious about it. I believe that in a later email you suggest that both interfaces be kept in the same spec. That seems like a good idea unless another compelling reason should pop up that argues for keeping them separate.
Ok, I'll consider this reconciled, then. ;-)
I would rather see a generic property getter method instead that takes an array of EPRs. This would model better w.r.t. WSRF's getResourceProperty, etc... methods and avoid the precedent of providing individual operations for each property.
The challenge here is the schism between the WSRF and the WS-Transfer camps. Although that schism is now slated to be healed by the new reconciliation effort that IBM, Microsoft, et al. announced recently, that reconciliation won’t be finalized for another year or two. Recall also that, although I’m proposing that the base case BES interface just deal with individual activities, one of the extensions that I expect will get added very quickly is an array interface for dealing with multiple activities in a single interaction. For the latter interface, it does not make sense to query the factory service’s resource properties (in the WSRF-oriented world) or its EPR (in the WS-Transfer-oriented world) since the query is about the state of a bunch of activities, not the factory. Since I’d like to have the interface for dealing with arrays of activities and for dealing with individual activities look as similar as possible – and given that the reconciliation of WSRF and WS-Transfer has not yet been completed – I’ve introduced named operations for the type of state I wish to see returned.
I have to admit that I had to read up on WS-Transfer. It makes more sense where you're coming from now. It's a very different philosophy of how resource state should be managed. Considering this I think we should still make this activity description a resource state property/element and leave it ambiguous as to how it is accessed. Unfortunately if we don't define the Activity interface we can't define the state item.
Now, you could argue that what I’ve done is expose a single “property” – the activityState property – and a means of retrieving all “properties” in something akin to WS-Transfer style. Based on that, you could argue that we should expose query operations for “all” the individual “properties” of an activity. Since that set is not completely defined and since we will also (at least eventually) want to support extended sets of “properties” and since there is not a reconciliation-approved way of exporting which “properties” an activity exports, I advocate that the base case of BES should aim to export a “minimal” query interface. To me, that’s a way to get everything (including any extensions) and a way of getting the one common state element that we know everyone always wants to query – namely the activityState element. Please note that I have no problem with adding in additional query operations in extensions, but I would argue that the BES base case should be kept as simple as possible. (Along those lines, one might argue that we should jettison the GetActivity operation that returns just the activity’s state diagram state. However, retrieving all the state that describes an activity just to get the activityState seems excessive to me, especially when thinking about how that would behave when dealing with large arrays of activities.)
And here is where I have the biggest problem with WS-Transfer. I think an activity's progress state should be a property that is modeled as desired (i.e. either WS-Transfer or WSRF) as long as there are multiple, popular ways to do so; but as you say, getting the entire state for one item is excessive. That's my personal opinion in general after reading about WS-Transfer. I don't think we should be sacrificing good design just because some implementation detail (I consider this implementation because it's left ambiguous in the spec) doesn't play nice. If you don't like it, don't use WS-Transfer in your implementation. Now then, there is a potentially serious problem here in that if the public state model is not standardized in the spec then how do you know what WS interface to use to manipulate it? In that case I would say we need an operation that specifically targets interop data (kind of like the FTP "FEAT" command). This is yet another reason in support of defining the activity interface. Each activity ought to be exposing via such a method what kind of public state model it uses.
It worries me that this is a non-WSRF-only operation. We should try very hard to avoid branching the spec for two different resource models. If we can't avoid it then there needs to be two separate specs IMHO. What do the WSRF services do with this?
We may have to have two separate specs, if people feel they need a WSRF-based version of the spec. Personally, I’d prefer a single spec that uses neither WSRF nor WS-Transfer and thereby circumvented the problem – but that’s my personal opinion. The interface I’ve proposed essentially tries to circumvent the issue by employing named query and modification operations.
To summarize what is essentially a counter proposal, I think we need to... 1) Expose public state as it was intended to be exposed (i.e. in state properties/elements within the state document) 2) Leave the public state model ambiguous 3) Define the Activity interface 4) Include an interop data fetch operation, say "GetInteropData", on both the BES interface and the Activity interface. The returned data should be well defined but extensible, and include what type of public state model is being used.
I don't really understand what you're trying to accomplish here. You say it's a non-WSRF operation and yet this description says it's an aggregation of the WSRF RPs. Then you add that it might return other stuff as well. This seems like a "give me the serialized resource object" operation. My feeling is that if the necessary information were exposed correctly you wouldn't need this operation.
This again comes down to the WSRF/WS-Transfer schism. I come from the WS-Transfer side of the world and so think of returning state as a single infoset. I’m trying to couch my descriptions in a manner that allows bridging to how a WSRF-oriented person would think about things.
And again I think that if it's burdensome to fetch the entire infoset just for one datum then you shouldn't be using WS-Transfer. It's not the BES-WG's fault that WS-Transfer isn't flexible enough. We shouldn't be making concessions to broken implementations. I apologize if that's a bit biased/harsh, but I'm not sure how else to put it. I want to make it clear that this is essentially a workaround to avoid a limitation of a particular implementation choice. Occasionally that's unavoidable, but I don't think that is the case here. Peter