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. 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. 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.) 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. 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. Marvin.