[rm-wg] Lifecycle Draft Spec

[Natale, Bob]

Hi David,

Your proposed mapping makes sense to me...with (moderate) reservations
about the Saturated case.

For the WSLC, "Saturated" (Down) is distinguished from "Busy" (Up) in
that the Service cannot be "Busy" because it is blocked (by lack of
resources of some kind) from accepting new requests.  Thus, to a
consumer issuing a new request for service, the Service would appear to
be "Down".  The "Saturated" value enables a management application
and/or human operators to take some action to "Relieve" (the state
transition action the WSLC defines for this case) the resource
blockage.  (In fact, maybe "Blocked" would have been a better term than
"Saturated" for the WSLC to use.)

The big plus of the "Saturated" state in the WSLC is better
manageability info.  The downside is possible flapping on the state --
so the Service has to include some threshold manageability capabilities
to deal with that possibility.

Cheers,
BobN

-----Original Message-----
From: David Snelling [mailto:David.Snelling at uk.fujitsu.com] 
Sent: Friday, June 01, 2007 5:10 AM
To: Natale, Bob
Cc: rm-wg at ogf.org
Subject: Re: [rm-wg] Lifecycle Draft Spec

Folks,

My first pass would be to map Up to Active since the service would be  
"severing the purpose for which it is intended". Idle and Busy would  
be substates if we needed them. The Down states are harder. By our  
current definition, I would map Crashed into Extant with substate  
Failed. Stopped is probably Commissioned, since there is some  
indication in the w3c note that it was intentionally stopped and  
could therefore be restarted, e.g. is "commissioned sufficiently to  
be activated".

The crunch is on Saturated, since to my mind from a management  
perspective the component is "serving the purpose for which it is  
intended". It is just very busy. Thus this would be a substate of  
Active.

I think we should add this on to the examples section.


On 31 May 2007, at 05:08, Natale, Bob wrote:

> Hi David,
>
> Concerning this statement in the Abstract:
> "The Reference Model Lifecycle model composes with application  
> specific
> lifecycle or state models and this document provides guidelines and
> non-examples of how to map application specific model to the
Reference
> Model notion of Lifecycle."
>
> The "guidelines and non-examples" regarding mapping were not  
> obvious to
> me.  Would it be desirable/possible to show in the document how the
> lifecycle model described in this document maps to the service level
> states defined in the W3C Web Services Management: Service Life Cycle
> (http://www.w3.org/TR/2004/NOTE-wslc-20040211/):
>
>    - Up
>       - Idle
>       - Busy
>    - Down
>       - Stopped
>       - Saturated
>       - Crashed
>
> Thanks,
> BobN
>
> -----Original Message-----
> From: rm-wg-bounces at ogf.org [mailto:rm-wg-bounces at ogf.org] On  
> Behalf Of
> David Snelling
> Sent: Wednesday, May 30, 2007 4:04 PM
> To: rm-wg at ogf.org
> Subject: [rm-wg] Lifecycle Draft Spec
>
> Folks,
>
> I have posted a draft lifecycle specification on GF. See https://
> forge.gridforum.org/sf/docman/do/listDocuments/projects.rm-wg/
> docman.root.drafts
>
> We should be able to discuss this on Friday.
>
> -- 
>
> Take care:
>
>      Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
>      Fujitsu Laboratories of Europe Limited
>      Hayes Park Central
>      Hayes End Road
>      Hayes, Middlesex  UB4 8FE
>      Reg. No. 4153469
>
>      +44-208-606-4649 (Office)
>      +44-7768-807526  (Mobile)
>
>
>
> _______________________________________________
> rm-wg mailing list
> rm-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/rm-wg

-- 

Take care:

     Dr. David Snelling < David . Snelling . UK . Fujitsu . com >
     Fujitsu Laboratories of Europe Limited
     Hayes Park Central
     Hayes End Road
     Hayes, Middlesex  UB4 8FE
     Reg. No. 4153469

     +44-208-606-4649 (Office)
     +44-7768-807526  (Mobile)