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

Sat Oct 15 10:25:52 CDT 2005

I like the concepts.  So basically, since the ACS spec is flexible (a 
good thing), then it can be later profiled as needed to further standize 
its actual usage.  I image as part of such a profile, that certain AAIDs 
might be specified for certain types of content.  Certain names could be 
reserved for EMS purposes, for instance.

Ziu, Peter wrote:

>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
>
>  
>

-- 
Michael Behrens
R2AD, LLC
(571) 594-3008 (cell) *new*
(703) 714-0442 (land)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/acs-wg/attachments/20051015/86871269/attachment.html 