Hi; The "neither" option is what frustrates me reading this. We want to expose public state, and yet apparently we have to keep implementors in mind that have no standard way to expose that public state. ... I reluctantly agree. I was operating under the assumption that at very least either WSRF or WS-Transfer would be an acceptable requirement. Not having any public state model requirement at all makes this a slightly different problem in my opinion. I believe that today's reality is that you can't assume universal WSRF or WS-Transfer support anytime soon. I think I'm with you now for the most part. I just have a problem with singling out one property over another in terms of which ones are "good enough" to have their own accessor operation. Especially if we allow for notifications, the activity status might be the least used and yet you are proposing that we make it the only property that gets it's own accessor operation. Perhaps it would be acceptable to create a hybrid operation that either takes an array of property QNames and returns those properties (ala WSRF's "GetMultipleResourceProperties"), or if the array is empty/not specified returns the entire public state document (ala WS-Transfer's "Get"). If we need a multiple-activity operation for the BES services, then just add another argument that is an array of activity EPRs and name the operation to distinguish it from the singular operation. I didn't mean to advocate that there be an explicit accessor function for only the activity status property. Rather I was advocating that there be accessor functions for each of the properties and that the interop standard mandate that there be at least the accessor function for returning an activity's status (in addition to the accessor function for returning all the state information for an activity). All other accessor functions would be part of extensions. In my response further down I explain why I prefer explicity accessor functions over a WSRF-style GetMultipleResourceProperties approach. This is essentially what I was pushing with my ambiguous public state model concept. What I wasn't considering was this new (at least to me) requirement for no public state model at all. If we can't assume a public state model, then we have to basically agree on some minimal reconciliation between WSRF and WS-Transfer since the BES spec implies some sort of public state model as a result of it's definition of statefull service properties. The two candidates seem to be the following: 1) Have named accessor operations for each property and one operation for obtaining the entire public state document, or 2) Have a single, generic operation that fetches either an array of properties or the entire set of public state properties. I would advocate taking approach 1 for the following reasons, derived from an explanation of a colleague of mine recently provided me: The advantage of the explicit accessor function approach, given the current tooling and suite of technologies that most of the world has, is that you can describe it completely using metadata (i.e. WSDL). The latter approach cannot be described in WSDL, hence the need to introduce the additional message exchange (GetListOfProperties). The disadvantage of the explicit accessor function approach is that you can't request more than one property at a time. You might ask why being able to describe the interface completely in WSDL/XSD matters. The reply to a 'GetState' request will have to be a message with open content... <properties> <xsd:any> </properties> Of course you can define in your specification that if property A is included in there, then the structure would look like <properties> <A> <foo /> <bar /> </A> </properties> However, now this description is in a human language specification and not in a machine-processable vocabulary. You have to manually make sure that you implement support for the various infosets before you can deal with the results. If you make an error in your implementation then the tooling won't help you - nor can the tooling help you with any kind of static analysis of your interface for correctness or security purposes. If you define explicit messages, then you can describe the structure using WSDL and XSD and you can point your favorite WSDL->Java or WSDL->C# tool at the WSDL document and everything will be generated for you. There would be no surprises because the two sides have agreed on a contract. Note also that such tools make the creation of client code for using a multitude of explicit accessor functions fairly painless. Marvin.