[acs-wg] RE: Your comments on the draft spec.

[Ziu, Peter]

Keisuke,

I read your .ppt sent to OGSA/CDDLM, I don't think there is a problem since
I
don't seen anything restricting a job document to be in an AA.  The concern
I
had that caused me to comment was a 'best practices' concern that perhaps is
best address in OGSA and does not need to be addressed in the ACS spec.  It
may need to involve other building off our spec, and adding constraints on
what should be in certain AAs.

My simple concern was that the job doc that starts the ball rolling should
be
encapsulated in something with a version number, and protected against
undesired modification via signature, much like an AA can do.  As you
pointed
out, we are not preventing this, so the comment can be addressed elsewhere.
I
agree, I think that for the most part we don't put restrictions on what
content can go in the AA, and that is reflected in 3.1.1.  I also agree, it
is
reflected in 3.1.4 that job "instance" should NOT be maintained.  I think
this
is well stated.  We should perhaps clarify that this does not mean that JSDL
is excluded from an AA.  To me job "instance" means any dynamic state
concerned with an executing job, and this does not restrict the ability for
a
job managing entity to obtain JSDL from an AA, correct?

Food for thought:  Since AA's can have external references, there is nothing
stopping a "root" AA from containing nothing but a JSDL doc, and a reference
to the main content AA.  If this type of job submittal format was optionally
allowed by OGSA, then an EPR of a "root" AA could be submitted to the job
managing entity to kick off a job, not just a JSDL doc.  This would mean
that
the actual execution instruction is conveniently archived in the repository
with a version and signature.

Pete.

-----Original Message-----
From: owner-acs-wg at ggf.org [mailto:owner-acs-wg at ggf.org] On Behalf Of
Keisuke
Fukui
Sent: Friday, October 14, 2005 1:44 AM
To: Ziu, Peter
Cc: acs-wg at ggf.org
Subject: Re: [acs-wg] RE: Your comments on the draft spec.

Pete,

Glad to hear that you doing fine and hope to see you. I will prepare myself
for the discussion toward next step.


Ziu, Peter wrote:
>
> In the section "3.1.4 Relationship between AA and Job" (Page 14), you
> left the comment "D10" below:
> Perhaps we could say a unit of "configuration management"
>
> We didn't see problem here in the review at GGF15. Can you elaborate
> on this a bit more?
>
> I think the above statement did not outline a problem in the doc that
> needed fixing, but rather an opportunity to make the distinction
> between sofware components, configuration and runtime
> parameters/contraints[jsdl], and that these distinct components could
> be concidered one configuration mananaged package within the AA.

I come to understand a part of your point in the original description:
----------------------------------------------------------------------------
An AA can be used to create a job, i.e. a unit of task, in the grid system.
----------------------------------------------------------------------------

However, we have a general description of AA, a few pages before, in section
"3.1.1 Application Archive and Repository" as below:
----------------------------------------------------------------------------
Such information may include, but not limited to, the application executable
code, configuration data necessary for initial deployment of the application
and the deployment descriptor documents.
----------------------------------------------------------------------------
This clearly states that not only the software components, but also any data
specific to the software can be stored.

Then, we came here to in "3.1.4 Relationship between AA and Job", drilling
down to the advanced topic. As such, the description here is focusing the
relationship to Job instance of AA instance. An single AA should be able to
be
reused to instantiate multiple jobs. So the relationship between them should
be maintained by Job Managing entity in the system. I explained this in the
slides named "acs_GGF15-F2F-EMS-draft.ppt" attached to my message in ogsa-wg
ML on Oct 12 in response to Dejan of CDDLM.

It would be better if we could have simple and complete statement in one
place.
I think the current text is my best shot, though I admit they may give the
readers somewhat dispersed and complex impression. In summary, I believe
that
the original text doesn't conflict your vision. Please correct me if I'm
still
besides the point.

> package within the AA.  (a managed unit w/ version)  This is important
> for automated repeatability.  This relates to some comments that
> Andrew Grimshaw had at the Sunnyvale face to face, that one can take a
> software unit, supply different parameters, and in essence wind up
> with a "new piece of software and function".  At the time, to me it
> seemed important to capture a version and place for this new piece of
> software.  So by treating job as part of AA content, this is possible.
> In this way, to run a job, one could pass to the "job manager" the EPR
> to an AA.  I am not sure I can defend myself properly on this
> position, it seems on the surface plausible, but not mandetory.  It
> seems more highly organized than having the JDSL somewhere out there,
> but also the idea seems to not be required in all use cases.  Hope
> this helps to clarify
> :-)
>
> With respect to replication, what is written in 4.5 is fine.  I think
> we should perhaps leave things to master/slave for now to be able to
> accomplish a version 1.0.  My comments a few meetings ago about
> replication GUIDs are really only a concern in bi-direction replication,
so
we are ok for now.
> There are too many open GGF issues right now with repect to naming,
> which would be a key component of any replication scheme, and also,
> the orep-wg's inactivity (last time a looked [a few months ago]).  I
> think what is written is excellent for now.

Thanks! I've been trying to keep our first specification simple, as well as
very combinable with other specifications or technologies, to go along with
SOA thought. Those replication topics are among them in my mind. ACS should
be
a pluggable service component in the grid systems. I hope once we finish the
base spec out, then we can continue building another one on top of that.

  -Keisuke

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 2450 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/acs-wg/attachments/20051014/82cfebd8/attachment.bin