OASIS SOA Repository Artifact Model and Protocol (S-RAMP) Technical Committee

The official charter for this Technical Committee is provided below. (For additional information, see the Call for Participation that was issued when this TC was formed.)

  1. The Name of the TC:

    OASIS SOA Repository Artifact Model and Protocol (S-RAMP) Technical Committee

  2. 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 an SOA repository, facilitates various activities across the life cycle of an 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 an SOA repository, means that customers and vendors must build customized access for each different vendor's SOA repository product. This reduces choice and 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 an SOA Repository and associated SOA Repository tooling.

  3. The scope of the work of the TC:

    The TC will accept as input Version 1.0 of the S-RAMP specification [1] as published by HP, IBM, Software AG and TIBCO. The specification is divided into 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.

    Extensibility:

    1. A core model, described using XML Schema with extension points; the extension points will allow to extend and reuse the core model.
    2. Any binding(s) 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.

    Capabilities:

    1. Create, Read, Update and Delete operations for the concepts defined below in the concepts section.
    2. Query of repository information based upon the repository's content and metadata, including, but not limited to XPath.
    3. Rendering of the Artifact Type models in a form appropriate to a binding.
    4. Declaring the S-RAMP specific extensions to the Atom Publishing Protocol. This encompasses, but is not limited to, details documented in the input document describing the Atom binding. Specifically, details about the addition, mutation, query, and deletion of artifacts are defined here.
    5. The S-RAMP Atom Binding will facilitate both coarse-grained and fine-grained interactions 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 hierarchical representation for a given class of metadata (relationships, properties, or classifications), and provides CRUD operations for these sections using HTTP.
    6. 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.

    Concepts:

    1. 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.
    2. Service Implementation Model - These are special S-RAMP-defined artifacts which provide a representation of the service implementation layer associated with the SOA Model.
    3. 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 cannot 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.
    4. SOA Model - These artifacts provide a conceptual representation of an SOA environment. A subset of The Open Group's SOA Ontology [2] is used as the basis for the definition of these artifacts.
    5. 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.
    6. 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 at a subsequent time, depending on schedule constraints. Areas where the TC work might extend beyond the scope of the contributed documents include:

    • Alternate means of query beyond XPath 1.0, such as XPath 2.0 and XQuery.
    • 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 an 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.

    Maintenance

    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.

  4. 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 at the end of 2011.

  5. IPR Mode

    The TC shall operate under RF on Limited Terms.

  6. Anticipated Audience

    The primary audience for the final output of this TC includes SOA Repository architects, implementers and tooling vendors.

  7. Language

    The TC will use English as the language for conducting its operations.

 

TOP OF PAGE