[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: FW: [members] Call for Participation: OASIS OASIS Symptoms Autonomic Framework (SAF) TC
This strikes me as a generic tool for analysis of information reported
from the operation of a system, and consequently complementary to PLCS.
Anyone else looked at it?
Howard Mason
Corporate IT Office
Tel: +44 1252 383129
Mob: +44 780 171 3340
Eml: howard.mason@baesystems.com
BAE Systems plc
Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK
Registered in England & Wales No: 1470151
-----Original Message-----
From: Mary McRae [mailto:mary.mcrae@oasis-open.org]
Sent: 18 September 2009 20:51
To: tc-announce@lists.oasis-open.org; members@lists.oasis-open.org
Subject: [members] Call for Participation: OASIS OASIS Symptoms
Autonomic Framework (SAF) TC
*** WARNING ***
This message has originated outside your organisation,
either from an external partner or the Global Internet.
Keep this in mind if you answer this message.
To: OASIS members & interested parties
A new OASIS technical committee is being formed. The OASIS Symptoms
Autonomic Framework (SAF) Technical Committee has been proposed by the
members of OASIS listed below. The TC name, statement of purpose, scope,
list of deliverables, audience, and language specified in the proposal
will constitute the TC's official charter. Submissions of technology for
consideration by the TC, and the beginning of technical discussions, may
occur no sooner than the TC's first meeting.
The eligibility requirements for becoming a participant in the TC at
the first meeting are:
(a) you must be an employee of an OASIS member organization or an
individual member of OASIS, and
(b) you must join the Technical Committee, which members may do by
using the "Join this TC" button on the TC's home page at [c].
To be considered a voting member at the first meeting, you must:
(a) join the Technical Committee at least 15/7 days prior to the
first meeting (15 October); and
(b) you must attend the first meeting of the TC, at the time and date
fixed below (22 October).
Of course, participants also may join the TC at a later time. OASIS and
the TC welcomes all interested parties.
Non-OASIS members who wish to participate may contact us about
joining OASIS [b]. In addition, the public may access the information
resources maintained for each TC: a mail list archive, document
repository and public comments facility, which will be linked from the
TC's public home page at [c].
Please feel free to forward this announcement to any other
appropriate lists. OASIS is an open standards organization; we encourage
your participation.
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
[a] http://www.oasis-open.org/apps/org/workgroup/saf/
[b] See http://www.oasis-open.org/join/
[c] http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=saf
---------------------------------------------------
CALL FOR PARTICIPATION
OASIS Symptoms Autonomic Framework (SAF) TC
Name
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. 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 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
It is anticipated that official contributions to the OASIS SAF TC will
be made in accordance with the TC Process; documents listed above are
unofficial, intended as display copies for informational purposes only.
The output specifications will uphold the basic principles of
specifications in terms of independence and composition. 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.
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.
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.
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.
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.
Non-Normative Information:
Identification of Similar and Complementary Works:
While similar works have not been identified within OASIS TCs,
complementary work is being pursued as follows:
* OASIS Emergency Management TC - SAF could be used to detect
inadequate emergency response capabilities.
* OASIS Energy Management TC - SAF could be used to detect early
indicators of supply & demand mis-matches.
* OASIS Open Building Information Exchange - SAF could be used to
detect building control system failures.
* OASIS SOA-End-to-End Resource Planning TC- SAF could be used in the
optimization of service deployment.
Outside of OASIS, some work is emerging, such as the Complex Event
Processing interoperability standards being proposed within the OMG, the
DMTF Common Diagnostic Model, and various working groups within the
Event Processing Technical Society.
The SAF TC plans to directly engage the complementary OASIS TCs listed
above, and will keep apprised of progress within the other SDOs and
organizations.
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:
The membership supporting this proposal is as follows:
* Paul Lipton, CA, OASIS member, Paul.Lipton@ca.com
* Mike Baskey, IBM, OASIS member, mbaskey@us.ibm.com
* David Snelling, Fujitsu, OASIS member, David.Snelling@uk.fujitsu.com
* Abdi Salahshour, IBM, OASIS membership in-progress, abdis@us.ibm.com
* Alvin Black, CA, OASIS membership in-progress, Alvin.Black@ca.com
* Jeff Vaught, CA, OASIS member, Jeffrey.Vaught@ca.com
* Vivian Lee, Fujitsu, OASIS membership in-progress,
Vivian.Li@uk.fujitsu.com
Convener:
Jeffrey Vaught, CA, OASIS member, Jeffrey.Vaught@ca.com
Member Section Affiliation:
The TC does not intend to affiliate with any OASIS Member Section at
this time.
Initial 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
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/
---------------------------------------------------------------------
This email list is used solely by OASIS for official consortium
communications.
Opt-out requests may be sent to member-services@oasis-open.org, however,
all members are strongly encouraged to maintain a subscription to this
list.
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]