SOA Repository Artifact Model and Protocol (S-RAMP) is supported by a Technical Committee at OASIS. It is a specification of SOA repository that provides a common data model and protocol for interacting with a repository of SOA artifacts. For more information, see https://www.oasis-open.org/committees/s-ramp/charter.php.
S-RAMP supports interoperability between repository implementations by standardizing on a data model and API. The S-RAMP specification includes the following:
A foundation document that describes the core concepts.
An Atom based protocol binding document that describes an Atom based API.
An S-RAMP repository primarily stores artifacts. An artifact comprises of the following metadata:
This chapter discusses the S-RAMP concepts, implementation, and Integration. To help you understand them better, we ship the following working examples, which are installed at jboss-eap-6.1/quickstarts/sramp:
By default S-RAMP uses the standard EAP Application Realm configuration as its authentication source. This means that adding users is a simple matter of using the existing EAP add-user script. If you are running on Windows you can use the add-user.bat script. Otherwise run the add-user.sh script. Both of these scripts can be found in EAP's bin directory.
Here is an example of how to add an S-RAMP user using the add-user.sh script:
[user@host jboss-eap-6.1]$ pwd
/home/user/FSW6/jboss-eap-6.1
[user@host jboss-eap-6.1]$ ./bin/add-user.sh
What type of user do you wish to add?
a) Management User (mgmt-users.properties)
b) Application User (application-users.properties)
(a): b
Enter the details of the new user to add.
Realm (ApplicationRealm) : ApplicationRealm
Username : fitzuser
Password : P4SSW0RD!
Re-enter Password : P4SSW0RD!
What roles do you want this user to belong to? (Please enter a comma separated list, or leave blank for none)[ ]: overlorduser,admin.sramp
About to add user 'fitzuser' for realm 'ApplicationRealm'
Is this correct yes/no? yes
Added user 'fitzuser' to file '/home/user/FSW6/jboss-eap-6.1/standalone/configuration/application-users.properties'
Added user 'fitzuser' to file '/home/user/FSW6/jboss-eap-6.1/domain/configuration/application-users.properties'
Added user 'fitzuser' with roles overlorduser,admin.sramp to file '/home/user/FSW6/jboss-eap-6.1/standalone/configuration/application-roles.properties'
Added user 'fitzuser' with roles overlorduser,admin.sramp to file '/home/user/FSW6/jboss-eap-6.1/domain/configuration/application-roles.properties'
Is this new user going to be used for one AS process to connect to another AS process?
e.g. for a slave host controller connecting to the master or for a Remoting connection for server to server EJB calls.
yes/no? no
Required Roles
TThere are several roles that the user must have in order to interact with the S-RAMP repository. These roles are as follows:
overlorduser : users must have this role in order to access the S-RAMP user interface (browser)
admin.sramp : users must have this role in order to access the S-RAMP repository (both read and write)
Note
If you change the S-RAMP repository name in the standalone.xml file and set the new repository name in standalone/configuration/sramp.properties (under sramp.config.jcr.repository.jndi-path), make sure you modify the user's roles. If the role that grants users access to the ModeShape repository is admin.sramp, where the ModeShape role is admin on repository named sramp, ensure you change this value to admin.<new repository name> in the application-roles.properties file.
All artifacts in S-RAMP contain a set of core properties such as name, description, and creation date. The server automatically sets many of these properties when the artifact is added or updated. Other properties such as description are set by clients. Every artifact has an Artifact Model and an Artifact Type. These two properties determine what kind of artifact it is.
Some artifact types contain additional core properties. For example, the Document artifact type includes additional core properties of contentType and contentSize, while the XsdDocument artifact type includes the targetNamespace property.
Note
We support only the S-RAMP shell and user interface that are shipped with JBoss Enterprise SOA Platform 6, however you can use your own custom clients.
In addition to the core properties, an artifact may have additional properties called the custom properties set on it by clients. These custom properties are arbitrary name-value pairs. A custom property may not have the same name as a core property.
An ontology is a hierarchy of tags defined as a subset of the OWL Lite language. A classifier is a node in an ontology that is previously uploaded to the repository. Classifiers are like keywords or tags except that they are hierarchical. Every artifact has a collection of classifiers configured by the client.
Here is an example of how you can configure the repository with a pre-defined set of hierarchical tags (classifiers) that can be associated with an artifact:
Consider a case where a repository administrator defines and uploads the following ontology:
World
|-> North America
|-> United States
|-> Alabama
|-> Alaska
|-> Mexico
|-> Canada
|-> South America
|-> Australia
Once this ontology is added to the repository, the clients can add classifiers such as #Alaska or #Canada on artifacts. This provides a way to tag artifacts in interesting and meaningful ways, and a useful means of querying.
An S-RAMP relationship is a uni-directional link between a source artifact and a target artifact. Artifacts can have arbitrary, client-defined relationships. Every relationship has a name and a target artifact. For example, a client may define a relationship with name "documentedBy" between a wsdl artifact and a text or PDF artifact, indicating that the latter provides documentation for the former.
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.
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.
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:
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:
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.
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:
S-RAMP defines a query language that allows clients to search artifacts by various criteria. The S-RAMP query language is a subset of the XPath 2.0 language, designed specifically to find and select S-RAMP artifacts.
The query language allows clients to search artifacts based on any of the following artifact meta-data:
Core Properties
Custom Properties
Classifiers
Relationships
Here is a basic structure of a typical S-RAMP query:
Artifacts related to any PortType artifact named OrderServicePT via a relationship named operation. This effectively returns all of the order service port type operations.
All WSDL Operation elements whose names start with submit.
Note
Use single quotes for query arguments and double quotes to surround the query on execution.
For example,
s-ramp> s-ramp:query "/s-ramp/xsd/XsdDocument[@name='core.xsd' and @version='1.0']"
Note
Single quotes in function arguments must be escaped using the backslash character, \. For example, in the xp2:matches(@name,\'submit.*\') function call, you must use \'submit.*\' instead of 'submit.*'.
This section describes the API for REST clients that are written by the users. These are different than the S-RAMP shell and user interface shipped with JBoss Enterprise SOA Platform 6.
The S-RAMP specification outlines a data model and protocol that define how a repository should store and manipulate artifacts. The S-RAMP specification does not dictate the format of the Atom REST endpoints. Instead, the client is expected to query a service document endpoint and inspect it to find the various relevant endpoints. The specification does present a notional format, but implementations are not required to follow it. In general, the Atom API data models are used to wrap custom S-RAMP specific XML structures.
Atom Entry documents are used when dealing with individual artifacts.
The Atom entry document is the Atom representation of an S-RAMP artifact object. There are two Atom representations of an S-RAMP artifact object:
A summary Atom entry that appears in an Atom feed document. Summary entries do not include the S-RAMP structured extension element (S-RAMP foreign markup).
A complete Atom entry which includes the S-RAMP structured extension element.
A feed in S-RAMP is XML data which contains Atom entries. S-RAMP defines several Atom feeds which are used to access fine-grained support for relationships.
An Atom Feed Document is a representation of an Atom feed. It includes metadata about the feed, and the entries associated with it. Use Atom Feed documents when dealing with lists of documents.
From the protocol standpoint, S-RAMP provides two types of artifacts:
Document Style Artifacts
These artifacts are based on files or binary content. For the document style artifacts, the client must POST the binary content to the correct Atom Endpoint.
Logical Artifacts
These artifacts are direct instantiation artifacts. For the logical artifacts, there is no document content and the client must POST an Atom Entry containing an S-RAMP artifact XML entity to the appropriate endpoint. If successful, the server responds with an Atom Entry containing the full meta data of the newly created artifact.
You can add one of these artifacts using the POST request as shown below:
A client can update the artifact metadata such as properties, classifiers, and relationships. You can update artifacts using the PUT request as shown below to the endpoint of an artifact:
PUT /s-ramp/{model}/{type}/{uuid}
You can find the endpoint of an artifact either by querying for the artifact or as part of the Atom Entry returned when the artifact was created.
Running an S-RAMP query means issuing a GET or POST to the S-RAMP query endpoint. S-RAMP provides full feed for all Artifact Models and Artifact Types. In both the cases, the response is an Atom Feed where each Entry provides summary information about an artifact in the respository.
Only a subset of the core properties, such as name and description, are mapped to the Atom Entry in a feed. To retrieve full details such as custom properties, classifiers, and relationships about a given entry in a feed, the client must issue an additional GET request.
In order to retrieve the full metadata for an artifact, the client must issue a GET request to the appropriate artifact endpoint as shown below:
GET /s-ramp/{model}/{type}/{uuid}
This is necessary after a query or feed, when only the summary information is available. The summary information found in a feed or query response contains the UUID of the artifact, as well as a URL to the endpoint needed to retrieve the full artifact details.
The batch processing function is a powerful additional feature of the S-RAMP API. The batch processing endpoint allows the client to POST an S-RAMP package, which can contain multiple Atom Entries and binary files. The package allows a client to add, update, and delete multiple artifacts in a single batch.
The S-RAMP implementation strives to be a fully compliant reference implementation of the S-RAMP specification. This chapter describes the overall architecture of the implementation and also provides some information about how to configure it.
S-RAMP also provides a Java based client library that consumers can use to integrate their own applications with an S-RAMP compliant server.
The server implementation is a conventional Java web application (WAR). The following technologies are used to provide the various components that make up the server implementation:
JCR (ModeShape): Used as the persistence engine, where all S-RAMP data is stored. Artifacts and ontologies are both stored as nodes in a JCR tree. All S-RAMP queries are mapped to JCRSQL2 queries for processing by the JCR API. The ModeShape JCR implementation is used by default. However, the persistence layer is pluggable allowing alternative providers to be implemented in the future.
AX-RS (RESTEasy): Used to provide the S-RAMP Atom based REST API. The S-RAMP specification documents an Atom based REST API that implementations must make available. The S-RAMP implementation uses JAX-RS (specifically RESTEasy) to expose all of the REST endpoints defined by the specification.
JAXB: Used to expose a Java data model based on the S-RAMP data structures defined by the specification (S-RAMP XSD schemas).
You can configure the server by providing a configuration file to the server on startup. You can provide the configuration file in a number of ways:
sramp.properties: You can provide this external file in the JBoss application server's configuration directory. An alternative location is the home directory of the user running the application server.
custom external file: You can specify a custom location for the sramp.properties file by starting the application server with the sramp.config.file.name system property set. This is typically done using -Dsramp.config.file.name=<pathToFile> on the application server's command line startup script (often in JAVA_OPTS).
On the classpath: If no external file is found, you can use the classpath to lookup a default configuration.
The configuration file is a simple Java properties file, with the following properties available to be set:
# The base URL of the S-RAMP server - can be useful in some advanced configurations where
# the incoming Request URL is not the canonical server address.
sramp.config.baseurl = http://host:port/context
# Turn on/off auditing of changes to S-RAMP artifacts
sramp.config.auditing.enabled = true
# Turn on/off auditing of changes to derived S-RAMP artifacts
sramp.config.auditing.enabled-derived = true
Part of the S-RAMP specification is the concept of Derived content. This happens when an artifact of a certain type is added to the S-RAMP repository. The server is responsible for creating relevant derived artifacts from it. For example, when an XML Schema (XSD) document is added to the repository, the server is responsible for automatically creating an artifact for every top level Element, Complex Type, Simple Type, and Attribute declaration found in the XSD.
The S-RAMP implementation includes Artifact Derivers for all of the logical models defined by the S-RAMP specification (such as WSDL, XSD, Policy). However, it also provides a mechanism that allows users to provide Artifact Derivers for their own artifact types. This is done by performing the following steps:
Procedure 4.1. Task
Write a custom Deriver Java class. It must implement ArtifactDeriver.
Create a DeriverProvider (a class that implements DeriverProvider) used to map artifact types to implementations of ArtifactDeriver.
Provide a text file named org.overlord.sramp.common.derived.DeriverProvider in the location META-INF/services. The content of this file must be a single line containing the fully qualified classname of the class defined in the previous step.
Package everything into a JAR and make it available either on the classpath or in an external directory. Configure the external directory by setting property sramp.derivers.customDir.
The S-RAMP Client Library is a Java client library implementing the S-RAMP Atom API. Other items in the list use the S-RAMP Client Library when connecting to the S-RAMP repository. This section describes how to use the S-RAMP Client Library.
Once the library is included in your project, you can use the client by instantiating the SrampAtomApiClient class. Note that the client class supports pluggable authentication mechanisms, although BASIC auth is just a matter of including the username and password upon construction of the client. For details, refer to the javadoc of the required class. Here are some usage examples to help you get started:
Upload an XSD document to S-RAMP
SrampAtomApiClient client = new SrampAtomApiClient(urlToSramp);
String artifactFileName = getXSDArtifactName();
InputStream is = getXSDArtifactContentStream();
ArtifactType type = ArtifactType.XsdDocument();
BaseArtifactType artifact = client.uploadArtifact(ArtifactType.XsdDocument(), is, artifactFileName);
Create a custom artifact in S-RAMP (meta-data only, no file content)
SrampAtomApiClient client = new SrampAtomApiClient(urlToSramp);
ExtendedArtifactType artifact = new ExtendedArtifactType();
artifact.setArtifactType(BaseArtifactEnum.EXTENDED_ARTIFACT_TYPE);
artifact.setExtendedType("MyArtifactType");
artifact.setName("My Test Artifact #1");
artifact.setDescription("Description of my test artifact.");
BaseArtifactType createdArtifact = client.createArtifact(artifact);
Retrieve full meta-data for an XSD artifact by its UUID
The S-RAMP implementation provides an extension to the Atom based REST API to support management of ontologies. You can use any of the client's ontology related methods when communicating with the implementation of S-RAMP, however it is likely to fail when communicating with any other S-RAMP server. The S-RAMP client supports adding, updating, and getting (both individual and a full list) ontologies from the S-RAMP repository.
A special feature of the S-RAMP client is the ability to automatically expand archive style artifacts (artifacts that are JARs, WARs, ZIPs, etc). This feature is similar to how the server creates Derived content. The result is that certain files from the archive being uploaded as an S-RAMP artifact are extracted from the archive and also uploaded to the server. When this happens, these expanded artifacts are added with an S-RAMP relationship (expandedFromDocument) that points to the archive artifact they were expanded from.
The S-RAMP implementation comes with a few built-in expanders (such as, java archive and SwitchYard archive). Additionally, custom expanders can be created and provided by implementing ZipToSrampArchiveProvider. In order to inform the S-RAMP client about the custom provider, you need to put it in a JAR along with a file named META-INF/services/org.overlord.sramp.atom.archive.expand.registry.ZipToSrampArchiveProvider. The contents of this file must be a single line with the fully qualified Java classname of the provider implementation.
The S-RAMP Atom API protocol binding does not dictate the format of the API endpoints. Clients request the /servicedocument and to inspect the workspaces inside it. However, the implementations endpoints conform to the notional syntax described in the S-RAMP specifications foundation document. The following table lists the endpoints available in the Red Hat JBoss Governance implementation:
Expand
Table 4.11. Implementation Endpoints
Endpoint
Name
GET /s-ramp/servicedocument
Get Service Document
POST /s-ramp/{model}/{type}
Publish Artifact
PUT /s-ramp/{model}/{type}/{uuid}
Update Artifact
PUT /s-ramp/{model}/{type}/{uuid}/media
Update Artifact Content
GET /s-ramp/{model}/{type}/{uuid}
Get Artifact
GET /s-ramp/{model}/{type}/{uuid}/media
Get Artifact Content
DELETE /s-ramp/{model}/{type}/{uuid}
Delete Artifact
GET /s-ramp/{model}
Get Artifact Feed (by model)
GET /s-ramp/{model}/{type}
Get Artifact Feed (by type)
GET /s-ramp
Query
POST /s-ramp
Query
POST /s-ramp
Batch Processing
POST /s-ramp/ontology
Add Ontology
GET /s-ramp/ontology
List Ontologies
PUT /s-ramp/ontology/{uuid}
Update Ontology
GET /s-ramp/ontology/{uuid}
Get Ontology
DELETE /s-ramp/ontology/{uuid}
Delete Ontology
GET /s-ramp/audit/artifact/{artifactUuid}
Get Artifact Audit History
GET /s-ramp/audit/user/{username}
Get User Audit History
POST /s-ramp/audit/artifact/{artifactUuid}
Add Artifact Audit Entry
GET /s-ramp/audit/artifact/{artifactUuid}/{auditEntryUuid}
The Get Service Document API (/s-ramp/servicedocument) retrieves the service document. The service document contains a workspace for each of the S-RAMP data models supported by the server.
This example only includes the Core data model and thus the service document has a single workspace. The full service document has multiple workspaces, one for each data model supported by the server.
The Publish Artifact API publishes a new artifact into the repository. You can invoke this endpoint in the following ways, depending on the type of artifact being published:
To publish a non-document style artifact, you require an Atom Entry that contains an s-ramp:artifact child element, to be POSTed to the appropriate endpoint. The appropriate endpoint is based on the desired artifact model and type.
/s-ramp/{model}/{type}
Expand
Table 4.14. Post Method Response for Non-Document Style Artifact
To publish an artifact and update its meta-data in a single request, you can POST a multipart or related request to the server at the appropriate endpoint. The first part in the request must be an Atom Entry containing the meta-data being set, while the second part must be the binary content. The appropriate endpoint is based on the desired artifact model and type.
/s-ramp/{model}/{type}
Expand
Table 4.15. Post Method Response for Document Style Artifact with Meta-Data
HTTP Method
Request
Response
POST
Multipart/Related
Atom Entry
Example Request:
POST /s-ramp/core/Document HTTP/1.1
Content-Type: multipart/related;boundary="===============1605871705==";
type="application/atom+xml"
MIME-Version: 1.0
--===============1605871705==
Content-Type: application/atom+xml; charset="utf-8"
MIME-Version: 1.0
<?xml version="1.0"?>
<entry xmlns="http://www.w3.org/2005/Atom"
xmlns:s-ramp="http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0">
<title type="text">myfile.txt</title>
<summary type="text">The description of my text file.</summary>
<category term="Document" label="Document"
scheme="urn:x-s-ramp:2013urn:x-s-ramp:2013:type" />
<s-ramp:artifact xmlns:s-ramp="http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<s-ramp:Document name="myfile.txt" version="1.0"
description="The description of my text file." >
<s-ramp:classifiedBy>
http://example.org/ontologies/regions.owl/Maine
</s-ramp:classifiedBy>
<s-ramp:property>
<propertyName>foo</propertyName>
<propertyValue>pity him</propertyValue>
</s-ramp:property>
</s-ramp:Document>
</s-ramp:artifact>
</entry>
--===============1605871705==
Content-Type: application/xml
MIME-Version: 1.0
This is a simple text document, uploaded as an artifact
into S-RAMP.
--===============1605871705==--
The Update Artifact API (/s-ramp/{model}/{type}/{uuid}) updates an artifact's meta data.This endpoint is used to update a single artifact's meta data, including core properties, custom properties, classifiers, and relationships. Typically the client first retrieves the artifact (for example, by invoking the Get Artifact endpoint), makes changes to the artifact, and then issues a PUT request to the Update Artifact endpoint.
Expand
Table 4.16. PUT Method Request for Update Artifact
HTTP Method
Request
Response
PUT
Atom Entry
N/A
Example Request:
PUT /s-ramp/core/Document/098da465-2eae-49b7-8857-eb447f03ac02 HTTP/1.1
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<atom:entry xmlns:s-ramp="http://docs.oasis-open.org/s-ramp/ns/s-ramp-v1.0" xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:atom="http://www.w3.org/2005/Atom">
<atom:title>pom.xml</atom:title>
<atom:updated>2013-05-15T08:12:01.985-04:00</atom:updated>
<atom:id>098da465-2eae-49b7-8857-eb447f03ac02</atom:id>
<atom:published>2013-05-15T08:12:01.985-04:00</atom:published>
<atom:author>
<atom:name>ewittman</atom:name>
</atom:author>
<atom:summary>Sample description of my document.</atom:summary>
<s-ramp:artifact>
<s-ramp:Document contentType="text/plain" contentSize="4748" artifactType="Document"
name="myfile.txt" description="Sample description of my document." createdBy="ewittman"
uuid="098da465-2eae-49b7-8857-eb447f03ac02" createdTimestamp="2013-05-15T08:12:01.985-04:00"
lastModifiedTimestamp="2013-05-15T08:12:01.985-04:00" lastModifiedBy="ewittman">
<s-ramp:property>
<s-ramp:propertyName>foo</s-ramp:propertyName>
<s-ramp:propertyValue>bar</s-ramp:propertyValue>
</s-ramp:property>
</s-ramp:Document>
</s-ramp:artifact>
</atom:entry>
The Update Artifact Content API (/s-ramp/{model}/{type}/{uuid}/media) updates an artifact's content.
This endpoint is used to update a single artifact's content, regardless if the artifact is a text document or some sort of binary. The body of the request must be the new binary content of the artifact.
Expand
Table 4.17. PUT Method Request for Update Artifact Content
HTTP Method
Request
Response
PUT
Binary Content
N/A
Example Response:
PUT /s-ramp/core/Document/0f6f9b6b-9952-4059-ab70-7ee3442ddcf0/media HTTP/1.1
The Get Artifact API (/s-ramp/{model}/{type}/{uuid}) retrieves an artifact's meta data.
This endpoint is used to retrieve the full meta-data for a single artifact in the repository. The data is returned wrapped up in an Atom Entry document. The Atom Entry contains an extended XML element containing the S-RAMP artifact data.
Expand
Table 4.18. GET Method Response for Get Artifact
HTTP Method
Request
Response
Get
N/A
Atom Entry (full)
Example Request:
PUT /s-ramp/xsd/ComplexTypeDeclaration/0104e848-fe91-4d93-a307-fb69ec9fd638 HTTP/1.1
The Get Artifact Content API (/s-ramp/{model}/{type}/{uuid}/media) retrieves an artifact's content.
This endpoint is used to retrieve the full content of a single artifact in the repository. If the artifact is not a Document style artifact, this call fails. Otherwise, it returns the full artifact content. For example, if the artifact is a PdfDocument, then this call returns the PDF file.
Expand
Table 4.19. Get Method Response for Get Artifact Content
HTTP Method
Request
Response
Get
N/A
Binary artifact content
Example Request:
GET /s-ramp/core/Document/0f6f9b6b-9952-4059-ab70-7ee3442ddcf0/media HTTP/1.1
The Delete Artifact API (/s-ramp/{model}/{type}/{uuid}) deletes an artifact.
This endpoint is used to delete a single artifact from the repository. If the artifact does not exist or is a derived artifact, then this fails. This may also fail if other artifacts have relationships with it. Otherwise, this artifact and all of it's derived artifacts are deleted.
The Get Artifact Feed (by model) API (/s-ramp/{model})retrieves an Atom feed of all artifacts in a given model.
This endpoint is used to retrieve an Atom feed of all artifacts in a single S-RAMP model. The feed contains Atom summary Entries, one for each artifact in the feed. Standard paging options apply.
Expand
Table 4.21. GET Method Response for Get Artifact Feed by Model
The Get Artifact Feed (by type) API (/s-ramp/{model}/{type})retrieves an Atom feed of all artifacts of a specific type.
This endpoint is used to retrieve an Atom feed of all artifacts of a specific S-RAMP type. The feed contains Atom summary Entries, one for each artifact in the feed. Standard paging options (as query params) apply.
Expand
Table 4.22. GET Method Response for Get Artifact Feed by Model
The Query API (/s-ramp) performs an S-RAMP query and returns an Atom feed containing the matching artifacts.
This endpoint is used to perform an S-RAMP query and return an Atom Feed of the results. Ordering and paging is supported. The query and other parameters are passed as query params in the request. The feed contains Atom summary Entries, one for each artifact in the feed.
Expand
Table 4.23. GET and POST Methods Request and Response for Query
The Batch Processing API (/s-ramp) performs an S-RAMP query and returns an Atom feed containing the matching artifacts.
This endpoint is used to perform an S-RAMP query and return an Atom Feed of the results. Ordering and paging is supported. The query and other parameters are passed as form data params in the request body. The feed contains Atom summary Entries, one for each artifact in the feed.
Expand
Table 4.24. POST Method Request and Response for Batch Processing
The Add Ontology API (/s-ramp/ontology) adds a new ontology (*.owl file) to the repository. This allows artifacts to be classified using the classes defined in the ontology.
This endpoint is used to add an ontology to the repository. The body of the request must be the OWL Lite formatted ontology (see the S-RAMP specification for more details). The response is an Atom Entry containing meta-data about the ontology, most importantly the UUID of the ontology (which can be later used to update or delete it).
Expand
Table 4.25. POST Method Request Response for Add Ontology
The List Ontologies API (/s-ramp/ontology) retrieves all ontologies currently known to the repository as an Atom feed.
This endpoint is used to retrieve all ontologies known to the repository as an Atom Feed of Entries, with one Entry for each ontology. You can subsequently retrieve full information about the ontology by calling the Get Ontology endpoint.
Expand
Table 4.26. GET Method Response for List Ontologies
The Update Ontologies API (/s-ramp/ontology/{uuid}) updates an existing ontology by its UUID.
This endpoint is used to update a single ontology in the repository. The request body must be a new version of the ontology in OWL Lite RDF format. Note that, this might fail if the ontology changes in an incompatible way (for example, a class is removed that is currently in use).
Expand
Table 4.27. PUT Method Request for Update Ontology
Get Ontology API (/s-ramp/ontology/{uuid}) returns the OWL representation of an ontology (wrapped in an Atom Entry).
This endpoint is used to get the full ontology (by its UUID) in OWL Lite (RDF) format, wrapped in an Atom Entry. The response body is an Atom Entry with a single extension element that is the ontology RDF. This fails if no ontology exists with the given UUID.
Expand
Table 4.28. GET Method Response for Update Ontology
HTTP Method
Request
Response
GET
N/A
Atom Entry
Example Request:
GET /s-ramp/ontology/fd0e5210-2567-409f-8df0-f851e1ce630d HTTP/1.1
The Delete Ontology API (/s-ramp/ontology/{uuid}) deletes an ontology from the repository.
This endpoint is used to delete a single ontology from the repository. This may fail if the ontology is currently in-use (at least one artifact is classified by at least one class defined by the ontology).
Expand
Table 4.29. DELETE Method Request and Response for Delete Ontology
The Get Artifact Audit History API (/s-ramp/audit/artifact/{artifactUuid}) retrieves an Atom feed containing all of the audit entries for a single artifact.
This endpoint is used to get a feed of the audit history of a single artifact. The request URL can include standard paging parameters. The response is an Atom Feed where each Entry in the feed represents a single audit event in the history of the artifact. A follow up call must be made to the Get Artifact Audit Entry endpoint in order to retrieve full detail information about the audit event. This call may fail if no artifact exits with the given UUID.
Expand
Table 4.30. GET Method Response for Get Artifact Audit History
HTTP Method
Request
Response
GET
N/A
Atom Feed
Example Request:
GET /s-ramp/audit/artifact/b086c558-58d6-4837-bb38-6c3da760ae80 HTTP/1.1
The Get User Audit History API (/s-ramp/audit/user/{username}) retrieves an Atom feed containing all of the audit entries for a specific user.
This endpoint is used to get a feed of the audit history for a single user. The request URL can include standard paging parameters. The response is an Atom Feed where each Entry in the feed represents a single audit event in the history of the artifact. A follow up call must be made to the Get Artifact Audit Entry endpoint in order to retrieve full detail information about the audit event. This call may fail if no user exists with the given username.
Expand
Table 4.31. PUT Method Request for Update Ontology
The Add Artifact Audit Entry API (/s-ramp/audit/artifact/{artifactUuid}) adds a user-defined (custom) audit entry to an artifact.
This endpoint is used to add a custom audit entry to a particular artifact. The request must be a POST of an XML document conforming to the audit schema type auditEntry. This call may fail if no artifact exists with the given UUID.
Expand
Table 4.32. POST Method Request and Response for Add Artifact Audit Entry
HTTP Method
Request
Response
POST
application/auditEntry+xml
Atom Entry
Example Request:
POST /s-ramp/audit/artifact/b086c558-58d6-4837-bb38-6c3da760ae80 HTTP/1.1
The Get Artifact Audit Entry API (/s-ramp/audit/artifact/{artifactUuid}/{auditEntryUuid}) retrieves full detailed information about a single audit entry.
This endpoint is used to get the full details for a single audit event for a particular artifact. The particulars of the detailed information are specific to the type of audit entry, so artifact create detail information might be different from artifact update detail information. Additionally, there is the possibility that the detail information might be from a custom audit entry added by an end user. This call may fail if the artifact does not exist or the audit entry does not exist.
Expand
Table 4.33. GET Method Response for Get Artifact Audit Entry
HTTP Method
Request
Response
GET
N/A
Atom Entry
Example Request:
GET /s-ramp/audit/artifact/b086c558-58d6-4837-bb38-6c3da760ae80/2947f90e-0f5a-4099-b3dc-29124c96c7d0 HTTP/1.1
Connecting to the S-RAMP server gives you access to the S-RAMP dashboard and repository. This allows you to access artifacts and their metadata in one place. Once you have signed in, you can browse the repository and inspect your data.
Open a command terminal and navigate to EAP_HOME/bin directory.
Start the JBoss EAP server by entering following command:
$ ./standalone.sh
Open another terminal and type connect and press Tab key. The command will auto-complete to say s-ramp:connect http://localhost:8080/s-ramp-server.
Enter username and password to connect via the S-RAMP shell. The username and password are defined in sramp.properties.
Result
When you press Tab key, the command will auto-complete to say s-ramp:connect http://localhost:8080/s-ramp-server and when you press the return key the cursor will go from red to green indicating successful connection to S-ramp server.
Running the commands in this task will allow you to access the S-RAMP repository and peruse its contents. You can view server output and metadata for artifacts. This lets you view additional details of indexed items.
To obtain the metaData of overlord.demo.SimpleReleaseProcess.bpmn (which is number 8 in the list in the output example), issue this command: s-ramp:getMetaData feed:8
Meta Data for: 31b3acbc-cda8-4856-9e34-d3e645283035
--------------
-- Core S-RAMP Info --
Type: BpmnDocument
Model: ext
UUID: 31b3acbc-cda8-4856-9e34-d3e645283035
Name: overlord.demo.SimpleReleaseProcess.bpmn
Derived: false
Created By: anonymous
Created On: 2013-03-08T14:00:37.036-05:00
Modified By: anonymous
Modified On: 2013-03-18T14:58:46.328-04:00
s-ramp>
To update a property on the artifact, enter s-ramp:property set and hit the tab key.
This lists the properties that you can update.
description name version
Add a description: s-ramp:property set description "BPMN2 artifact representing the SimpleReleaseProcess".
Successfully set property description.
s-ramp> s-ramp:updateMetaData
Successfully updated artifact overlord.demo.SimpleReleaseProcess.bpmn.
Verify the change, by entering s-ramp:getMetaData feed:8.
The change will appear at the bottom of the output:
Meta Data for: 31b3acbc-cda8-4856-9e34-d3e645283035
--------------
-- Core S-RAMP Info --
Type: BpmnDocument
Model: ext
UUID: 31b3acbc-cda8-4856-9e34-d3e645283035
Name: overlord.demo.SimpleReleaseProcess.bpmn
Derived: false
Created By: anonymous
Created On: 2013-03-08T14:00:37.036-05:00
Modified By: anonymous
Modified On: 2013-03-18T16:09:56.879-04:00
-- Description --
BPMN2 artifact representing the SimpleReleaseProcess
To add a custom property, run the s-ramp> s-ramp:property set month December command, where month is the name of the property and December is the value.
Successfully set property month.
To update artifact, run the s-ramp> s-ramp:updateMetaData command.
To add a classification of deployment-status to your artifact, use the s-ramp> s-ramp:classification add "http://www.jboss.org/overlord/deployment-status.owl#Dev" command.
S-RAMP supports an XPath2 Syntax for querying. For example, to obtain all WSDL models in the repository, use the s-ramp:query /s-ramp/wsdl/WsdlDocument command.
Querying the S-RAMP repository:
/s-ramp/wsdl/WsdlDocumenta
Atom Feed (1 entries)
Idx Type Name
--- ---- ----
1 WsdlDocument OrderService.wsdl
When this WSDL file is uploaded, the derived information is extracted from it and stored a WSDL model.
To see the various data structures the WSDL file derives, enter s-ramp:query /s-ramp/wsdl command and press the tab key.
Binding BindingOperation BindingOperationFault BindingOperationInput BindingOperationOutput
Fault Message Operation OperationInput OperationOutput
Part Port PortType WsdlDocument WsdlExtension
WsdlService
The derived data is read-only.
To obtain all Operations in this WSDL, use the s-ramp:query /s-ramp/wsdl/Operation command.
Querying the S-RAMP repository:
/s-ramp/wsdl/Operation
Atom Feed (1 entries)
Idx Type Name
--- ---- ----
1 Operation submitOrder
To narrow down this query, add a condition that the name needs to start with submit: s-ramp:query "/s-ramp/wsdl/Operation[xp2:matches(@name, 'submit.*')]"
Querying the S-RAMP repository:
/s-ramp/wsdl/Operation[xp2:matches(@name, 'submit.*')]
Atom Feed (1 entries)
Idx Type Name
--- ---- ----
1 Operation submitOrder
Ensure that you use the surrounding quotes, and a . (dot) after submit as required by XPath2.
To obtain all the artifacts that were derived from an artifact, use the following command:
/s-ramp[relatedDocument[@uuid = '<uuid>'
In this case, you can use the uuid of a wsdl and get all the artifacts derived from the wsdl:
s-ramp:query "/s-ramp[relatedDocument[@uuid = '15a94308-a088-4a03-ad83-e60239af74e4']]"
Querying the S-RAMP repository:
/s-ramp[relatedDocument[@uuid = '15a94308-a088-4a03-ad83-e60239af74e4']]
Atom Feed (16 entries)
Idx Type Name
--- ---- ----
1 OperationInput submitOrder
2 WsdlService OrderService
3 SoapAddress soap:address
4 BindingOperationInput wsdl:input
5 SoapBinding soap:binding
6 Part parameters
7 Binding OrderServiceBinding
8 BindingOperationOutput wsdl:output
9 Message submitOrderResponse
10 OperationOutput submitOrderResponse
11 BindingOperation submitOrder
12 Message submitOrder
13 Operation submitOrder
14 Port OrderServicePort
15 Part parameters
16 PortType OrderService
To get a list of all artifacts that were extracted from another archive, use the following command:
The S-RAMP CLI has a number of built-in commands that are ready to be used. However, it is also possible to extend the CLI with new custom commands. This section describes how to do it.
New CLI commands are contributed by creating a class that implements the ShellCommandProvider interface. The provider indicates a namespace for its commands along with a Map of commands (command name > command). The provider and command implementations should be packaged up into a JAR along with a file called META-INF/services/org.overlord.sramp.shell.api.ShellCommandProvider.
Ensure to make the JAR available to the S-RAMP CLI, either by putting it on the classpath, or else by putting it in the ~/.s-ramp/commands directory.
A key feature of the S-RAMP project is the integration between Maven and S-RAMP. This integration is currently primarily provided by a Maven Wagon that supports the S-RAMP Atom based REST API protocol. You can use this wagon to upload deployable artifacts directly from Maven into a compliant S-RAMP repository.
Additionally, you can use artifacts from the S-RAMP repository as dependencies in a Maven project, also by using the S-RAMP Maven Wagon.
With these settings, maven deployments are sent directly to the S-RAMP repository using the S-RAMP API. Note that artifacts are added to the S-RAMP repository with an artifact type based on the maven type of the project. You can override this behavior by adding a query parameter to the repository URL in the pom.xml. For example:
Once you enable the wagon, you can use artifacts from the S-RAMP repository as dependencies in your maven project.
Firstly, you must configure the S-RAMP repository in the maven project as a maven repository. You can do this with the following markup in the pom.xml:
Once you configure the repository, you can reference an S-RAMP artifact as a dependency in the following ways:
If the artifact was added to S-RAMP using the maven integration to deploy it, then the artifact in S-RAMP will contain maven specific properties, allowing it to be referenced as a dependency using those maven specific properties. In this case, add the dependency as shown in this example:
If an artifact was added to the S-RAMP repository in some other way (and therefore does not have any maven specific properties), you can still use it as a dependency. In this case, you can reference the dependency by using its S-RAMP artifact model, type, and UUID. The model and type are used to make up a maven groupId, while the UUID becomes the maven artifactId. The version information is not used, but is still required in the pom.xml). For example, if a JAR is added to the S-RAMP repository and you wish to use it as a dependency, your pom.xml might contain the following dependency:
Whenever the S-RAMP Maven integration features are used, it is likely that you will need to provide valid authentication credentials. You may provide the S-RAMP repository username and password in the Maven settings.xml file. If no credentials are found there, then you will be prompted to enter them when they are needed during the build. Here is an example of providing credentials in the settings.xml file:
We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.
Making open source more inclusive
Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.
About Red Hat
We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.