4.4. S-RAMP Data Models

The S-RAMP specification defines a number of built-in artifact types, while also allowing clients to define their own implicit types. This section describes these different models.
An artifact may have document (such as a file) content or it may be a purely logical artifact. In either case, clients typically add artifacts to the repository directly (for example, via the S-RAMP Atom API). Additionally, some document style artifact types when added to the repository, result in the creation of a set of derived artifacts. For example, if an XSD document is added to the repository, the server automatically extracts the element declarations from the content of the file resulting in a set of additional artifacts related to the original.

4.4.1. Core Data Model

The S-RAMP core data model defines some basic artifact types that include Document and XmlDocument. These basic types allow clients to add simple files to the repository as artifacts.

Table 4.1. S-RAMP Core Data Model

Artifact Type Parent Type Properties
Document   contentType, contentSize, contentHash
XmlDocument Document contentEncoding

4.4.2. XML Schema Data Model

The XSD model defines a single document style artifact, XsdDocument, and a number of derived artifact types. When an XSD document is added to the repository, the server additionally indexes the artifact by automatically creating a number of derived artifacts of the following types from the XSD content:

Table 4.2. S-RAMP XML Schema Data Model

Artifact Type Parent Type Properties
XsdDocument XmlDocument targetNamespace
AttributeDeclaration <derived> ncName, namespace
ElementDeclaration <derived> ncName, namespace
SimpleTypeDeclaration <derived> ncName, namespace
ComplexTypeDeclaration <derived> ncName, namespace

4.4.3. WSDL Data Model

The WSDL model defines a single document style artifact called WsdlDocument, and a number of derived artifact types. Similar to the XsdDocument type, when you add a WSDL document to the repository, the server automatically derives additional artifacts from the content of the WSDL file. Here is the list of these artifacts:

Table 4.3. WSDL Artifacts

Artifact Type Parent Type Properties
WsdlDocument XmlDocument targetNamespace, xsdTargetNamespaces
WsdlService <derived> ncName, namespace
Port <derived> ncName, namespace
WsdlExtension <derived> ncName, namespace
Part <derived> ncName, namespace
Message <derived> ncName, namespace
Fault <derived> ncName, namespace
PortType <derived> ncName, namespace
Operation <derived> ncName, namespace
OperationInput <derived> ncName, namespace
OperationOutput <derived> ncName, namespace
Binding <derived> ncName, namespace
BindingOperation <derived> ncName, namespace
BindingOperationInput <derived> ncName, namespace
BindingOperationOutput <derived> ncName, namespace
BindingOperationFault <derived> ncName, namespace

4.4.4. Policy Data Model

The Policy Data Model represents the primary components of a WS-Policy document. Here is the list of artifacts for Policy Data Model:

Table 4.4. Policy Data Model Artifacts

Artifact Type Parent Type
PolicyDocument XmlDocument
PolicyExpression <derived>
PolicyAttachment <derived>

4.4.5. SOA Data Model

The SOA model provides a link to the work done by the Open Group SOA Ontology group. All of the artifacts in this model are non-document artifacts that are directly instantiated by clients.

Table 4.5. SOA Data Model Artifacts

Artifact Type
HumanActor
Choreography
ChoreographyProcess
Collaboration
CollaborationProcess
Composition
Effect
Element
Event
InformationType
Orchestration
OrchestrationProcess
Policy
PolicySubject
Process
Service
ServiceContract
ServiceComposition
ServiceInterface
System
Task

4.4.6. Service Implementation Data Model

The Service Implementation model adds SOA service implementation artifact types under the SOA Data Model.

Table 4.6. Service Implementation Data Model Artifacts

Artifact Type Properties
Organization end
ServiceEndpoint end, url
ServiceInstance end, url
ServiceOperation end, url

4.4.7. Custom or Extension Data Models

Clients can define their own implicit data models by using the ext model space defined by the S-RAMP specification. This allows clients to add documents with custom artifact types. For example, a client can add an artifact to /s-ramp/ext/PdfDocument. This provides a way for clients to define their own data models with their own properties and relationships. Note that the server does not have a definition of the model and it is up to the client to properly conform to their own implicit model. Custom properties and user-defined relationships allow clients to richly define their own models.
Here is an example where a client defines the following Data Model for a J2EE web application domain:

Table 4.7. Custom/Extension Data Models Artifacts

Artifact Type Parent Type Properties
WebXmlDocument ExtendedDocument displayName
ServletFilter ExtendedArtifactType displayName, filterClass
Servlet ExtendedArtifactType servletClass, loadOnStartup