Proposed Charter for OASIS Symptoms Autonomic Framework (SAF) TC

[Mary McRae <mary.mcrae@oasis-open.org>]

To OASIS Members:

  A draft TC charter has been submitted to establish the OASIS  
Symptoms Autonomic Framework (SAF) Technical Committee (below). In  
accordance with the OASIS TC Process Policy section 2.2:
(http://www.oasis-open.org/committees/ 
process-2008-06-19.php#formation) the proposed charter is hereby  
submitted for comment. The comment period shall remain open until  
11:45 pm ET on 7 September 2009.

  OASIS maintains a mailing list for the purpose of submitting  
comments on proposed charters. Any OASIS member may post to this list  
by sending email to:
mailto:oasis-charter-discuss@lists.oasis-open.org. All messages will  
be publicly archived at:
http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members  
who wish to receive emails must join the group by selecting "join  
group" on the group home page:
http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/.  
Employees of organizational members do not require primary  
representative approval to subscribe to the oasis-charter-discuss e- 
mail.

  A telephone conference will be held among the Convener, the OASIS  
TC Administrator, and those proposers who wish to attend within four  
days of the close of the comment period. The announcement and call-in  
information will be noted on the OASIS Charter Discuss Group Calendar.

  We encourage member comment and ask that you note the name of the  
proposed TC (SAF) in the subject line of your email message.

  If you are interested in adding your name in support of this  
proposed charter, please send an email to the Convener.

Regards,

Mary


Mary P McRae
Director, Technical Committee Administration
OASIS: Advancing open standards for the information society
email: mary.mcrae@oasis-open.org
web: www.oasis-open.org
twitter: fiberartisan #oasisopen
phone: 1.603.232.9090


-----
Proposed Charter for OASIS Symptoms Autonomic Framework (SAF) TC

Name of Technical Committee:
OASIS Symptoms Autonomic Framework (SAF) Technical Committee

Statement of Purpose:
IT and business systems are usually well instrumented to provide  
operators and managers with a wealth of information about the state of  
each of these systems. Experts in these domains also possess  
substantial toolboxes of remedial techniques to bring these systems  
and processes back online or to their desired state.

However, there often is a significant challenge in the integration,  
interpretation, and analysis of this diverse state information  
followed by the ability to act on that information. Failure to meet  
this challenge impacts the organization through lost opportunities to  
develop new and extend existing business, as well as the possible loss  
of existing business through 'down time' or lower efficiency. The  
continued drain on business and IT resources also impacts the overall  
operational and business-related costs of the organization.

The aim of the Symptoms Autonomic Framework is to integrate  
information and processes across the organization and/or cloud-enabled  
services in a more holistic way by defining, enhancing, and  
maintaining a standard XML-based framework that will enable the  
collection, detection, isolation, and remediation/optimization of the  
operational or business characteristics of complex systems with  
applicability to both IT and non-IT domains including operational and  
service management, governance, and security.

Scope of Work:
The TC is engaged in developing the Symptoms Autonomic Framework  
specifications. The scope of the effort will be guided by the above  
Statement of Purpose. This effort will deliver on the following high- 
level goals:
•	Ensure that the specifications can be applied to various sources of  
event data, enabling a methodology to perform pattern matching,  
diagnostics, and analysis in order to achieve a timely and accurate  
resolution of a wide range of IT and non-IT situations.
•	An implementation agnostic architecture to support both online  
processing and offline operations.
•	The TC shall consider and work with other standards organizations,  
as agreed to by a majority of its members.
The focus of the TC specifications will be predicated on further  
development and refinement of the following contributions:

Symptoms Framework White Paper Version 1.0: http://xml.coverpages.org/SAF/SAF-WhitePaper.doc
Symptoms Autonomic Framework Specification Version 1.0: http://xml.coverpages.org/SAF/SAF-Spec-V10.doc
SAF XML Schema: Message Types: http://xml.coverpages.org/SAF/SAF-MessageTypes-V10.xsd
SAF WSDL Document: http://xml.coverpages.org/SAF/SAF-V10.wsdl
SAF XML Schema: Symptoms, Syndromes, Protocols, Prescriptions: http://xml.coverpages.org/SAF/SAF-V10.xsd

The output specifications will uphold the basic principles of other  
Web services specifications in terms of independence, composition, and  
composability with the other specifications in the Web services  
architecture, such as the specifications listed in the References  
section. Each of the elements of the symptoms information model will  
use implementation and language neutral XML formats defined in XML  
Schema [1]. The TC will not define a mapping of the functions and  
elements described in the specifications to any programming language,  
to any particular messaging middleware, nor to specific network  
transports.
In general, the goal is the further refinement of key entities and  
their schema, which are listed below in general form and semantics to  
provide structure and scope to the work of the TC. Additional entities  
and their schema may be defined, if required.

•	Symptom as an XML document that represents a dynamic state of the  
system and possibly corresponds to a Syndrome and is described by the  
Syndrome, indicating that the condition or situation is present in the  
system.
•	Syndrome as an XML document that identifies a collection of zero or  
more related and potentially relevant Symptoms and represents a  
potential positive or negative condition or situation in the system.
•	Protocol as an XML document used for the generation of appropriate  
Prescriptions with appropriate target-specific arguments.
•	Prescription as an XML document that may be generated from  
application of a Protocol. A Prescription may be used to confirm a  
potential Syndrome diagnosis (match) via the creation of validating  
Symptoms, for remediating a Syndrome, or Syndrome optimization. A  
Prescription may include arguments specific to its target.
Furthermore, the TC will continue to develop and refine the  
definitions of architectural roles that may be implemented as part of  
the Symptoms Autonomic Framework including, but not limited to, those  
listed below.
•	Syndrome and Protocol Catalog as a container for Syndromes and  
Protocols associated with the system for which that Catalogue was  
designed.
•	Symptom Store as a container for Symptoms that have been created in  
the course of operation of a Symptoms Autonomic Framework.
•	Diagnostician as the active entity that compares a set of Symptoms  
with the signatures of various Syndromes to determine if any of the  
Syndromes match the set of Symptoms.
•	Practitioner as the active entity that administers Prescriptions.
•	Case Manager to act as a general manager because other architectural  
roles. Conceptually, such an entity might conduct a host of activities  
such as keeping track of what Symptoms are currently of importance,  
directing the activities of the other architectural roles, managing  
queues of Prescriptions.
•	Catalog Source emits entities that may be stored in a Syndrome and  
Protocol Catalog.
•	Symptom Source emits entities that may be stored in a Symptom Store.


Out of Scope:
The following items are specifically out of scope of the work of the TC:
1.	Specific implementation and performance tuning details
2.	Domain specific Symptoms or Protocol catalog contents.

The TC will not attempt to define concepts or renderings for functions  
that are of wider applicability including but not limited to:
•	Addressing
•	Policy language frameworks and attachment mechanisms
•	Reliable message exchange
•	Transactions and compensation
•	Secure Conversations
•	Metadata Exchange Protocols
•	Resource Transfer protocol

Where required these functions are achieved by composition with other  
Web services specifications.
The TC will not attempt to define functionality duplicating that of  
any normatively referenced specification in the input specifications.


List of Deliverables:
The TC is targeting the first release for the middle of 2010. The  
release will include versions of the following specifications:
•	Glossary
•	Message Exchange Patterns (including interfaces)
•	The Symptoms Information Model (including definitions of  
architectural roles that may be implemented)
•	XML Schema definitions for all normative entities

Additional documents, such as a non-normative White Paper and/or a  
Primer covering the use of the Symptoms Autonomic Framework including  
scenarios and examples of message exchange in other domains (e.g. oil  
and gas industry) may also be produced at the Committee's discretion.  
The TC's intent is to pursue OASIS Standard status for all SAFTC Draft  
Specifications.
These specifications will reflect refinements, corrections or material  
technological improvements with respect to the input documents and in  
accordance with this charter.

Ratification of the above specifications as OASIS standards, including  
a brief period to address any errata will mark the end of the TC's  
lifecycle. The TC may decide to recharter when complete to continue  
maintenance activities on an ongoing basis or to create further  
substantive improvements in the specifications rather than permanently  
disband.

Exit Criteria
The TC shall define concrete exit criteria that include at least two  
independent offerings that implement and are compliant with all the  
required normative portions of the specifications and demonstrate  
interoperability and portability as appropriate. Note that these are  
minimums and that the TC is free to set more stringent criteria.

Maintenance
Once the TC has completed work on a deliverable and it has become an  
OASIS standard, the TC will enter "maintenance mode" for that  
deliverable. The purpose of maintenance mode is to provide minor  
revisions to previously adopted deliverables to clarify ambiguities,  
inconsistencies and obvious errors. Maintenance mode is not intended  
to enhance a deliverable or extend its functionality.

Ongoing TC Work
The TC shall also consider and assist in the work of other related  
OASIS TCs on an ongoing basis as agreed by the TC membership.


Specification of the IPR Mode under which the TC will operate:
This TC will operate under the "RF on Limited Terms" IPR mode as  
defined in the OASIS Intellectual Property Rights (IPR) Policy.


Audience:
The primary audience for the final output of this TC is architects  
interested in enterprise management, autonomic computing, cloud  
computing, as well as Symptoms and protocol catalog implementers.  
Business analysts interested in the automatic resolution or  
optimization of business processes and environments may also find the  
output of this TC to be of interest.


Language of the TC:
All business of the TC will be conducted in English.



Identification of Similar Works:
No similar works within OASIS TCs have been identified at this time.   
Emerging works outside of OASIS, such as Complex Event Processing  
interoperability standards being proposed within the Object Management  
Group (OMG), are in early stages of development.  The SAF TC will keep  
apprised of progress with these emerging works, but will not directly  
engage with those teams under this charter.


First Meeting Details:
The first meeting will be held via teleconference on Thursday October  
22, 2009 at 12:00 noon EST, and will be convened by Jeff Vaught of CA.  
The bridge number is 888-827-2241 (5132292435#).


Project On-going Meeting Schedule:
Meetings will be held subsequently on every Thursday at 12:00 noon EST.


Supporting Membership:
•	Paul Lipton, CA, Paul.Lipton@ca.com
•	Mike Baskey, IBM, mbaskey@us.ibm.com
•	David Snelling, Fujitsu, David.Snelling@uk.fujitsu.com
•	Abdi Salahshour, IBM, abdis@us.ibm.com
•	Alvin Black, CA, Alvin.Black@ca.com
•	Jeff Vaught, CA, Jeffrey.Vaught@ca.com
•	Vivian Lee, Fujitsu, Vivian.Li@uk.fujitsu.com


Convener:
Jeffrey Vaught, CA, Jeffrey.Vaught@ca.com


Member Section Affiliation:
The TC does not wish to affiliate with any specific OASIS Member  
Section.


References
 [1] XML Schema Part 1: Structures Second Edition, W3C  
Recommendation, October 2004
        http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
      XML Schema Part 2: Datatypes Second Edition, W3C  
Recommendation, October 2004
       http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/