[ogsa-bes-wg] Updates to document

[Peter G Lane]

On Wed, 2006-05-24 at 12:59 -0400, Andrew Grimshaw wrote: 
> > I'm concerned about this term "container" as used in the document. This
> > is very confusing as this term is already used to refer to the web
> > service hosting infrastructure (i.e. Tomcat, GT's "standalone
> > container", or figure 1's "service container").
> [Andrew Grimshaw] 
> 
> We've been using this term for some time - and indeed if you look at the
> larger EMS picture the "services" started may in fact be stateful web
> services. The sense is that the "service" - or legacy activity in the case
> of BES, is logically "contained" by its execution environment.
[Peter Lane]

Perhaps a compromise by changing it to "activity container" or
something? The term is being used in two different ways AFAICT within
this one document.

> > In section 5.1.1 I find the IsAcceptingNewActivities RP rather useless.
> > The client will find out just as easily if the service is accepting new
> > activties depending on whether a NotAcceptingNewActivities fault is
> > thrown or not. Checking the RP first both creates an extra WS operation
> > call and cannot be guaranteed since there is a potential race condition
> > between when the RP value is returned and the submission call is sent.
> > If there was some negotiation protocol incorporated into BES I might buy
> > this, but otherwise I don't see the point.
> [Andrew Grimshaw] 
> There are always race conditions in DS's. What if I want to discover whether
> you are taking activities - but not necessarily start an activity, for
> example to construct a candidate set of BES containers?
[Peter Lane]

Do you have a more concrete example. I'm not quite following.

> > In section 6.1, I feel it's superfluous to suffix the operation name
> > with "FromJSDL". Are there plans to support something other than JSDL?
> > If not, why not just make this "CreateActivity"?
> >
> [Andrew Grimshaw] 
> BES is the simplest, most basic, "type" of a service container in the EMS
> architecture. Rather than assume that for all time only JSDL will be used
> seemed overly restrictive. In BES there are no plans for anything else - but
> ...
[Peter Lane]

So you're saying you want to be open to possibly accepting job
submissions in other job description formats in addition to JSDL? I'm
not trying to be too harsh, but this seems a bit anti-standards to me.
It's like saying you can use SOAP or some other competing standard to
format a web service message. The whole point of standards is to get
everybody doing the same thing. If BES doesn't commit to JSDL, why
should anyone else commit? Perhaps this is another political decision,
in which case I'm not going to push it anymore than that.

> > Section 6.1.2: absolutely unique idempotence IDs are impossible to
> > guarantee. I'm of the opinion that these should be valid only for the
> > life of a job. Besides being ridiculous to assume that the service
> > should keep track of these IDs to make sure it is never ever used again,
> > doing so serves no real purpose.
> [Andrew Grimshaw] 
> I happen to agree with you - certainly for all time is difficult, and
> depending on exactly what semantics you think you're getting, impossible.
> However, this is in there as a result insistence and a long discussion on
> input (ESI document) from the Globus and Unicore teams.
[Peter Lane]

The ESI document indeed says the exact same thing. I guess I'll have to
raise the issue with the ESI authors as well. ;-)

> > Section 6.1.3: If there is an optional subscription request element in
> > the input, then there needs to be an optional subscription reference
> > element either in the output (preferred to avoid an RP query round trip)
> > or a resource property.
> [Andrew Grimshaw] 
> I'm not sure I follow - you mean you want a handle to the subscription in
> the return?
[Peter Lane]

Yep. I think that's reasonable even from an abstract point of view. Customers
like to have a subscription ID so they can cancel or change their subscription
as desired. At very least this needs to be published somewhere.
Otherwise the user is relying on implied resource termination to clean up the
subscription.

Thanks for your responses. I look forward to the rest.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3720 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/ogsa-bes-wg/attachments/20060524/d160a2a1/attachment.bin