[rm-wg] Some Questions :o)

[Laurence Field]

Hi Paul,

 From the perspective of the consuming organisation (we need to think of 
a better term) it stops at step 3.  We delegate the responsibility for 
carrying out the activity to the service.  We know that we have a share 
of the resource which the service manages and have described our 
activity.  How the service does this is of no concern to us. What does 
concern us is that the service ensures that our activity is completed 
correctly.

I will try to come up with a sequence diagram for the Workload and Data 
Management scenarios.

I quite like the direction all this is taking and the diagrams seem to 
make sense in many places. I especially like the concept of the activity.


Laurence




Strong, Paul wrote:
>
> Hi Sergio,
>
> I have taken the liberty of perhaps suggesting a slightly different 
> breakdown (see attached).  This is based on the following workflow
>
>    1. A consuming Organization agrees one or more Share(s) with an
>       Admin Domain for the access to a Computing Service.  That
>       Service may comprise a set of Compute Resources and Application
>       Resources.  Share could include types of resources, quantities,
>       achievable SLOs and so forth.
>    2. The Admin Domain delegates responsibility for delivering a
>       specific Share to a specific Computing Service.
>    3. A User within the consuming Organization then submits a Job to
>       the Computing Service.  The Job request includes target resource
>       types (application types, cpu types?) and desired quantities and
>       so forth
>    4. The Computing Service checks to see if the Job request can be
>       fulfilled by matching the Job request details to available
>       Resources under it's management.
>    5. If the Job can be fulfilled the Service creates a logical
>       Container and maps the Job to it.  In reality, this may mean
>       associating an Application Resource with a Computing Resource
>       and then the pair to the Job.  The Container is a useful
>       abstraction as other resources may be added later.
>
> Whilst I think this is probably nowhere near perfect, I think that 
> enumerating your use case and sequence diagram in a way similar to the 
> above will make this exercise much quicker.  
>
> In this the Element becomes a Container, which can make use of various 
> resources, for example physical machines, virtual servers, application 
> binaries, data and so forth, thus providing an execution environment.  
> The Container is created on demand when a Job is accepted, based on 
> the resources that the Service has available to it, the resource types 
> and quantities requested by the job and the resource types and 
> quantities still available from the share.
>
>
>