On Dec 02, William Lee modulated: ...

Issue 1: What the type of the service addressed by the EPR returned from a CreateActivityFromJSDL request?

[Section 5] suggests the type of the service is out of the scope of BES. However, it hasn't addressed the fact that an activity might not even have a service representing it. If I implement this hypothetical BES service, what should I put in the <wsa:Address/> element?

I think this is a constant confusion in terminology that should be clarified in the BES writeup... there is a difference in level of abstraction between the kind of activity management mechanisms that might be supported for a specific JSDL Application type, e.g. POSIXApplication, and the type of application or service being instantiated by the activity, e.g. a particular fluid dynamics code. I don't know what these concepts should be called, but it is very confusing when some people call "POSIX activity" the application/activity type and other people call "my fluid dynamics code" the type! I think BES, or profiles of specific JSDL document subtypes with BES, must define at least the basic relationship between the input JSDL document contents and the resulting management resource(s) and service(s) which represent each activity instance implied by a particular input document type. These resulting interfaces then should be tied into the protocol specification as appropriate, e.g. in allowing assumptions to be made about the type of WSDL interface that MUST be available at a resulting activity endpoint. Recognizing the difficulty in drawing boundaries between "application" and "management", I think these profiles could also describe how additional instance-specific services are exposed dynamically. This approach can be repeated indefinitely, in an onion-like deconstruction of the JSDL input document into extension types and eventually into specific data fields. However, I think an opportunity is wasted if BES cannot support more static inference to determine what base management interfaces should be available as a result of a particular "outermost" input JSDL application subtype.

Issue 2: Should a <bes:activity-identifier/> (currently an EPR) be totally opaque to users other than the issuer (the BES service)?

If the client does not understand how or even wish to interact with the service referenced by the EPR, the <bes:activity-identifier/> is completely opaque because they are simply copied into the bodies of GetActivityStatus, RequestActivityStateChanges and GetActivityJSDLDocuments. There's no need for the content to be introspected.

I think this is one of the fallacies of trying to render BES generically instead of in a binding-specific way. The most appropriate renderings diverge for a WSRF-style approach where the activites themselves should be resource-qualified endpoint references, versus a name-oriented approach where non-qualified endpoints are targeted with messages containing activity names. In my view, the current draft use of WS-Names is the worst of both worlds, providing a superficial appearance of generic interoperability on top of the same fundamentally non-interoperable approaches. This seems worse to me than just having different specialized renderings for different subcommunities. (Implementors can always choose to couple either or both renderings to their underlying implementation mechanisms, just as they can choose how to juggle all the optional or underspecified features of a generic rendering.)

If the client wishes to interact with the service referenced by the EPR (and know the type of course), the <bes:activity-identifier/> will serve as both the address and the identifier (a <wsa:ReferenceProperties/>?) to the activity. I can only interact with the activity through the service (e.g. POSIXControlService) addressed by that EPR. Even though there might be a third service (at a different <wsa:Address/> and different type [MonitoringService]) that can interact with my activity. I can't just replace the <wsa:Address> with the new one and stick in the original <wsa:ReferenceProperties/> because it's supposed to be opaque. How should I perform this resolution?

In a WSRF-style rendering (ignoring WS-Name), I would expect the renderings to include resource properties which can be used to correlate one typed resource with another of a different WSDL type (understanding that they both operate on the same implied resource state identified by these common properties). I would then expect to consult service groups or other discovery mechanisms to search for correlated endpoint references using these properties. I have to admit I am not sure how WS-Name is supposed to work here, e.g. whether one should be able to project a name out of one endpoint and inject it into another. This seems to be one of the dividing lines which created opposed camps in all previous discussions. In the non-WSRF approach, this question is also left wide open. There is a simple name (possibly an IRI as you suggest), but there is nothing there to suggest which IRIs should be composeable with which service endpoints! It still requires out of band knowledge and/or discovery.

My point is (if my interpretation is correct) is it a good idea to use a service address to identify an activity? If we are not specifying the type of the service referenced by the EPR, is there any value in using an EPR (instead of ... an IRI)?

The only value I see right now is as a concession so that a WSRF-style implementation can be more trivially mapped into the specification syntax, e.g. implementation-specific activity endpoint references can be returned and manipulated by clients. However, this will need to be constrained by profiles to allow those clients the comfort of KNOWING they can use the references as such if they succeed in submitting a particular specialized JSDL application description, so this does not actually promote interoperability any more than having two separate renderings, one in the resource-qualified reference style and one in the bare names style.

William

karl -- Karl Czajkowski karlcz@univa.com