[Oslc-Automation] Updates to Availability Spec

Wed Aug 20 11:32:07 EDT 2014

Hello group,

finally I've completed my rework of the Availability Spec. I hope I got all
your comments (thanks again a lot covered), but I also have changed a lot
of things in the spec.
You can find the latest spec here:
http://open-services.net/wiki/automation/File%3Aavailability_draft_2014_08_20.pdf
Behind this link you can find a version including the changes I've made (as
Open Office allows to record) since the previous version. This may help to
skip old sections that haven't been changed:
http://open-services.net/wiki/automation/File%3Aavailability_draft_changes_2014_08_20.pdf

The following BIG changes I've done described in a few words:

(1) Removed all unnecessary properties like mttr, rto etc. since they're
not needed for the current scenarios.

(2) Removed the synchronized/ unsynchronized-stuff, that somehow was mixed
with Availability sub-domains.
Instead I've introduced now one single sub-domain
"http://open-services.net/ns/availability#Automated".
Implementing this sub-domain means, that the Availability Resources of the
service provider are automated and not intended to be controlled manually
(e.g. by a software like SA z/OS).
Therefore it is also recommended to implement the Automation Spec if this
sub-domain is used.
If this sub-domain is implemented, the service provider MUST provide the
Action Profile "Create an Automation Request".
If the sub-domain is not implemented ("general purpose"), the service
provider MUST provide the Action Profile "POST RDF described by a OSLC
Resource Shape to the Action resource" instead.

(3) Changing the condition of an Availability Resource is done by executing
an Action, the ConditionAction (this is already known by the old spec
draft).
Additionally, managing the membership of an Availability Group is now also
done by an Action, the "MembershipAction".

(4) Replaced the "compoundState" with "consistentState", that's goal is to
signal if a resource is in a consistent state.

(5) Property values: Properties like oslc-availability:{consistentState,
currentState, desiredState} etc. are now specified to be a 1:n or 0:n
cardinality. The spec pre-defines values for them (like "Available",
"Unavailable" or "Consistent", "NotConsistent")
and specifies that a service provider must use at least one of the
predefined ones. But: A service provider is allowed to specify own
properties and use this additionally to the enforced ones. This allows a
service provider to provide additional information to the predefined
states,
for example why a resource is "Unavailable" (e.g. by "OutOfMemory" or
so...)

(6) Rewrote the "Availabilty Specification Guidance" to give a better
understanding on how to use "Availability" and especially how to do the
scenarios with it.
I need to already apologize, because I assume that there is a lot of text
that could be written in a much better way. Its hard for me as a non-native
speaker to write in the "specification style".

(7) What I haven't changed is the namespace, because its still unclear how
it will look like. Maybe we need to do a big "search and replace" later,
but that shouldn't be a problem.

(8) I have uploaded this draft still to open-services.net, but I have
moving to OASIS on my TO DO list and hope to be able to do so, soon.

Thanks a lot!

Mit freundlichen Grüßen / Kind regards

Tim Friessinger

System Automation for z/OS Development
IBM Software Group, Tivoli
IBM Lab Boeblingen, Germany

 Phone:            49-7031-16-2535                IBM Deutschland                            (Embedded 
                                                                                           image moved 
                                                                                              to file: 
                                                                                         pic11721.gif) 

 E-Mail:           tfriess at de.ibm.com             Schoenaicher Str. 220                                

                                                  71032 Boeblingen                                     

                                                  Germany                                              

 IBM Deutschland                                                                                       
 Research &                                                                                            
 Development                                                                                           
 GmbH /                                                                                                
 Vorsitzende des                                                                                       
 Aufsichtsrats:                                                                                        
 Martina Koederitz                                                                                     
 Geschäftsführung:                                                                                     
 Dirk Wittkopp                                                                                         
 Sitz der                                                                                              
 Gesellschaft:                                                                                         
 Böblingen /                                                                                           
 Registergericht:                                                                                      
 Amtsgericht                                                                                           
 Stuttgart, HRB                                                                                        
 243294                                                                                                

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pic11721.gif
Type: image/gif
Size: 1851 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20140820/c40e5d19/attachment.gif>