Proposed OASIS S-RAMP Technical Committee
TC Proposal: SOA Repository Artifact Model and Protocol (S-RAMP)
From firstname.lastname@example.org Wed Sep 29 13:09:38 2010 Date: Wed, 29 Sep 2010 13:08:42 -0400 From: Mary McRae [email@example.com] To: firstname.lastname@example.org, email@example.com Cc: firstname.lastname@example.org Subject: Proposed Charter for OASIS S-RAMP TC Message-ID: [FABD76F7-6465-40C5-A301-7C264B75DBD6@oasis-open.org]
To OASIS Members:
A draft TC charter has been submitted to establish the OASIS SOA Repository Artifact Model and Protocol Technical Committee (below). In accordance with the OASIS TC Process Policy section 2.2: (http://www.oasis-open.org/committees/process-2009-07-30.php#formation) the proposed charter is hereby submitted for comment. The comment period shall remain open until 11:45 pm ET on 13 October 2010.
OASIS maintains a mailing list for the purpose of submitting comments on proposed TC charters. Any OASIS member may post to this list by sending email to: email@example.com. All messages will be publicly archived at: http://lists.oasis-open.org/archives/oasis-charter-discuss/. Members who wish to receive email messages posted to the 'oasis-charter-discuss' list must join the group by selecting "Join Group" on the Kavi "OASIS Charter Submission Discuss" 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' mailing list.
A telephone conference will be held among the Convenor, the OASIS TC Administrator,
those proposers who wish to attend, and other OASIS Members who wish to attend as observers, within four days of the close of the comment period. The announcement and call-in information will be noted on the OASIS Charter Submission Discuss Group Calendar.
We encourage member comment and ask that you note the name of the proposed TC (S-RAMP) in the subject line of your email message.
Mary P McRae Director, Standards Development Technical Committee Administrator OASIS: Advancing open standards for the information society email: firstname.lastname@example.org web: www.oasis-open.org twitter: @fiberartisan #oasisopen phone: 1.603.232.9090
- 1. S-RAMP TC Proposed Charter for Review
- 2. Non-Normative Information
OASIS SOA Repository Artifact Model and Protocol (S-RAMP) TC
TC Formation: Any group of at least Minimum Membership shall be authorized to begin a TC by submitting to the OASIS TC Administrator, with a copy to those listed in 2(d) and 2(e) below, the following items, written in English and provided in electronic form as plain text. No information other than these items may be included in the proposal. All items must be provided in any subsequent revision of the proposal, and must be submitted in the same manner as the original submission.
(1)(a) The name of the TC, such name not to have been previously used for an OASIS TC and not to include any trademarks or service marks not owned by OASIS. The proposed TC name is subject to TC Administrator approval and may not include any misleading or inappropriate names. The proposed name must specify any acronyms or abbreviations of the name that shall be used to refer to the TC.
OASIS SOA Repository Artifact Model and Protocol (S-RAMP) Technical Committee
(1)(b) A statement of purpose, including a definition of the problem to be solved.
In working on a Service Oriented Architecture (SOA), organizations find it useful to create a focal point for access to key artifacts. These key artifacts include data model descriptions such as XML Schema, service interface descriptions such as WSDL, and service composition descriptions (SCA Assembly), as well as other kinds of documents.
This focal point for access, hereafter referred to as a SOA repository, facilitates various activities across the life cycle of a SOA artifact, including the design, assembly, quality assurance, deployment and runtime operation of SOA based applications and business processes.
The lack of a standardized information model and interaction protocol for artifacts and their metadata residing in a SOA repository, means that customers and vendors must build customized access for each different vendor's SOA repository product. This reduces choice, flexibility and adds costs for customers when choosing tools.
The purpose of the SOA Repository Artifact Model and Protocol (S-RAMP) TC is to define a common data model for SOA repositories as well as an interaction protocol to facilitate the use of common tooling and sharing of data. The TC will define an ATOM binding which documents the syntax for interaction with a compliant repository for create, read, update, delete and query operations.
This approach to providing flexible access to SOA artifacts will facilitate interoperability and provide customers with more choices of tools that can be used to interoperate with any S-RAMP compliant SOA repository implementation.
This TC will not prescribe how specific features should be implemented within those SOA Repositories and tooling. This TC is intended to define a generic set of capabilities provided by a SOA Repository and associated SOA Repository tooling.
(1)(c) The scope of the work of the TC, which must be germane to the mission of OASIS, and which includes a definition of what is and what is not the work of the TC, and how it can be determined when the work of the TC has been completed. The scope may reference a specific contribution of existing work as a starting point, but other contributions may be made by TC Members on or after the first meeting of the TC. Such other contributions shall be considered by the TC Members on an equal basis to improve the original starting point contribution.
The TC will accept as input Version 1.0 of the S-RAMP specification  as published by HP, IBM, Software AG, and TIBCO. The specification is divided in to two logical modules, The Foundation and The Atom Binding. Documents and XML Schemas are located at http://s-ramp.org/downloads.html. The TC will also accept as input a list of issues and recommended changes from the authoring companies.
Changes to the input documents or other contributions will be accepted for consideration without any prejudice or restrictions and evaluated based on technical merit in so far as they conform to this charter.
The scope of the TC's first set of deliverables includes further refinement of the Input Documents, addressing issues raised by authoring companies, incorporating appropriate additional contributions to the TC, and addressing issues raised in the TC itself. The output of the TC is the standardization of these documents extension points, conformance targets, capabilities and concepts therein. The extensibility, capabilities and concepts are described below.
A core model, described using XML Schema with extension points; the extension points will allow to extend and reuse the core model.
Any binding(s) that are defined should use the capabilities mentioned below that facilitate some or all CRUD operations on the core model. The binding(s) will also be flexible enough to be extended to solve implementation specific issues.
Create, Read, Update and Delete operations for the concepts defined below in the concepts section.
Query of repository information based upon the repository's content and metadata, including, but not limited to XPath.
Rendering of the Artifact Type models in a form appropriate to a binding.
Declaring the S-RAMP specific extensions to the Atom Publishing Protocol. This encompasses, but is not limited to details documented in input document describing the Atom binding. Specifically, details about the addition, mutation, query, and deletion of artifacts are defined here.
The S-RAMP Atom Binding will facilitate both a coarse-grained and fine-grained interaction with the artifact type models described below. The coarse-grained interaction describes how to perform CRUD operations on an S-RAMP artifact via HTTP methods, how to create multiple artifacts via HTTP Batch, and how to retrieve artifacts via HTTP GET. The fine-grained interaction provides a hierarchicalrepresentation for a given class of metadata (relationships, properties, or classifications), and provides CRUD operations for these sections using HTTP.
Query of S-RAMP Artifacts and associated metadata via ATOM defined in the S-RAMP Atom Binding. This includes use of inline queries via HTTP GET/POST as well as use of stored queries.
Document Artifact: These are artifacts which correspond to physical documents such as WSDL Documents, XML Documents, XSD Documents and Policy Documents which have special support in S-RAMP, however any document type can be placed in the repository.
Service Implementation Model: These are special S-RAMP defined artifacts which provide a representation of the service implementation layer associated with the SOA Model.
Derived Artifact: These are artifacts which are dynamically instantiated as a consequence of publishing a document instance whose type is one that is supported with a Derived Model - Derived Artifacts provide a metamodel of the content components of a particular Document Artifact. They can not be created or deleted directly however they can be queried and relationships to them from other artifacts can be established. Derived Artifact models include: Policy Model, XSD Model, WSDL Model and SOAP/WSDL Model.
SOA Model: These artifacts provide a conceptual representation of a SOA environment. A subset of The Open Group's SOA Ontology  is used as the basis for the definition of these artifacts.
User Defined Artifact: These are artifacts defined by the user of the S-RAMP specification and as such are out of scope. However, the Artifact Type models listed above must be extensible to provide for user-defined artifacts.
Metadata: Including relationships (direct associations between artifact instances), properties (named attributes associated with an artifact instance), and classifications (artifact decorations which reference a classification system).
The following is a non-exhaustive list of capabilities, bindings and data models that may be addressed in the first deliverable, or in a subsequent time, depending on schedule constraints. Areas where the TC work might extend beyond the scope of the contributed documents include:
A core model based on RDF and OWL
Additional metadata, including properties, relationships, and classifications
Additional concepts deemed essential for supporting concepts already identified, or that are relevant to the role of a SOA Repository
Federation of data across multiple repositories
Additional bindings and data models, including REST, Web Services, BPEL, SCA, BPMN
If some function, mechanism or feature is not included in the content above, it will be deemed to be out of scope.
Once the TC has completed work on a deliverable and it has become an OASIS standard, the TC will enter "maintenance mode" for the 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.
The TC will collect issues raised against the deliverables and periodically process those issues. Issues that request or require new or enhanced functionality shall be marked as enhancement requests and set aside. Issues that result in the clarification or correction of the deliverables shall be processed. The TC shall maintain a list of these adopted clarifications and shall periodically create a new minor revision of the deliverables including these updates. Periodically, but at least once a year, the TC shall produce and vote upon a new minor revision of the deliverables.
(1)(d) A list of deliverables, with projected completion dates.
The TC has the following set of deliverables:
S-RAMP Foundation Document specification and associated XML Schema and/or RDF/OWL descriptions
S-RAMP Atom Binding Document specification and associated XML Schema and/or RDF/OWL descriptions
These two deliverables will be available end of 2011.
(1)(e) Specification of the IPR Mode under which the TC will operate.
The TC shall operate under RF on Limited Terms.
(1)(f) The anticipated audience or users of the work.
The primary audience for the final output of this TC includes SOA Repository architects, implementers and tooling vendors.
(1)(g) The language in which the TC shall conduct business.
The TC will use English as the language for conducting its operations.
Non-normative information regarding the startup of the TC
(2)(a) Identification of similar or applicable work that is being done in other OASIS TCs or by other organizations, why there is a need for another effort in this area and how this proposed TC will be different, and what level of liaison will be pursued with these other organizations.
OASIS UDDI Specification TC. The UDDI standard describes how to store and access service metadata in a Service Registry. It does not provide any protocol support for storage and access of physical documents. The SOA Repository specification is focused on publication and query of documents based upon their content and meta-data.
Reusable Asset Specification (RAS). RAS files include any work products from the software development lifecycle, such as requirements, documents, models, source code files, deployment descriptions, test cases or scripts, and so on.
The following are listed as they are specifications/standards that S-RAMP is dependent upon:
(2)(b) The date, time, and location of the first meeting, whether it will be held in person or by telephone, and who will sponsor this first meeting. The first meeting of a TC shall occur no less than 30 days after the announcement of its formation in the case of a meeting held exclusively by telephone or other electronic means, and no less than 45 days after the announcement of its formation in the case of a meeting held face-to-face (whether or not a telephone bridge is also available).
The first TC meeting will be a face to face meeting on December 14, 2010. (This date is approximately 75 days after submission to OASIS and 45 days after the OASIS Member comment period closes.)
The location of the first TC meeting will be determined prior the close of the member review period.
(2)(c) The projected on-going meeting schedule for the year following the formation of the TC, or until the projected date of the final deliverable, whichever comes first, and who will be expected to sponsor these meetings.
The S-RAMP TC will meet by telephone every other week at a Time to be determined. The time, date and recurrence of the periodic phone call will be confirmed at the first TC meeting. The meetings will last no more than two hours. The S-RAMP TC will also hold face-to-face meetings periodically. The date, time and place of the face-to-face meetings will be determined by the S-RAMP TC.
(2)(d) The names, electronic mail addresses, and membership affiliations of at least Minimum Membership who support this proposal and are committed to the Charter and projected meeting schedule.
- Chris Peltz, email@example.com, Hewlett-Packard Co.
- Dan Enache, firstname.lastname@example.org, TIBCO Software Inc
- Diane Jordan, email@example.com, IBM
- Eric Johnson, firstname.lastname@example.org, TIBCO Software Inc
- Gary Woods, Gary.Woods@SoftwareAG.com, Software AG
- John Colgrave, email@example.com, IBM
- John Favazza, firstname.lastname@example.org, WebLayers
- Jonathan Marsh, email@example.com , WSO2
- Kurt Stam, firstname.lastname@example.org, Red Hat
- Luc Clement, email@example.com, Active Endpoints
- Mark Little, firstname.lastname@example.org, Red Hat
- Martin Smithson, email@example.com, IBM
- Michael Rowley, firstname.lastname@example.org, Active Endpoints
- Miroslav Novak, email@example.com, Hewlett-Packard Co.
- Paul Fremantle, firstname.lastname@example.org, WSO2
- Pradeep Gundavarapu, Pradeep.Gundavarapu@soa.com, SOA Software
- Prasad Yendluri, Prasad.Yendluri@softwareag.com, Software AG
- Radek Pospisil, email@example.com, Hewlett-Packard Co.
- Randall Hauch, firstname.lastname@example.org, Red Hat
- Steve Fanshier, Steve.Fanshier@SoftwareAG.com, Software AG
- Vince Brunssen, email@example.com, IBM
(2)(e) For each OASIS Organizational Member listed in (2)(d), the name, electronic mail address, membership affiliation, and statement of support for the proposed Charter from the Primary Representative.
David Burke, firstname.lastname@example.org, TIBCO Software Inc
"As TIBCO Software Inc.'s Primary Representative to OASIS, I, David Burke (email@example.com) fully support the formation and activities of the S-RAMP TC under the proposed charter."
Dave Ings, firstname.lastname@example.org, IBM
"As the Primary Representative to OASIS of IBM, I approve the S-RAMP Charter."
John Favazza, email@example.com, WebLayers
"As the primary representative from WebLayers I fully support the S-RAMP charter proposal."
Paul Fremantle, firstname.lastname@example.org, WSO2
"I, Paul Fremantle, as WSO2's primary representative to OASIS, fully support the proposed S-RAMP charter."
Mark Little, email@example.com, Red Hat
"As Red Hat's Primary Representative to OASIS, I, Mark Little (firstname.lastname@example.org) fully support the formation and activities of the S-RAMP TC under the proposed charter."
Prasad Yendhuri, Prasad.Yendluri@softwareag.com, Software AG
"As OASIS Primary Representative for Software AG, I (Prasad.Yendlkuri@software.com) certify that Software AG fully supports the formation and activities of the S-RAMP TC under the proposed charter and agrees to be a co-proposer of the TC."
Chris Keller, email@example.com, Active Endpoints, Inc.
"As Active Endpoints, Inc.'s Primary Representative to OASIS, I, Christopher Keller (firstname.lastname@example.org) support the formation and activities of the S-RAMP TC under the proposed charter."
Alistair Farquharson, email@example.com, SOA Software
"I, Alistair Farquharson, (firstname.lastname@example.org), as SOA-Software's Primary Representative to OASIS, fully support the formation and activities of the S-RAMP TC under the proposed charter."
(2)(f) The name of the Convenor who must be an Eligible Person.
Chris Peltz, Hewlett-Packard Co.
(2)(g) The name of the Member Section with which the TC intends to affiliate, if any.
(2)(h) Optionally, a list of contributions of existing technical work that the proposers anticipate will be made to this TC.
 SOA Repository Artifact Model and Protocol — The Foundation Document v1.0 and corresponding XML Schema files
SOA Repository Artifact Model and Protocol — The Atom Binding Document v1.0 and corresponding XML Schema files
Available at: http://s-ramp.org/downloads.html
(2)(i) Optionally, a draft Frequently Asked Questions (FAQ) document regarding the planned scope of the TC, for posting on the TC's website.
(2)(j) Optionally, a proposed working title and acronym for the specification(s) to be developed by the TC.
SOA Repository Artifact Model and Protocol Standard
- SOA Repository Artifact Model and Protocol (S-RAMP) Web Site
- S-RAMP Frequently Asked Questions (FAQ) Document
- S-RAMP Downloads
- The Foundation Document [cache/archive, from http://s-ramp.org/2010/s-ramp/specification/documents/S-RAMP-Specification-Foundation-FINAL.pdf]
- The Atom Binding Document [cache/archive, from http://s-ramp.org/2010/s-ramp/specification/documents/S-RAMP-Specification-Atom-Binding-FINAL.pdf]
- Atom Binding Model Schema
- Core Model Schema
- Policy Model Schema
- Service Implementation Model Schema
- SOA Model Schema
- SOAP WSDL Model Schema
- WSDL Model Schema
- XSD Model Schema
- "Emerging Standards for Service Registry and Repository." IBM. April 20, 2010.
- SOA Repository Specification Technology Preview (alphaWorks)
Prepared by Robin Cover for The XML Cover Pages archive.