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.