S-RAMP Foundation Version 1.0

spinabundantInternet and Web Development

Jul 30, 2012 (4 years and 10 months ago)

532 views

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
1

of
61


S
-
RAMP Foundation

Version
1.0

1

Working Draft
01

2

26 January 2011

3

Abstract:

4

Vendors offer tools to facilitate various activities across the life cycle of a SOA artifact, such as
5

design,
assembly, quality assurance, deployment and runtime operation of SOA based
6

applications and business processes. The lack of a standardized information model and
7

interaction protocol for artifacts and their metadata residing in a SOA repository means that
tools
8

must be customized for use with each different vendor’s SOA repository product. This reduces
9

choice, flexibility and adds costs for customers when choosing tools. This specification defines a
10

SOA artifact data model together with bindings that descr
ibe the syntax for interacting with a SOA
11

repository.

12

Status:

13

A "Working Draft" is a preliminary version of a Work Product produced by one or more TC
14

Members that has not yet been voted on by the TC and approved as a Committee Specification
15

Draft or a Comm
ittee Note Draft. The OASIS document Approval Process begins officially with a
16

TC vote to approve a WD as a Committee Draft. The TC may at any stage during development of
17

a Work Product approve a Working Draft as a Committee Specification Draft; approval o
f these
18

drafts shall require a Full Majority Vote of the TC. The TC may approve a Working Draft, revise it,
19

and re
-
approve it any number of times as a Committee Specification Draft.

20


21


22

Copyright © OASIS® 2011
. All Rights Reserved.

23

All capitalized terms in t
he following text have the meanings assigned to them in the OASIS Intellectual
24

Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

25

This document and translations of it may be copied and furnished to others, a
nd derivative works that
26

comment on or otherwise explain it or assist in its implementation may be prepared, copied, published,
27

and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice
28

and this section

are included on all such copies and derivative works. However, this document itself may
29

not be modified in any way, including by removing the copyright notice or references to OASIS, except as
30

needed for the purpose of developing any document or deliverab
le produced by an OASIS Technical
31

Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must
32

be followed) or as required to translate it into languages other than English.

33

The limited permissions granted above a
re perpetual and will not be revoked by OASIS or its successors
34

or assigns.

35


36

37

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
2

of
61


1

Introduction

38

The “SOA
-

Repository Artifact Model and Protocol” (S
-
RAMP) specification defines a common data
39

model for SOA repositories to facilitate the use of common tooling
and sharing of data. It provides a rich
40

representation data model that supports query. It includes binding(s) which document the syntax for
41

interaction with a compliant repository for create, read, update, delete and query operations within the
42

context o
f each binding. Initially, only one binding will be defined, but others can be added.

43

The specification is organized into multiple documents. This document, the SOA
-

Repository Artifact
44

Model and Protocol Foundation (hereafter referred to as Foundation)

describes the overall goals of S
-
45

RAMP and defines the Artifact Type Model and associated schemas for S
-
RAMP. It also describes the
46

generic query grammar used in S
-
RAMP. The Foundation document is not specific to any binding. Other
47

documents in this spe
cification provide material specific to a given binding for S
-
RAMP, including the
48

syntax for interacting with an S
-
RAMP compliant repository. Those available at the time of this
49

publication are:

50



S
-
RAMP Atom Binding

51

When there is a discrepancy between a bi
nding specific document and this Foundation document, the
52

binding specific document always takes precedence. If there is a discrepancy between schema
53

representations provided in this document and the S
-
RAMP schemas of record on s
-
ramp.org, the
54

schemas of
record SHALL take precedence.

55

1.1

Terminology

56

The key words “
MUST

,

MUST NOT

,

REQUIRED

,

SHALL

,

SHALL NOT

,

SHOULD

,

SHOULD
57

NOT

,

RECOMMENDED

,

MAY

, and

OPTIONAL
” in this document are to be interpreted as described
58

in
[RFC2119]
.

59

The characters "[" and "]" are used to indicate that contained items are to be treated as a group with
60

respect to cardinality or choice.

61

This document makes use of many UML Diagrams and a summary
of the notation used in those
62

diagrams is provided here for convenience

63



Italicized artifacts are abstract

64



Closed arrows indicate inheritance

65



Open arrows indicate non
-
containment association relationships

66



Filled diamonds ending in open arrows represent
composition relationships

67



Names associated with arrows indicate Relationship Type names

68

NOTE: Attributes listed within an artifact box do not indicate cardinality. Users must refer to the document
69

text and schemas for that information.

70

1.2

Normative Reference
s

71

[RFC2119]

S. Bradner,
Key words for use in RFCs to Indicate Requirement Levels
,
72

http://www.ietf.org/rfc/rfc2119.txt
, IETF RFC 2119, March 1997

73

1.3

Non
-
Normative References

74

[XML]

Extensible Markup Language (
XML) 1.0 Specificatio
n
(Fifth Edition)
,
75

http://www.w3.org/TR/2008/REC
-
xml
-
20081126/
, W3C Recommendation,
76

November 2008.

77

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
3

of
61


[XMLNS]

Namespaces in XML 1.0 (Second Edition),

http://www.w3.org/TR/2006/REC
-
xml
-
78

names
-
20060816/
, W3C Recommendation, August 2006.

79

[XSD]

XML Schema Part

1
: Structures Second Edition, version 1.0,

80

h
ttp://www.w3.org/TR/2004/REC
-
xmlschema
-
1
-
20041028/
, W3C
81

Recommendation, October 2004.

82

[XPATH]

XML Path Language
(XPath) 2.0 (Second Edition),

83

http://www.w3.org/TR/2010/REC
-
xpath20
-
20101214/
, W
3C Recommendation,
84

December 2010.

85

[RDF]

RDF Primer,

http://www.w3.org/TR/2004/REC
-
rdf
-
primer
-
20040210/
, W3C
86

Recommendation, February 2004.

87

[OWL]

OWL Web Ontology Language Guide
,

http://www.w3.org/TR/2004/REC
-
owl
-
88

guide
-
20040210/
, W3C Recommendation, February 2004

89

[WSDL]

Web Services Description Language (WSDL),
Version 1.1,

90

http://www.w3.org/TR/2001/NOTE
-
wsdl
-
20010315
, W3C Note, March 2001.

91

[ISO6392]

Codes for the Representation of Names and Languages



Part 2,

92

http://www.loc.gov/standards/iso
639
-
2/normtext.html
, ISO 639
-
2, 1998.

93

[SOAONT]

Service Oriented Architecture Ontology
(Public Draft 3.2),

94

http://www.opengroup.org/projects/soa
-
ontology/
, The Open Group, August
95

2010.

96

[WSFWK]

Web Services Policy 1.5



Framework
,

http://www.w3.org/TR/2007/REC
-
ws
-
97

policy
-
20070904
, W3C Recommendation, September 2007.

98

[WSATTCH]

Web Services Policy 1.5



Attachment,

http://www.w3.org/TR/2007/REC
-
ws
-
99

policy
-
attach
-
20070904
, W3C Recommendation, September 2007.

100

[UUID]

P. Leach, M. Mealling, and R. Salz,
A Universally Unique ID
entifier (UUID) URN
101

Namespace
,
http://www.ietf.org/rfc/rfc4122.txt
, IETF RFC 4122, July 2005.

102

[QUERYOPS]

XQuery 1.0 and XPath 2.0 Functions and Operators (Second Edition)
,
103

http://www.w3.org/TR/2010/REC
-
xpath
-
functions
-
20101214/
, W3C
104

Reco
mmendation, December 2010.

105


106

1.4

Problem Statement and Objectives

107

Service Oriented Architecture (SOA) is an architectural approach to designing applications and
business
108

processes

by consuming business logic from reusable software components exposed as netwo
rk
109

accessible services. In today’s environment, vendors offer tools to facilitate various activities across the
110

life cycle of a SOA artifact, such as design, assembly, quality assurance, deployment and runtime
111

operation of SOA based applications and busine
ss processes. The SOA repository provides the
112

foundation for all these activities. This specification codifies how SOA information models are represented
113

by artifacts (including their associated metadata) in a SOA repository. This specification also defin
es
114

bindings to support interaction with the SOA repository, including create, read, update, delete, query, and
115

subscription for notifications. It defines the Artifact Type Model and provides various bindings
that

define
116

the syntax needed to support interac
tion with a SOA repository. This approach to providing flexible
117

access to SOA artifacts will facilitate interoperability and provide customers with more choices of tools
118

that can be used to interoperate with any S
-
RAMP compliant SOA repository implementati
on
.

119

1.5

Use Case Scenarios

120

Table
1
,
Table
2

and

Table
3

below provide some examples across different portions of the service
121

lifecycle for which
there are various use cases in which an S
-
RAMP compliant repository could be used.
122

This does not necessarily imply that all vendors would support every scenario, or use an S
-
RAMP
123

repository in each of these scenarios across all portions of the service lif
ecycle.


124


125


126

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
4

of
61



127


128

Table
1
: Design Time Tool Repository Interaction Use Cases

129

Tool Category

Activities

S
-
RAMP Feature

Examples

Integrated
Development
Environment
(IDE)

1.

Design WSDL and schemas

2.

Publish and consume services

3.

Publish SCA
into repository

4.

Shred SCA for impact analysis

5.

Notification to service developer
when WSDL changes

WsdlDocument

XsdDocument

OWL classifications

PortType

WID

RSA

Together

VisualStudio

Oracle JDeveloper

Business
Process
Modeling Tools

1.

Publish WSDL
descriptions for
processes

2.

Look for process entry points

3.

Search/find services to use in their
business processes

4.

Impact analysis

wsdDocument

XsdDocument

OWL classifications

PortType

WebSphere Business
Modeling

ARIS Platform

Oracle (Collaxa)

TIBCO Business
Studio


130

Table
2
: Run Time Tool Repository Interaction Use Cases

131

Tool Category

Activities

S
-
RAMP Feature

Examples

Testing

1.

Search to find a WSDL

2.

Understand policies associated
with WSDL

3.

Understand relationships between
SOA
components

4.

Notification when WSDL changes

WsdlDocument

Service

PolicyAttachment

Policy


HP Service Test
Manager

Rational Testing Tools

Itko Lisa

ESB

1.

Dynamic routing based on
#services, requestor type, etc.

2.

Notifications of new artifacts,
changes/deletions

3.

Track information on lifecycle and
operational state (e.g., using
classifications, properties, etc.)

PolicyAttachment

WSDL Parts

Service properties

DataPower

WebSphere ESB

Oracle Service Bus

SAP XI

WebMethods

TIBCO ActiveMatrix

Policy Mgmt

1.

Edit and store

policies

2.

Query repository for policies to
deploy/provision

3.

Execute (enforce) policy

4.

Update managed endpoint in
repository

PolicyAttachment

policy

service

ServiceEndpoint

AmberPoint

Actional

HP SOA Policy
Enforcer

CentraSite

TIBCO ActiveMatrix
Policy
Manager


132


133

134

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
5

of
61


Table
3
: Monitoring Tool Repository Interaction Use Cases

135

Tool Category

Activities

S
-
RAMP Feature

Examples

Service
Monitoring

1.

Retrieve service definitions from
repository

2.

Update service information with
performance
and availability data

3.

Discover dependencies between
business services and web service
instance

4.

Discover what organizations
provide a service

5.

Discover operational data for the
service for monitoring

Organization

Service

ServiceInstance

ServiceOperation

user properties

Tivoli CAM for SOA

BAC for SOA

AmberPoint

Actional

WebMethods Insight

TIBCO ActiveMatrix
Service Performance
Manager


136

1.6

Design Principles

137

There are several high
-
level design principles to which S
-
RAMP has adhered:

138



Use of existing standards
where possible (e.g., XML, XML Schema, OWL, XPath2, APP (Atom
139

Publishing Protocol), ASF (Atom Syndication Format), etc.).

140



Vendor neutrality.

141



Does not include governance models, but may be used by them.

142



Driven by use cases.

143



Data model extensibility for
new data types, and support for system and user defined metadata.

144



Inclusion of an XML Schema based serialization for its data model.

145



Use of XPath 2 to describe its query grammar.

146



Use of OWL Lite to describe its classification system grammar.

147



Separation
of the data model from the bindings which describe the interaction APIs clients use to
148

interact with the repository.

149

1.7

S
-
RAMP Schemas

150

The schemas for the various S
-
RAMP Models are provided in the appendices. They closely follow the
151

conceptualized UML diagram
s described in this document. The normative S
-
RAMP schemas of record
152

define the serialization for S
-
RAMP.

153

Notable points concerning the schemas in S
-
RAMP include:

154



Built
-
in properties are typically represented as attributes.

155



Types based on
BaseArtifactType

use an extension of that type as their base.

156



Where practical, Global Element Declarations are provided.

157



Extensibility in the Core Model is limited to the ##any attribute on most structures.

158

Schemas are provided for serialization purposes and the UML diagr
ams define the S
-
RAMP meta
-
model.

159


160

1.8

XML Namespaces

161

The XML namespace URI that MUST be used by implementations of this specification is:

162

http://s
-
ramp.org/xmlns/2010/s
-
ramp

163

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
6

of
61


Table
4

lists the XML namespaces that are used in this specification. The choice of any namespace prefix
164

is arbitrary and not semantically significant.

165

Table
4
: Prefixes and XML Namespaces Used in this Specification

166

Prefix

XM
L Namespace

Specification(s)

xp2

http://www.w3.org/2005/xpath
-
functions

XPath 2.0

rdf

http://www.w3.org/1999/02/22
-
rdf
-
syntax
-
ns#

RDF namespace

rdfs

http://www.w3.org/2000/01/rdf
-
schema#

RDFS
namespace

owl

http://www.w3.org/2002/07/owl#

OWL namespace

s
-
ramp

http://s
-
ramp.org/xmlns/2010/s
-
ramp

S
-
RAMP namespace

wsdl

http://schemas.xmlsoap.org/wsdl/

WSDL [WSDL 1.1]

wsp

http://www.w3.org/TR/2007/REC
-
ws
-
policy
-
20070904

WS
-
Policy [WS
-
Policy]

xsd

http://www.w3.org/2001/XMLSchema

XML Schema [Part 1, 2]


167


168

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
7

of
61


2

Artifact Type Model

169

The S
-
RAMP Artifact Type Model is a strongly typed data model for SOA repositories which allows
170

interoperability among vendor repository implementations and tooling, within the
context of a specific
171

binding. It will also later serve as a foundation for developing data exchange and federation models. The
172

Artifact Type Model is presented here using conceptualized UML models. Each of these models also has
173

a XML Schema representat
ion available in the Appendice
s.

174

2.1

Artifact Type Models

175

An artifact in S
-
RAMP is a container for all of the metadata that describes it. There are 4 major types of
176

artifacts in S
-
RAMP. Each of these Artifact Types is discussed in more detail in later section
s:

177

1.

Document Artifact
: Those which correspond to a physical document stored in the repository.
178

Several important document types are pre
-
defined and have special support in S
-
RAMP (such as
179

XML Schema or WSDL documents). But any document type can be placed in the repository.


180

2.

Service Implementation Model Artifact
: Those S
-
RAMP defined artifacts which provide a
181

representation of the service implementation layer associated with the SOA Model (such as a
182

ServiceOperation or ServiceEndpoint).

183

3.

Derived Artifact
: Derived Artifac
ts (e.g., WSDL PortType, or WS
-
Policy PolicyExpression) are
184

dynamically instantiated by the server as a consequence of publishing a document instance
185

whose type is one of those supported with a Derived Model (see
Table
5
). These artifacts cannot
186

be created or deleted directly, although clients can edit them to add or remove Generic
187

relationships, properties and classifications. Derived Artifact Models are managed by
the server
188

and kept in synchronization with the document object with which they are associated. Derived
189

artifacts provide a metadata model of the content components of a particular document. This
190

allows much more powerful query capabilities at a granular
ity specific to the internal components
191

of a document, when it is of a format supported with a Derived Model. Refer to Section
4

for more
192

information on the query m
odel supported in S
-
RAMP, as well as to the individual binding
193

document(s) for the query syntax pertaining to each binding.

194

4.

SOA Model Artifact
: Those S
-
RAMP defined artifacts and relationships as well as those defined
195

in the “SOA Repository View” of The O
pen Group’s SOA Ontology, which provides a conceptual
196

representation of a SOA environment. The SOA Repository View is defined by The Open Groups
197

SOA Ontology draft version 3.2.

198

5.

User Defined Artifact Model
: These are created by the client and are part of
a User Defined
199

Model. The means by which a client specifies such a model are beyond the scope of this
200

specification, but some provision is made within S
-
RAMP schema to facilitate basic
201

interoperability for such artifacts. Regardless of the internal defin
ition of these artifacts, they
202

SHALL be serialized in S
-
RAMP as an instance of
UserDefinedArtifactType
, which extends
203

BaseArtifactType.

204

The pre
-
defined S
-
RAMP Artifact Types are organized into a set of logical models as summarized in
205

Table
5

below. Each of these is discussed further in the sections that follow. Note that Derived Artifact
206

Models are currently specified for each of the XSD, WSDL and WS
-
Policy document ty
pes.

207


208


209


210


211


212


213

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
8

of
61


Table
5
: Artifact Type Models

214

Model

Purpose

Core

Defines the base data types used by the other models

SOA

Defines the artifact data types and relationships which are used to integrate
The Open Group’s SOA Ontology
潢j散琠t潤敬=i湴漠o
-
RAMP’s data model.
=
p敲eic攠em灬敭敮瑡tion
=
䑥ai湥s⁴=攠ertif慣琠t慴a=typ敳⁡=搠牥l慴io湳桩灳⁵=敤⁴漠o潤敬⁴=e⁳敲eic攠
im灬敭敮瑡ti潮=lay敲e⁡=plA⁥=vir潮m敮琮
=
䑥aiv敤㨠Wpa
=
䑥ai湥s潧ical⁡牴if慣琠t慴a⁴yp敳⁦潲⁡渠o䵌=pc桥m愠a潣畭e

=
䑥aiv敤㨠tp䑌
=
䑥ai湥s潧ical⁡牴if慣琠t慴a⁴yp敳⁦潲⁡otp䑌⁤潣um敮t
=
䑥aiv敤㨠plAmtp䑌
=
䑥ai湥s⁡牴if慣琠t慴a⁴yp敳⁦潲⁴桥oplAm⁢in摩n朠gf⁡=tp䑌⁤潣畭敮t
=
䑥aiv敤㨠molicy
=
䑥ai湥s⁡牴if慣琠t慴a⁴yp敳⁦潲⁡渠tp
-
m潬icy=摯c畭敮t
=
=
㈱O
=
2.1.1

Artifact Metadata

216

An
artifact can contain three major types of metadata. Each is discussed in detail in the sections that
217

follow.

218

1.

Relationships
: These are directed associations that describe a conceptual link between two
219

artifact instances. There are several types of relation
ships, which are defined below in Section
220

2.1.2
.

221

2.

Properties
: These describe various named attributes associated with an artifact instance, and
222

can be built
-
in or user
-
defined. Each S
-
RAMP property MUST have a single name that is unique
223

to the artifact that it decorates. When present, an S
-
RAMP property SHALL hav
e a single value.

224

3.

Classifications
: Classification systems in S
-
RAMP are imported by the server as OWL
225

documents that define the classification system to the server. The means by which a client
226

imports the system into the server is implementation specific

and is beyond the scope of this
227

specification. Clients MAY decorate artifacts with references to specific values in a classification
228

system defined to the server.

229

Note that Artifact Type and Artifact Model values MUST also be unique.

230

2.1.2

Relationships in S
-
R
AMP

231

Relationships in S
-
RAMP are all directed from a source, to a target. Each relationship instance is the
232

logical triple of the following 3 items of metadata:

233

1.

Relationship Type
. This is the name for the type of relationship. A number of these are pre
-
234

d
efined by S
-
RAMP in the various Artifact Models (e.g., “includedXsds”, “appliesTo”, …). There
235

can be multiple relationship instances of the same Relationship Type.

236

2.

Source.

This is a reference to the artifact that is on the source side of the directed rel
ationship.
237

Relationships are always contained by the Source Artifact that “owns” them.

238

3.

Target.

This is a reference to the artifact that is on the target side of the directed relationship.

239

It is possible for a relationship of a given Relationship Type n
ot to have a target, which is termed a
240

“relationship with no targets”. In this case there is only one relationship instance with that Relationship
241

Type for a given Source. Such relationships have a target cardinality of “0”. If there is a relationship
242

i
nstance with a given Relationship Type that does have a target, then there CANNOT also be a
243

relationship instance with that Relationship Type which has no target.

244

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
9

of
61


There are 4 types of relationships supported in S
-
RAMP. Refer to the table in Appendix
I

for a complete
245

list of pre
-
defined relationships, an indication of whether the relationship is derived, and the model in
246

which it occurs.

247

1.

Derived Relationships
. These

are pre
-
defined relationships that cannot be directly created or
248

deleted by the client. Cardinalities for such relationships are defined in the applicable Derived
249

Model. All instances of an Artifact Type for which a Derived Relationship is defined, will

always
250

contain that Derived Relationship, even if there are no targets for that relationship. The S
-
RAMP
251

serialization of a Derived Relationship uses named elements defined in the schema for the
252

appropriate Artifact Type definition(s).

253

2.

Modeled Relationshi
ps.

These refer to the S
-
RAMP pre
-
defined relationships that may be
254

edited by the client. Cardinalities for such relationships are defined in the applicable model (e.g.,
255

the Service Implementation Model or Core Model). All instances of an Artifact Type
for which a
256

Modeled Relationship is defined, will always contain that Modeled Relationship, even if there are
257

no targets for that relationship. The S
-
RAMP serialization of a Modeled Relationship uses named
258

elements defined in the schema within the applica
ble Artifact Type. There are several
259

considerations related to target cardinality of Modeled Relationships:

260



Modeled Relationships with Minimum Cardinality = 0:

261



Instances of the Source Artifact can be created independently of the Target Artifact.

262



Modeled
Relationships with Minimum Cardinality > 0:

263



Instances of the Source Artifact cannot be created without the appropriate Target
264

Artifact(s) based upon the required minimum cardinality of the relationship.

265



This can be accomplished by publishing the relevant
artifacts at the same time, or by
266

publishing the target artifact(s) first.

267



Actions that result in the deletion of a relationship instance are not permitted if that would
268

result in a violation of the minimum cardinality.

269



Modeled Relationships with Maximum C
ardinality < unbounded:

270



Relationship instances cannot be created if that would result in a violation of the
271

maximum cardinality limit for the Modeled Relationship.

272

Note that in cases where the minimum cardinality equals the maximum cardinality, such a
273

relationship must be created or updated in a single step to avoid intermediate states that would
274

violate these requirements.

275

3.

Generic Relationships
. These are user
-
defined ad
-
hoc directed relationship instances between
276

any two artifacts in S
-
RAMP. They al
ways have a minimum cardinality of 0 and an unbounded
277

maximum cardinality. The Relationship Type value of a Generic Relationship instance is chosen
278

by the client, but it MUST NOT match any pre
-
defined Relationship Type values already defined
279

by the S
-
RAMP

Modeled and Derived relationships. (see

Appendix
I
).

The S
-
RAMP serialization
280

of a Generic Relationship uses the
relationship

structure defined in the Core Model.

281

4.

User Defined Modeled Relationships
. S
-
RAMP attempts to be compatible with
282

implementations which choose to allow users the ability to define models of their own which
283

consist of new or existing Artifact Types and any defined relationships between them, although
284

how and whether such models
are supported is beyond the scope of this specification. Such
285

models are called “User Defined Models”. Since pre
-
defined relationships in a model are termed
286

“Modeled”, then in this context they are called “User Defined Modeled Relationships”. The S
-
287

RAMP
serialization of a User Defined Modeled Relationship uses the S
-
RAMP
relationship

288

structure defined in the Core Model.

289


290

2.2

The Core Model

291

There is a single “core” model which defines all the basic Artifact Types used throughout S
-
RAMP. The
292

Core Model contains

abstract base artifacts for document artifacts and derived artifacts (which are
293

associated with certain document types). Most Artifact Types in the other S
-
RAMP models are
294

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
10

of
61


extensions of
BaseArtifactType
.
Figure
1

provides a conceptualized illustration of the Core Model
295

artifacts. In addition, there are a number of support types used by the core and other models. Note that
296

the class attributes in the UML diagram a
re essentially built
-
in properties. The remaining sub
-
sections
297

provided additional details on the Core Model.

298


299


300


301

Figure
1
: Conceptualized UML Model of Core Model Artifacts

302

2.2.1

Base Artifact Type

303

The
BaseArtifactType

is the fundamental abstract type used by all of the artifact models in S
-
RAMP. It
304

contains all of the common metadata which describes an artifact instance. All artifact instances which are
305

based on the
BaseArtifactType

contain the following metadata:

306



Bu
ilt
-
in Properties:

307

o

createdBy
: A required string assigned by the server identifying the user who created
308

the artifact. S
-
RAMP does not define requirements on this value. These are
309

implementation specific.

310

o

createdTimestamp
: A required timestamp which is s
et by the server at the time an
311

artifact is first published. It conforms to xml:dateTime, referenced to UTC.

312

o

description
: This optional property is used to provide a human consumable description
313

of the artifact instance. This value is set by the client f
or all non
-
Derived Artifacts
314

(although implementations MAY support setting it automatically using introspection.
315

Derived Artifact descriptions are set by the server.

316

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
11

of
61


o

lastModifiedBy
: A required string assigned by the server identifying the user who last
317

up
dated the artifact. S
-
RAMP does not define requirements on this value. These are
318

implementation specific.

319

o

lastModifiedTimestamp
: A required timestamp which is updated by the server each
320

time an artifact instance is modified. It conforms to xml:dateTime,

referenced to UTC.

321

o

name
: This required property is used to describe the artifact instance. This value is set
322

by the client for all non
-
Derived Artifacts (although implementations MAY support setting
323

it automatically using introspection). Derived Artifact

names are set by the server.

324

o

uuid
: A required unique identifier of an artifact instance in the repository. This value
325

conforms to Type 4 random
-
number format UUIDs
[UUID]
, and is set
for the artifact at
326

the time of its creation. The repository will assign a value if the user does not provide
327

one.

328

o

version
:

An optional string representing the version of the artifact instance. S
-
RAMP
329

makes no attempt to define formatting rules for this property, which are implementation
330

specific.

331



Generic Properties:

332

o

property
: These are optional properties which are defined
by the client. They MUST
333

have a single unique name (which SHALL NOT duplicate any other property name of
334

any type, and SHALL NOT duplicate any Relationship Type value). A property name
335

SHALL have 0 or 1 value.

336



Generic Relationships
:

337

o

relationship
: These

are optional relationship(s) defined by the client. A relationship
338

contains a Relationship Type identifying the type of the relationship, and 0 or more
339

target artifact references. Relationship Type values within a relationship SHALL NOT
340

duplicate the nam
e of any property.

341



Classifications
:

342

o

classifiedBy
: This is a separate class of metadata. It MAY be set by the client with an
343

unbounded upper cardinality limit. Each value SHALL be a URI which references a
344

specific OWL class from a classification system defined to the repository. For more on
345

OWL class
ification systems in S
-
RAMP, see Section
3
.

346

2.2.2

Document Artifact Types

347

The
DocumentArtifactType

is the fundamental abstract data type for all documents represented in

the
348

repository, and it extends
BaseArtifactType
. This Artifact Type includes several built
-
in properties:

349

contentType
:

350



A string indicating the MIME Media type of the content. This is set by the server as part of
351

processing the publication of the
document, and cannot be changed by the user.

352

contentSize
:

353



An integer representing the size of the content in bytes. This is set by the server as part of
354

processing the publication of the document. It cannot be changed by the user.

355

The Core Model also in
cludes an
XmlDocument

type which all XML based document data types extend.
356

The
Document

type provides a concrete artifact that can be used to represent arbitrary document types.
357

The
DocumentArtifactType

itself can also be further extended for other docum
ent types, such as binary
358

data, etc.

359

Documents which have a Derived Model associated with them cannot be updated in the repository. They
360

must be removed and republished.

361

Documents upon which another document has a dependency cannot be deleted.

362

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
12

of
61


2.2.3

Miscell
aneous Types

363

There are a few miscellaneous classes in the Core Model:

364

StoredQuery
:

365



This is a special Artifact Type which is used to persist queries in the repository. Additional
366

information on this topic is available in Section
3
,
Classification
Systems in S
-
RAMP
.

367

UserDefinedArtifactType
:

368



The
UserDefinedArtifactType

allows c
lients to create their own artifact type when it is not
369

predefined in an S
-
RAMP model. The
userType

property is intended to be used to provide an
370

indication of the object type.

371


372

2.3

Modeling SOA Concepts

373

S
-
RAMP supports modeling of business level SOA concepts

related to service and process
374

representations and interactions. Since it is not the mission of S
-
RAMP to define a “SOA Ontology” for
375

the industry, this specification has chosen to reference work being done by The Open Group in their
376

“SOA Working Group”
on the “SOA Ontology” (see
http://www.opengroup.org/projects/soa
-
ontology/
).
377

That work is compatible with both SCA and BPMN but draws both service and process concepts together
378

at a higher lev
el of abstraction.

379

S
-
RAMP supports modeling of SOA concepts using a layered approach:

380

1.

S
-
RAMP SOA Model

381

2.

S
-
RAMP Service Implementation Model

382

The sections below describe how the SOA Ontology work is integrated with S
-
RAMP as well as the
383

implementation
layer underneath it.

384

2.3.1

The SOA Model

385

The S
-
RAMP SOA Model exists to provide a mechanism to link work done by The Open Group SOA
386

Ontology work group with the rest of the S
-
RAMP internal models. It defines a very minimal set of
387

linkages to artifacts defined i
n the SOA Ontology.

388


389

NOTE: The S
-
RAMP specification SHALL be referential to draft version 3.1 of the SOA Ontology being
390

developed by The Open Group SOA working group. The SOA Ontology being developed is suitable for
391

use by SOA Repositories. This SOA O
ntology SHALL be considered normative for this specification.

392


393

Several S
-
RAMP modeling features have been defined in order to provide linkage between the SOA
394

Ontology and the S
-
RAMP data model. This is done using the S
-
RAMP SOA Model. Artifact Types in

395

this model are all user instantiated, and are described in the S
-
RAMP SOA Model illustrated in
Figure
2

396

below.

397

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
13

of
61



398


399

Figure
2
: Conceptualized

UML Model of SOA Model Artifacts

400


401

SOA Model artifacts and the SOA Ontology artifacts referenced by the SOA Model are designed to
402

provide clients the ability to create conceptual SOA representations. SOA Model Artifacts are all logical
403

artifacts and
do not represent or correspond directly to a document instance, as do those in the Derived
404

Models.

405

S
-
RAMP provides an XML Schema representation of the S
-
RAMP SOA Model, including elements
406

corresponding to the base version of The Open Groups SOA Ontology’s
defined artifacts, within the
407

context of the S
-
RAMP data model. It can be found in
Appendi
x
F
.

408

2.3.1.1

SOA Model Artifact Types and Relationships

409

The abstract
SoaModelType

Artifact Type implicitly acts as a super class for ALL top level SOA Ontology
410

artifacts when they are used within the context of S
-
RAMP. This imbues all of them with the properties
411

built into all S
-
RAMP Artifact Types. S
-
RAMP adds several relationships
to SOA Ontology Artifacts used
412

in the SOA Model in order to provide a connection from the SOA Ontology artifacts into the
413

implementation level artifacts described in the Service Implementation Model in Section
2.3.3
.

414

SOA Model Artifacts MAY have relationships to Document Artifacts and/or Derived Artifacts in other
415

models, as well as among themselves. All the relationships defined in the SOA Model are Modeled
416

Relati
onships. See Section
2.1.2

for behavioral details associated with Modeled Relationships. The
417

relationships which have been added to artifacts from the SOA Ontolo
gy are summarized in
Figure
3

418

below.

419


420

Figure
3
: SOA Model Relationships

421

Relationship Name

Source
Artifact Type
(from SOA
Ontology)

Target
Artifact
Type (from S
-
RAMP Business
& Core Models)

Notes

hasInstance

Service

ServiceInstance


s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
14

of
61


hasOperation

ServiceInterface

ServiceOperation


interfaceDefinedBy

ServiceInterface

DerivedArtifactType

This allows one to indicate the
Derived Artifact instance which
defines this service interface. For
example, this could be
PortType

artifact instance from the WSDL
Model.

policyDefinedBy

Policy

DerivedArtifactType

This allows one to link the SOA
Model Pol
icy artifact with a
concrete S
-
RAMP derived artifact
type (e.g., PolicyAttachment)

informationTypeDefinedBy

InformationType

DerivedArtifactType

This allows one to link the SOA
Model InformationType artifact with
a concrete S
-
RAMP derived artifact
type (e.
g., PolicyAttachment)


422

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
15

of
61



423

2.3.2

The Service Implementation Model

424

S
-
RAMP defines a “Service Implementation Model” which describes the service implementation layer
425

underneath the SOA Model. Artifact Types in this model are all user instantiated and most are extensible.
426

Each of these artifacts derives from the
ServiceImpl
ementationModelType

and may be created, changed,
427

updated and deleted by the client. There are a number of pre
-
defined Modeled Relationships between
428

artifacts of particular types.
Figure
4

below illustrates the conceptualized Service Implementation Model
429

artifacts.

430


431


432


433


434

Figure
4
: Conceptualized UML Model of Service Implementation Model Artifacts

435


436

S
-
RAMP provides an XML Schema representatio
n of the Service Implementation Model. It can be found
437

in Appendix
G
. The sub
-
sections that follow discuss each of the Service Implementation Artifact types in
438

m
ore detail.

439

2.3.3

Service Implementation Model Artifact Types

440

The primary Artifact Type from which all Service Implementation Model Artifacts extend is the abstract
441

ServiceImplementationModelType.

The concrete Service Implementation Model Artifacts which extend

it
442

are designed to provide the implementation layer below the SOA Model which allows clients to build SOA
443

representations. Service Implementation Model Artifacts are all logical artifacts and do not represent or
444

correspond directly to a document instance

as do those in the Derived Models.

445

Service Implementation Model Artifacts MAY have relationships to Document Artifacts and/or Derived
446

Artifacts in other models, as well as among themselves. All the relationships shown in the Service
447

Implementation Model
are Modeled Relationships. See Section
2.1.2

for behavioral details associated
448

with Modeled Relationships. Of note for the
ServiceImplementationModelType
is the
documentation

449

Modeled Relationship which allows any artifact in the Service Implementation Model to reference a
450

document describing it.

451

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
16

of
61


The concrete Service Implementation Model Artifact Types are then:

452

Organization


453



The
Organization

type is used to describe an organizational entity. It is a subclass of the “Human
454

Actor” artifact defined in the SOA Ontology. Clients can define an unlimited number of
455

organizations and can use the
provides

relationship to link an Organization to any S
ervice
456

Implementation Model Artifact

457

ServiceInstance

458



The
ServiceInstance

Artifact Type represents deployed instance(s) of a service. For example, a
459

Web service running in WebSphere, or Oracle Fusion, etc. The
describedBy

Modeled
460

Relationship can be used
to reference document artifact(s) that describe it.

461

ServiceEndpoint

462



The
ServiceEndpoint

Artifact Type represents a physical location at which the Service instance
463

can be invoked, using its
url

Modeled Property. The
endpointdefinedBy

Modeled Relationship
464

a
llows indicating the Derived Artifact instance which defines this Service endpoint is defined. For
465

example, this could be a
Port

artifact instance from the WSDL Model.

466

ServiceOperation

467



The
ServiceOperation

Artifact Type represents the specific operation pe
rformed by the Service.
468

The
operationDefinedBy

Modeled Relationship can be used to link a
ServiceOperation

with a
469

Derived Artifact which defines it. For example this could be an
Operation

artifact instance from
470

the WSDL Model.

471


472

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
17

of
61


2.4

Derived Models

473

The sections that follow describe the logical models that are constructed by the repository in response to
474

publication of a document for which a Derived Model is defined. The server parses these documents
475

upon publication, dynamically constructing Derived

Artifacts corresponding to the major data type
476

components of the document. Every Derived Artifact instance has a
relatedDocument

relationship to the
477

document from which it was created. The artifacts and relationships in a Derived Model provide a
478

powerful

tool for searching the repository based on specific components of such a document (e.g., a
479

WSDL PortType, etc.). In most cases, the UML model diagrams illustrated in this section are adequate to
480

define the Artifact Types and the Derived Relationships bet
ween them, so these sections are
481

correspondingly brief.

482

Appendix
H

describes all of the Derived Model schemas defined in S
-
RAMP.

483

2.4.1

The Policy Model

484

The Policy Model d
escribes the Artifact Types that correspond to the primary components of a WS
-
Policy
485

document. Policy expressions can be in a standalone policy document, or embedded in another
486

document such as a WSDL.
Figure
5

below is a conceptual UML based illustration of the Policy Model:

487


488

Figure
5
: Conceptualized UML Model of Policy Model Artifacts

489


490

All
appliesTo

relationships are instantiated in the repository based on the content in the policy attachment
491

document. There is no restriction on the artifacts it can reference.

492

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
18

of
61



493

2.4.2

The XSD Model

494

The XSD Model describes the Artifact Types that correspond to components o
f an XSD document stored
495

in the repository, and yields structural metadata useful in performing queries. The conceptual UML model
496

describing the XSD Model is illustrated in
Figure
6
.

497


498


499


500


501

Figure
6
: Conceptualized UML Model of XSD Model Artifacts

502

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
19

of
61


Note that an XSD document MAY include, import, or redefine other XSD documents. These capabilities
503

are modeled using the
includedXsds
,
importedXsds

and
redefinedXsds

Derived Relationships,
504

respectively.

505

A
SimpleTypeDeclaration

artifact instance is generated for each global simple type defined in the
506

associated XML Schema document. Similarly, a
ComplexTypeDefinition

instance is generated for each
507

glo
bal complex type defined in that XML Schema document. Each global attribute declared in the XML
508

Schema document will generate a corresponding
AttributeDeclaration

artifact instance, and finally, each
509

global element declared in the XML Schema document will

generate a corresponding
ElementDeclaration

510

artifact instance.

511

While it is possible to construct a more fine
-
grained model of an XML Schema document, this level of
512

modeling provides a suitably rich context for discovery queries without creating an overly
complex model.

513

2.4.3

The WSDL Model

514

The WSDL Model is one of the most complex Derived Models, owing to the complexity of WSDL itself.
515

The WSDL Model contains substantial richness because of the value in being able to perform highly
516

refined queries using logical

artifact representations of most of a WSDL document’s constituent
517

components.

518

Figure
7

and
Figure
8

below provides a conceptual UML model representing the logical artifacts and their
519

Derive
d Relationships in the WSDL Model. This model is intended to mirror the structure of a WSDL file.
520

In most cases, the artifact names exactly match corresponding data types in WSDL (e.g.,
Message,
521

PortType, Operation, Binding, Service, Port
, and so on).

These figures are actually one diagram
522

presented in two pieces for legibility.

523

Note that aggregation relationships in these diagrams are modeled as Derived Relationships in the WSDL
524

Model schema found in Appendix
H.3
.

525

Note that the WsdlExtension Artifact Type illustrated in
Figure
8

below is used to model extensibility
526

elem
ents for any given WSDL element. This supports WSDL extensions that the repository does not
527

recognize.

528


529

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
20

of
61



530


531

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
21

of
61


Figure
7
: Conceptual UML Diagram of WSDL Model: Part 1

532

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
22

of
61



533

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
23

of
61


Figure
8
: Conceptual UML Diagram of
WSDL Model: Part 2

534

The WsdlDerivedArtifactType is a modeling convenience from which all WSDL related metadata artifacts
535

extend. It contains a
namespace

attribute that is the namespace of the WSDL document and it applies to
536

every Derived Artifact instance
for that Document. It also has an
extension

Derived Relationship which
537

serves to identify the set of WSDL extensions which apply to the Derived Artifact.

538

Figure
9

bel
ow illustrates a conceptual UML model representing the portions of the WSDL Model that
539

describe the relevant document artifacts and Derived Relationships for the associated WSDL document.
540

A WSDL document can import, include and redefine XSD document(s), a
s well as import other WSDL
541

documents. Similarly, an XSD document can import, include and redefine other XSD documents. The
542

model supports each of these capabilities with the Derived Relationships shown in the diagram.

543


544



545


546

Figure
9
: Conceptual UML Diagram of WSDL Model: Part 3

547

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
24

of
61



548

2.4.4

The SOAPWSDL Model

549

The SOAPWSDL Model contains the SOAP 1.1 binding specific WSDL Model artifacts for WSDL 1.1. It is
550

separated into its own Model and schema to simplify its use.
Figure
10

below illustrates a conceptual
551

UML model of the relevant SOAP WSDL Model artifacts.

552


553


554

Figure
10
: Conceptualized UML Diagram of the SOAP WSDL Model

555


556

2.5

Referencing S
-
RAMP Artifacts

557

This section describes the syntax for referencing Artifact Type(s) in the S
-
RAMP bindings. The use of the
558

references described in this section to operate on S
-
RAMP artifacts is specific to the binding used (e.g.,
559

the S
-
RAMP Ato
m Binding). Please refer to the appropriate binding specific document of this
560

specification for details.

561

The following referential syntax applies:

562


563

/s
-
ramp/{ArtifactModel}/{ArtifactType}

564


565

Note that each successive component of this syntax is optional. Sp
ecifically

566



A reference of “/s
-
ramp” refers to all Artifact Types in all models

567



A reference of “/s
-
ramp/{Artifact Model}” refers to all Artifact Types within the specified Artifact
568

Model.

569



Refer
ences of the form

“//{ArtifactModel}” or “//{ArtifactType}” ar
e also permitted.

570

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
25

of
61



571

Table
6

below provides the valid values for Artifact Model and Artifact Types. Abstract types are not
572

included since they cannot be instantiated.

573


574

Table
6
: Artifact Models and Types

575

Artifact Model

Artifact Type

core

Document

XmlDocument

xsd

XsdDocument

AttributeDeclaration

XsdType

ElementDeclaration

SimpleTypeDeclaration

ComplexTypeDeclaration

policy

PolicyDocument

PolicyExpression

PolicyAttachment

soapWsdl

SoapAddress

SoapBinding

wsdl

WsdlDocument

WsdlService

Port

WsdlExtension

Part

Message

Fault

PortType

Operation

OperationInput

OperationOutput

Binding

BindingOperation

BindingOperationInput

BindingOperationOutput

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
26

of
61


BindingOperationFault

serviceImplementation

Organization

ServiceEndpoint

ServiceInstance

ServiceOperation

user

{User Defined Artifact Type}

soa

{See The Open Group’s SOA Ontology
for the normative list of
Artifact names. They are reproduced here for clarity.}

HumanActor

Choreography

ChoreographyProcess

Collaboration

CollaborationProcess

Composition

Effect

Element

Event

InformationType

Orchestration

OrchestrationProcess

Policy

PolicySubject

Process

Service

ServiceContract

ServiceComposition

ServiceInterface

System

Task


576

Below are some examples of valid S
-
RAMP model and Artifact Type references.

577


578

Example
1
: Artifact Model and Type References

579

/s
-
ramp

580

o

References all Artifact Types in the repository

581

/s
-
ramp/xsd

or

//xsd

582

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
27

of
61


o

References all Artifact Types in the XSD Model (e.g.,
XsdDocument
,
XsdType
, …)

583

/s
-
ramp/xsd/XsdType

or

//XsdType

584

o

References the XsdType A
rtifact Type in the XSD Model

585

/s
-
ramp/soa/Service

586

o

References all
Service

Artifacts Types in the SOA Model (included by reference to
587

The Open Group’s SOA Ontology)

588

/s
-
ramp/wsdl/Port

589

o

References the Port Artifact Type in the WSDL Model

590


591


592


593


594


595

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
28

of
61


3

Classification
Systems in S
-
RAMP

596

A classification system allows classification values to be organized in a hierarchy, allowing artifacts to be
597

grouped into sets and to identify subsets within those sets. Query and display of all artifacts in a set then
598

becomes possible a
nd provides a simple yet powerful means of classifying and finding related objects.
599

Artifact instances in the repository MAY have classification values applied to them.

600

A simple example of a classification system hierarchy is a geographical region hierarch
y that could, for
601

example, be used to indicate which location produced an artifact. Using '/' to delineate levels in the
602

hierarchy and ',' to separate members at the same level, one part of an example hierarchy could be World
603

/ Asia / Japan, China. The hie
rarchy could also contain World / Europe / United Kingdom, Germany. In
604

other words, subsets of World are Asia and Europe, subsets of Asia are Japan and China, and subsets of
605

Europe are United Kingdom and Germany. To find artifacts produced by teams in Asia
, a search can be
606

issued to return artifacts classified by the Asia classification. To give the behavior desired, a repository
607

implementation interprets this query as requiring the retrieval of artifacts classified by Asia and its sub
-
608

groups i.e. Asia or J
apan or China.

609

Classification systems used in S
-
RAMP are expressed in the Web Ontology Language (OWL) that builds
610

upon the Resource Description Framework (RDF). The RDF/XML serialization format is commonly used
611

for files containing OWL constructs and is a
format that SHALL be understood by an S
-
RAMP repository.
612

OWL consists of three increasingly expressive sublanguages, OWL Lite, OWL DL and OWL Full. The
613

W3C "OWL Web Ontology Language Overview" document indicates that "OWL Lite supports those users
614

primaril
y needing a classification hierarchy and simple constraints", and accordingly the OWL elements
615

that S
-
RAMP uses to define classification systems come from OWL Lite. To enable the classification
616

capabilities required in S
-
RAMP, a restricted set of OWL Lite
elements is sufficient. Also, it should be
617

noted that multiple inheritance will not be supported in S
-
RAMP.

618

The elements that SHALL be supported and a brief description of each follow (refer to the W3C
619

documents detailing OWL and RDF for further detail o
n these elements).

620


621

rdf:ID

622



In an element that requires a resource to be identified, an
rdf:ID

attribute MAY be used. This
623

attribute has slightly different behavior to
rdf:about
, including the requirement that the value only
624

appear once in the scope of a d
ocument, so it provides a useful check when defining distinct
625

resources. RDF and OWL use URIs to identify resources. The attribute value is a string indicating
626

a URI fragment relative to the currently in
-
scope base value (typically set using the xml:base
627

a
ttribute).

628

rdf:about

629



As an alternative to using an
rdf:ID
attribute to identify a resource, an
rdf:about

attribute MAY be
630

used. The attribute value is either a string indicating an absolute URI, or a string indicating a
631

relative URI resolved against the currently in
-
scope base value (typically set using the xml:base
632

attribute).

633

owl:Ontology

634



In OWL, classific
ation systems are represented by an OWL ontology. The ontology groups a
635

number of related classifications together. In the example the geographical regions classification
636

system would be defined using an
owl:Ontology

element.

637

owl:Imports

638



owl:Imports elemen
ts are permitted under owl:Ontology. This means that classes declared in the
639

ontology MAY subclass classes declared in any imported ontologies, although multiple
640

inheritance is not permitted. How owl ontologies are imported is vendor specific and therefo
re the
641

resolution of owl:import references is also vendor specific.

642

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
29

of
61


owl:Class

643



OWL represents classifications with OWL classes. In the example, the World, Europe, Asia,
644

United Kingdom, Germany, Japan and China classifications would be defined using an
owl:C
lass

645

element.

646

rdfs:subClassOf

647



To define the hierarchy, classes are related to each other via the
rdfs:subClassOf

element. If
648

class B is declared to be a subclass of class A, then the instances of class B represent a subset
649

of the instances of class A. In the example, Asia would be declared to be a subclass of World,
650

Japan a subclass of Asia, and so on.

651

rdfs:label

652



On
tologies and classes MAY be given a human readable name using the
rdfs:label

element.
653

Names in multiple languages are supported by this element, using the xml:lang attribute.

654

rdfs:comment

655



Ontologies and classes MAY be given a human readable comment or desc
ription using the
656

rdfs:comment

element. Comments in multiple languages are also supported by this element using
657

the xml:lang attribute.

658


659

All other OWL elements are not supported (in terms of OWL Lite this means that property
-
related
660

elements, and the
owl:e
quivalentClass
,
owl:imports
,
owl:intersectionOf
, and versioning elements are not
661

supported).

662

OWL files used in S
-
RAMP MUST conform to the following rules, which result in ontologies that are self
-
663

contained in a single OWL file:

664



There MUST be exactly one
ow
l:Ontology

element in any OWL file

665



A class MUST only be defined in one ontology

666

The example ontology can be expressed in OWL as follows:

667


668

Example
2
: An OWL Ontology

669

<?xml version="1.0" encoding="UTF
-
8"?>

670


671

<!DOCTYPE rdf:RDF [

672


<
!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">

673


<!ENTITY rdf "http://www.w3.org/1999/02/22
-
rdf
-
syntax
-
ns#">

674


<!ENTITY rdfs "http://www.w3.org/2000/01/rdf
-
schema#">

675


<!ENTITY owl "http://www.w3.org/2002/07/owl#">

676


<!ENTITY ns_region "http://www.region
s.com/geographicalregion">

677

]>

678


679

<rdf:RDF

680


xmlns:xsd="&xsd;"

681


xmlns:rdf="&rdf;"

682


xmlns:rdfs="&rdfs;"

683


xmlns:owl="&owl;"

684


xmlns:ns_region="&ns_region;"

685


xml:base="&ns_region;"

686

>

687


688


<!
--

ontology
--
>

689


690


<owl:Ontology rdf:ID="">

691


<rdfs:label>
Geographical Regions</rdfs:label>

692


<rdfs:comment>An ontology used to provide classifications describing geographical
693

regions.</rdfs:comment>

694


</owl:Ontology>

695


696


<!
--

root class
--
>

697


698

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
30

of
61



<owl:Class rdf:ID="World">

699


<rdfs:label>World</rdfs:label>

700


<r
dfs:label xml:lang="en">World</rdfs:label>

701


<rdfs:label xml:lang="fr">Monde</rdfs:label>

702


</owl:Class>

703


704


<!
--

sub classes
--
>

705


706


<owl:Class rdf:ID="Asia">

707


<rdfs:subClassOf rdf:resource="&ns_region;#World"/>

708


<rdfs:label>Asia</rdfs:label>

709


</ow
l:Class>

710


711


<owl:Class rdf:ID="Europe">

712


<rdfs:subClassOf rdf:resource="&ns_region;#World"/>

713


<rdfs:label>Europe</rdfs:label>

714


</owl:Class>

715


716


<!
--

sub sub classes
--
>

717


718


<owl:Class rdf:ID="Japan">

719


<rdfs:subClassOf rdf:resource="&
ns_region;#Asia"/>

720


<rdfs:label>Japan</rdfs:label>

721


</owl:Class>

722


723


<owl:Class rdf:ID="China">

724


<rdfs:subClassOf rdf:resource="&ns_region;#Asia"/>

725


<rdfs:label>China</rdfs:label>

726


</owl:Class>

727


728


<owl:Class rdf:ID="UnitedKingdom">

729


<rdfs:subC
lassOf rdf:resource="&ns_region;#Europe"/>

730


<rdfs:label>United Kingdom</rdfs:label>

731


</owl:Class>

732


733


<owl:Class rdf:ID="Germany">

734


<rdfs:subClassOf rdf:resource="&ns_region;#Europe"/>

735


<rdfs:label>Germany</rdfs:label>

736


</owl:Class>

737


738

</rdf:RDF>

739


740


741

Some points of interest in the foregoing example:

742



An
rdfs:comment

element is shown within the Geographical Regions
owl:ontology

element, but
743

comments may be used in
owl:Class

constructs if desired.

744



rdfs:label

elements have generally been used with no xml:
lang attribute specified. However,
745

multiple
rdfs:label

elements MAY be specified within an
owl:Ontology

or
owl:Class

element, and
746

these may contain a variety of xml:lang attribute values (and an

rdfs:label
element with no
747

xml:lang attribute may be specifie
d in addition to elements with such attributes present). The
748

World class in the ontology listed in Example 2 illustrates this. An
owl:Ontology

or
owl:Class

749

element SHOULD contain only one
rdfs:label

element with a given xml:lang value to ensure well
-
750

define
d behavior when requesting a label for a specific language.

751



The behavior of
rdfs:comment

elements with respect to xml:lang attributes is identical to the
752

behavior for
rdfs:label

elements.

753



Although the example shows a single root class which the other class
es’ subclass either directly
754

or indirectly, multiple root classes are permitted in an ontology. Also permitted are stand
-
alone
755

classes that neither subclasses some parent class nor are themselves parents to other child
756

classes.

757



Multiple inheritance (a clas
s being a subclass of multiple parent classes) is NOT permitted.

758


759

s
-
ramp
-
foundation
-
v1.0
-
wd01

Working Draft

26 January 2011

Copyright
©

O
ASIS® 2010
. All Rights Reserved.

Standards Track Work Product

Page
31

of
61


4

S
-
RAMP Query Model

760

The S
-
RAMP specification supports a robust query interface that compliant implementations MUST
761

support. It provides a way to find repository artifacts using a rich set of

762

constraints. The query expression in S
-
RAMP uses an XPath 2.0 based dialect.
763

Refer to Section
4.4

for additional information on the S
-
RAMP query grammar.
764

The exp
ression predicates act as filters to identify matching artifact instances.
765

Filtering can be done based upon artifact metadata, including properties,
766

relationships and classifications. Complex criteria can be formed. One can for
767

example, search for “all
services which are categorized as being in production”,
768

or find “all the XML Schema documents which are referenced by any WSDL
769

document”, and so on. Queries are executed against a set of S
-
RAMP artifacts
770

using the criteria provided and the result returned

is a set of S
-
RAMP artifacts.
771

Furthermore, all artifact types both concrete and abstract are eligible for use in
772

the query expressions.

773

Specific request and response syntax for executing query requests is, however, binding specific.
774

Details can be fou
nd in the relevant binding document(s) of this specification.
775

This document covers the common features of an S
-
RAMP query, independent
776

of their invocation syntax

777

4.1

Query Dialect (XPath2) Context

778

Since the S
-
RAMP query model is based on XPath2
[XPATH]
, this specification defines a static context
779

for the information available during static analysis of a query expression prior to its evaluation, as well as