[ogsa-bes-wg] EPR as activity identifier

[Karl Czajkowski]

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 at univa.com