a metamodel for the web services standards
TRANSCRIPT
J Grid Computing (2013) 11:735–752DOI 10.1007/s10723-013-9273-4
A Metamodel for the Web Services Standards
Balazs Simon · Balazs Goldschmidt ·Karoly Kondorosi
Received: 7 February 2012 / Accepted: 29 August 2013 / Published online: 21 September 2013© Springer Science+Business Media Dordrecht 2013
Abstract Web services provide distributed com-munication in a platform independent way. TheWS-* standards define how middleware aspects(security, reliability, transactions, etc.) can be re-alized through web services. Although the WS-Policy standard family can be used to configurethe various WS-* protocols, they are very hard toconstruct and to maintain manually. In addition,most SOA products and Grid systems implement-ing these standards provide their own methodsfor configuring these protocols, making it verydifficult to match the various configuration op-tions of different products. This fact inspired usto propose a platform independent metamodelfor describing distributed systems of web servicesincluding the most important WS-* standards.The present article defines the full metamodel,it specifies the corresponding programming lan-guage formally, and it shows the productivityof the framework built around the metamodelthrough real-life examples. The framework is ca-
B. Simon (B) · B. Goldschmidt · K. KondorosiDepartment of Control Engineering and InformationTechnology, Budapest University of Technologyand Economics, Budapest, Hungarye-mail: [email protected]
B. Goldschmidte-mail: [email protected]
K. Kondorosie-mail: [email protected]
pable of generating product specific configurationfiles and source codes, resulting in directly in-teroperable applications even between differentSOA products. The framework could also pro-mote interoperability with Grid systems built onWS-* protocols.
Keywords Web services · WS-* standards ·WS-Policy · Metamodeling
1 Introduction
Web services realize distributed communicationin a platform independent way by building everyrelating standard on XML. The communicationprotocol (SOAP), the interface description language(WSDL) and the middleware aspects (called WS-*standards: WS-Addressing, WS-ReliableMessaging,WS-Security, WS-SecureConversation, etc.) areall represented in XML. These middleware as-pects can also be configured in a platform inde-pendent way through XML chunks called WS-Policy assertions which are usually included in theWSDL. The primary intent of the use of XMLfor communication is to promote interoperabilitybetween different platforms. This is beneficial forthe products of different software vendors andalso for Grid systems.
However, the major drawback of the WS-Policystandard family is that the policy assertions of
736 B. Simon et al.
the WS-* standards can be very large XML struc-tures which makes them nearly impossible to behandwritten by humans. Luckily, most SOA prod-ucts provide policy repositories (e.g. Oracle SOASuite, IBM WebSphere) containing complete as-sertions that can be used for configuration. How-ever, these assertions may be different in differentproducts and matching them can be a difficulttask. There are also products which offer GUIdesigners (e.g. GlassFish ESB) or transform WS-Policy assertions into their own configuration rep-resentation (e.g. Apache CXF, Microsoft WCF)making interoperability more problematic. Secu-rity mechanisms in Grid systems are also verytedious to set up and not user friendly [3].
These problems inspired us to create a plat-form independent metamodel for describing dis-tributed systems built from web services and also aplatform independent programming language forconfiguring such distributed systems. There arepropositions to use UML for this task [8, 12], butUML itself is not suitable, since it lacks most ofthe concepts of the WS-* standard family evenwhen it is extended with stereotypes [9, 10, 23].However, it is much better to have a domainspecific language designed particularly for webservices. Therefore, we have created such a meta-model, it is called SoaMM (SOA Metamodel). Italso has a textual concrete syntax called SOAL(SOA Language), which is essentially a program-ming language for describing distributed systemsof web services. We have also written a compilerthat transfoms SOAL descriptions into models(instances of the SoaMM metamodel), and alsoa code generator that produces program codesand platform specific configuration files to imple-ment the described system in the various SOAproducts. The produced artifacts provide consis-tent configurations between the different SOAproducts resulting in immediately interoperableapplications. We also intend to extend the frame-work to support platform independent modelingof Grid systems [4, 22]. Remote calls betweendifferent Grid-enabled job scheduling systems [14,21] can also be implemented easier by such aframework.
In previous conference proceedings we havealready published [28, 29] some parts of this meta-model. The present article describes the full
metamodel including the security aspects, it alsospecifies the corresponding programming lan-guage formally, and it shows the productivityof the framework built around the metamodelthrough real-life examples. The second sectiongives a brief overview of the WS-* protocols whichare most widely implemented in SOA products,and are also supported by our framework. Thethird section covers the related work in mod-eling web services. The fourth section containsthe description of the SoaMM metamodel. Thefifth section shows an example how easily theproposed metamodel and programming languagecan be used to implement a WS-Trust scenario,which is usually a very complicated task. The sixthsection evaluates the productivity of our frame-work through real-life examples. The last sectionconcludes the article and lists the possible futuredirections. The formal specification of the SOALlanguage can be found in Appendix A, and anexample is shown in Appendix B.
2 The Covered WS-* Protocols
The most widely implemented WS-* proto-cols are WS-Addressing, WS-ReliableMessaging,WS-Security, WS-SecureConversation and WS-AtomicTransaction. The Microsoft .NET Frame-work, the GlassFish server, the IBM WebSphereserver and the Apache CXF framework sup-port most of them. The difference between theseframeworks is in the configuration of these proto-cols. Our framework is designed to provide a com-mon platform independent configuration for thesestandards to be able to generate product specificconfiguration files from the platform independentdescription.
There are many other WS-* protocols. How-ever, the most widely used commercial SOA prod-ucts do not implement them; therefore, we alsoomitted them from our framework. Support forthese protocols can be easily added later sinceextensibility was one of the most important designprinciples of our framework.
Figure 1 shows the general architecture ofweb services stacks. The Windows Communica-tion Foundation (WCF) [18] stack (part of theMicrosoft .NET framework) and the Metro [24]
A Metamodel for the Web Services Standards 737
Transport(HTTP, JMS, etc.)
Encoding(SOAP, MTOM)
Protocols(WS-RM, WS-S, etc.)
Client
Network
Transport(HTTP, JMS, etc.)
Encoding(SOAP, MTOM)
Protocols(WS-RM, WS-S, etc.)
Service
Fig. 1 Typical architecture of web services stackimplementations
stack (the reference implementation of JAX-WS)follow this structure, and other framework imple-mentations can also be modeled this way. The net-work is at the bottom, it is used for sending bytesfrom one end to the other. The network protocolfor web services is usually HTTP, but it can be re-placed with other protocols. The transport layer isresponsible for handling the network protocol. Onthe service side it waits for client connections, onthe client side it connects to services. It also trans-fers bytes between the two participants. The en-coding layer translates between bytes and a frame-work specific message object representation, i.e. itis responsible for serialization and deserialization(e.g. into SOAP, with or without MTOM). Thetransport and encoding layers are always manda-tory. The protocol layers are optional, and theyimplement the various WS-* standards (e.g. WS-ReliableMessaging, WS-Security, etc.).
3 Related Work
Our goal is to give a platform independent meta-model and a human readable textual concretesyntax for describing web services including theWS-* standards. There have been a number ofsimilar approaches published; however, none ofthem provide such a comprehensive and intuitivesolution, as ours. Table 1 summarizes the relatedworks in this topic. The first column lists thevarious approaches. The remaining columns aretarget (the target of the approach), WS-* (whetherthe approach supports WS-* protocols), meta-model (the metamodel of the model defined inthe approach), modeling language (the modelinglanguage used in the approach), textual language
(the textual concrete syntax for the model) andplatform (the supported platforms).
One of the most obvious ways to model webservices is through UML. Gronmo et al. [12] rec-ommend using solely the semantics of UML with-out additional WSDL-specific stereotypes. Theystate that this method enhances the understandingand efficiency of service modeling. It can be truefor simple services, however, the WS-* protocolscannot be modeled by pure UML concepts. DeCastro et al. [8] propose an extension to UMLinstead. They define a number of stereotypes thatcan be used to annotate UML elements. Althoughthis approach is much more suitable for modelingthe details of the web services domain, they definetoo low level stereotypes (e.g. «definition»and «message» are unnecessary) and they donot model the WS-* standards either. There arealso other similar proposals that not only includeweb services but also their interactions [9, 10];however, they also lack the support of the WS-*protocols.
Wada et al. [35, 36] have the closest approachto ours. They recommend using UML with stereo-types to model Service Oriented Architecturesand also Service Oriented Grids. They have avery detailed UML profile which can describea lot of middleware aspects of SOA systems,however, more advanced security protocols suchas WS-SecureConversation, WS-Trust and WS-Federation are not supported. There is no directmapping defined between their model elementsand the policies of WS-* protocols, and they leavethe implementation of some aspects to customlibraries extending existing products. They do not(yet) support the SOA products of importantvendors like Microsoft, IBM, Oracle or RedHat.Their solution also lacks a textual language fordescribing SOA systems.
There is also a SOA Modeling Language [23]from OMG which also extends UML with stereo-types in order to be able to describe SOA systems.It is suitable for conceptual modeling of servicesand their interactions, but the middleware aspectsnecessary for the WS-* standards are completelymissing.
Jegadeesan and Balasubramaniam [15] defineda SOA metamodel based on MOF 2. This is a verydetailed metamodel, and it is capable of describing
738 B. Simon et al.
Tab
le1
Com
pari
son
ofth
ere
late
dw
orks
App
roac
hT
arge
tW
S-*
Met
amod
elM
odel
ing
lang
uage
Tex
tual
lang
uage
Pla
tfor
m
Gro
nmo
etal
.[12
]Se
rvic
esN
oU
ML
met
amod
elU
ML
Non
eIn
depe
nden
tD
eC
astr
oet
al.[
8]Se
rvic
esN
oU
ML
met
amod
elU
ML
wit
hst
ereo
type
sN
one
Inde
pend
ent
Dum
ezet
al.[
9]Se
rvic
es,i
nter
acti
onN
oU
ML
met
amod
elU
ML
wit
hst
ereo
type
sN
one
Inde
pend
ent
Elg
amm
alan
dSe
rvic
es,i
nter
acti
onN
oU
ML
met
amod
elU
ML
wit
hst
ereo
type
sX
ML
Inde
pend
ent
El-
Shar
kaw
i[10
]W
ada
etal
.[35
,36]
Serv
ices
,mid
dlew
are
Not
dire
ctly
UM
Lm
etam
odel
UM
Lw
ith
ster
eoty
pes
Non
eIn
depe
nden
tas
pect
sSO
AM
L[2
3]Se
rvic
esN
oU
ML
met
amod
elU
ML
wit
hst
ereo
type
sN
one
Inde
pend
ent
Jega
dees
anan
dSe
rvic
esN
oSe
rvic
em
etam
odel
Serv
ice
mod
elN
one
Inde
pend
ent
Bal
asub
ram
ania
m[1
5]in
MO
F2
Pip
rani
etal
.[25
]B
usin
ess
proc
esse
sN
oIS
O19
763-
5IS
O19
763-
5m
odel
Non
eIn
depe
nden
tin
OR
MC
aoet
al.[
6]Se
rvic
esN
oN
one
ER
DN
one
Inde
pend
ent
Qaf
mol
laan
dSe
rvic
esN
oK
erm
eta
(EM
F)
EM
Fm
odel
Non
eIn
depe
nden
tN
guye
n[2
6]SA
WSD
L[3
4]O
ntol
ogic
alco
ncep
tsN
oN
one
Non
eW
SDL
exte
nsio
n,In
depe
nden
tR
DF
OW
L-S
[33]
Serv
ices
,non
-fun
ctio
nal
Not
dire
ctly
OW
Lm
etam
odel
OW
Lm
odel
OW
Lla
ngua
geIn
depe
nden
tas
pect
sW
SMO
[11]
Serv
ices
,non
-fun
ctio
nal
Not
dire
ctly
WSM
Oin
MO
F2
WSM
Om
odel
WSM
LIn
depe
nden
tas
pect
sK
olov
skie
tal.
[17]
Pol
icy
mat
chin
gN
oO
WL
met
amod
elO
WL
mod
elO
WL
lang
uage
Inde
pend
ent
Ver
ma
etal
.[32
]P
olic
ym
atch
ing
No
OW
Lm
etam
odel
OW
Lm
odel
OW
Lla
ngua
geIn
depe
nden
tSr
ihar
eeet
al.[
31]
Serv
ice
disc
over
yN
oO
WL
met
amod
elO
WL
mod
elO
WL
lang
uage
Inde
pend
ent
Cha
rfie
tal.
[7]
WS-
*fo
rB
PE
LY
esN
one
Non
eX
ML
Act
iveB
PE
LX
AC
ML
[19]
Pol
icy
inte
rpre
tati
onY
esN
one
Non
eX
ML
Inde
pend
ent
WSP
L[1
,20]
Pol
icy
mat
chin
gY
esN
one
Non
eX
ML
Inde
pend
ent
WS-
Pol
icy-
Pol
icy
mat
chin
gY
esN
one
Non
eX
ML
,sim
ple
text
Inde
pend
ent
Con
stra
ints
[2]
Our
appr
oach
Serv
ices
,WS-
*,Y
esSo
aMM
inM
OF
2So
aMM
mod
elSO
AL
Inde
pend
ent
mid
dlew
are
aspe
cts
A Metamodel for the Web Services Standards 739
a lot of aspects of web services. However, theyonly support the simple WS-Policy standard, andthey did not include model elements and seman-tics for WS-* protocols.
Piprani et al. [25] published a metamodel fordescribing deliverable Services Oriented Archi-tecture containing control sequence models, eventmodels, and bridges to associated data models orweb services. The focus of their work is to modelprocess control sequences and events so that theinner details of the processes can be reused. Thismay be beneficial for reducing the implementa-tion cost of services; however, their solution alsolacks middleware aspects.
Cao et al. [6] proposed a domain specific MDAapproach to model web services through EntityRelationship diagrams. This solution follows simi-lar principles as ours, however, their metamodel istoo simple and it does not cover WS-* protocols.Another problem with their approach is that theymix meta levels on the same diagram. E.g. Web-Service, portType, operation and binding shouldappear at the meta-model level, while BankAc-count, withdraw, transfer, etc. should be at themodel level.
Qafmolla and Nguyen [26] also used MDAprinciples to generate WSDL, XSD files and Javacode for web services from program codes de-scribed by a simple and very readable relationaldatabase description language called Kermeta.Unfortunately, the sample they included in thepaper contained a relational database descriptioninstead of a desription for web services. Hence,it is not very clear how they would use Kermetafor web services. They also omitted the WS-*protocols.
Another way of describing services is usingsemantic web technologies. The major goal ofSemantic Web Services (SWS) is to create intel-ligent software agents to provide automated, in-teroperable and meaningful coordination of webservices [16]. The three main directions of SWSare SAWSDL, OWL-S and WSMO.
SAWSDL [34] does not introduce a new lan-guage. It is a WSDL extension for referencingontological concepts outside WSDL documents.Beyond that it does not define any execution se-mantics for the implementation.
The OWL-S [33] profile ontology is used todescribe what a service does, and is meant to bemainly used for the purpose of service discov-ery. The service description contains input andoutput parameters, pre- and post-conditions, andalso non-functional aspects. The OWL-S processmodel describes service composition includingthe communication pattern. In order to connectOWL-S to existing web service standards, OWL-S uses grounding to map service descriptions toWSDL. The OWL-S environment provides aneditor to develop semantic web services and amatcher to discover services. The OWL-S VirtualMachine is a general purpose web service clientfor the invocation. OWL-S therefore requires acustom execution environment and cannot beused in current commercial SOA products. Itsunderlying description logic OWL-DL has also alimited expressiveness in practice.
The WSMO [11] framework provides a con-ceptual model and a formal language WSML forsemantic markup of web services. WSMO is usedfor modeling of ontologies, goals, web servicesand mediators. Ontologies provide formal logic-based grounding of information used by othercomponents. Goals represent user desires, i.e. theobjectives that a client might have when searchingfor services. Web services are computational enti-ties, their semantic description includes functionaland non-functional properties, as well as theircapabilities through pre- and post-conditions, as-sumptions and effects. Mediators provide inter-operability between components at data, protocoland process level. The reference implementationof WSMO is the WSMX [13] framework, a customexecution environment. It is designed to allowdynamic discovery, invocation and composition ofweb services. It also provides interoperability withclassical web services.
The main design goals of SWS standards arediscovery, invocation and composition of web ser-vices. These standards are not primarily designedfor modeling purposes. They are weak in terms ofsecurity, transactional, reliability and other non-functional aspects even at the conceptual level[27]. Because of their custom execution environ-ment, their implementations do not rely on ex-isting SOA products of major software vendors,
740 B. Simon et al.
which can result in interoperability problems withclassical web services published by these products.
Although there are directions to extend SWSstandards with WS-Policy concepts [17, 31, 32],these solutions focus on service discovery and pol-icy matching, and do not resolve the issues relatedto modeling and implementation.
Most BPEL workflow engines in the industryalso lack support of the specification and en-forcement of non-functional requirements. Charfiet al. [7] proposed and implemented a containerframework to include the most important WS-*standards regarding security, reliability and trans-action handling in BPEL processes. However,their solution can only be used in the ActiveBPELengine, and cannot be applied to other industryengines.
Others focus their research on creating plat-form independent languages for describing WS-Policy assertions. These efforts come togetherunder the umbrella of XACML [19] (eXtensi-ble Access Control Markup Language). XACMLis a declarative access control policy languageimplemented in XML and a processing model,describing how to interpret the policies. WSPL[1, 20] (Web Services Policy Language) is a sub-set of XACML and is designed for matchingpolicy descriptions. WS-PolicyConstraints [2] isan even smaller subset of WSPL with the partsof WSPL that overlapped and conflicted withWS-Policy and WS-PolicyAttachment removed.Although these XACML-based solutions are plat-form independent, they are too complex and havean unfriendly XML syntax. Their current tool sup-port is also very poor and they cannot be used formodeling.
WS-Policy and XACML provide expressionsto specify different configurations of policy as-sertions; however, most SOA products supportonly a single configuration option per end-point. Different configurations are published ondifferent endpoints. Hence, there is usually noneed to dynamically choose between options; tobe able to specify the exact same configurationon the client and server side between differentproducts is a more important task in practice.
4 Metamodel for the WS-* Standard Family
Since almost every web services framework usesa different kind of configuration format it is veryhard to match the options of the different frame-works. That is why we decided to create a commonmetamodel for the WS-* standard family in orderto be able to model the services in a platformindependent way. From this model the platformdependent configurations of the various frame-works is automatically generated.
This section specifies the SoaMM metamodelwhich can be used for modeling distributed ser-vices in a platform independent way. The meta-model is capable of describing simple and complextypes, interfaces of services and middleware as-pects including addressing, reliability, transactionsand security.
Figure 2 shows the architecture of the SoaMMmetamodel. Most of the WSDL parts are mappedto the SoaMM metamodel. The only exception isthe message part which is a redundant elementin the WSDL description; therefore, it is omitted
Fig. 2 Architecture ofthe SoaMM metamodel types
interfaces transportnamespaces
WS-Addressing
claims
bindings
endpoints
encoding
protocols
WS-ReliableMessaging
WS-Security
WS-SecureConversation
WS-AtomicTransaction
A Metamodel for the Web Services Standards 741
from the SoaMM metamodel. All the other parts(types, portType, bindings and endpoints) areincluded in SoaMM and there is an additionaldeclaration for modeling claims to support claimsbased identity. Bindings define the transport,the encoding and the WS-* protocols to be used.The supported protocols are WS-Addressing,WS-ReliableMessaging, WS-Security, WS-SecureConversation, WS-AtomicTransaction.The remaining parts of this section show howthe elements in Fig. 2 are defined in the SoaMMmetamodel.
We also created a simple programming lan-guage called SOAL which provides a textual con-crete syntax for the SoaMM metamodel. This lan-guage has a similar syntax to C# and Java, butit is specific to the SoaMM domain. The formalspecification of the SOAL language can be foundin Appendix A.
Figure 3 shows the possible declaration ele-ments of SoaMM. SoaMM supports namespacesto avoid name collisions. Namespaces can be hi-erarchical; therefore, a Namespace can containother Namespace declarations. A Type is a sim-ple or complex type which constraints the val-ues represented by variables. The Claims ele-ment is a list of claim definitions used in claimsbased identity management. These claims can bemapped to SAML attributes and WS-Feredationclaims. An interface is a collection of operationsprovided by a service, and is described by theInterface element (this is the portType ele-ment in the WSDL). Middleware aspects and pro-tocol configurations are specified in the Bindingelement. The Endpoint element represents aservice running on a specific location (this is theservice element in the WSDL).
The SoaMM modeling language has a strongtype system shown in Fig. 4. A type can be eithera simple type (SimpleType), a wrapper type(WrapperType) or a complex type (Complex-Type). Simple types are either built-in types(BuiltInType) commonly used in most pro-gramming languages (int, double, string, etc.) orenumeration types (EnumType) with a fixed setof values (EnumValue). Wrapper types are con-structed from primitive types by adding some newbehavior. Such a wrapper type is the array type(ArrayType) that represents an array of val-ues and the nullable type (NullableType) thatextends the codomain of non-null simple typeswith null values. More complex types can be con-structed from other types using structured types(StructType). Structured types also supportsingle inheritance from other structured types.An exception type (ExceptionType) is similarto a structured type; however, its semantics isdifferent: it represents a fault in SOAP and an ex-ception in conventional programming languages.
One of the main advantages of SoaMM is thatclaims based identity management is built intothe metamodel in a platform- and standard inde-pendent way. This means that claims (Claims)are first class types in the type system. A claim(Claim) has a name, a uri and a type. Theseclaims can be mapped to WS-Federation claimsand also to SAML attributes.
The interfaces (Interface) of the services aredescribed as a set of operations (Operation).Figure 5 shows the metamodel of interfacedeclarations. Interfaces support multiple inheri-tance. An operation can have zero or more in-put parameters (Parameter) and a return type(returnType). If the oneway property is true,
Fig. 3 Namespaces anddeclarations
Declaration
gnirts:eman-
Namespace
gnirts:iru- Type Interface Binding EndpointClaims
declarations
namespace
0..*
0..1
742 B. Simon et al.
Type Field
gnirts:eman-
SimpleType ComplexType
EnumTypeBuiltInType ArrayType StructType
ExceptionType
EnumValue
gnirts:eman-
Claim
gnirts:eman-
gnirts:iru-
Claims
Declaration
BuiltInTypeKind
looB+
etyB+
tnI+
gnoL+
taolF+
elbuoD+
gnirtS+
diuG+
etaD+
emiT+
emiTetaD+
napSemiT+
tcejbO+
dioV+
NullableType
WrapperType
superType
values
typetype
claims
superType
kind
fields
innerType
0..1
1
1
10..*
0..*
0..1
1
0..*
Fig. 4 Types and claims
Declaration
Type Interface
Operation
gnirts:eman-
naeloob:yaweno-
Parameter
gnirts:eman-
ExceptionType
returnType
operations
parameters
interface
exceptions
superInterfaces
type
0..*1
0..*
0..*
0..*
11
Fig. 5 Interface
the operation follows the one-way message ex-change pattern, otherwise it is a request-responseoperation. One-way operations must have a voidreturn type and cannot throw exceptions (SOAPfaults). Request-response operations can throwexceptions. The possible exception types must beexplicitly listed for the operation, just like checkedexceptions in Java.
An endpoint implementing a specific interface(Interface) with a specific binding (Binding)running on a specific location is represented by theEndpoint element (Fig. 6). An endpoint containsthe address of the web service and may also spec-ify a metadata address, where additional informa-tion about the web service may be accessed usingthe WS-MetadataExchange standard.
The SoaMM metamodel follows the architec-ture presented in Section 2. A binding (Binding)declaration defines through what protocols a ser-vice can be accessed. It contains the list of theenabled protocols in the stack. The protocols
A Metamodel for the Web Services Standards 743
Fig. 6 Endpoint andbinding
Binding BindingElement
TransportBindingElement
EncodingBindingElement
ProtocolBindingElement
Interface
Endpoint
gnirts:sserdda-
gnirts:sserddAatadatem-
transport
encodingprotocols
interface binding
1
10..*
1 1
are represented by binding elements (Binding-Element). A binding has exactly one trans-port protocol (TransportBindingElement),exactly one encoding protocol (Encoding-BindingElement) and zero or more WS-* pro-tocols (ProtocolBindingElement).
The SoaMM metamodel currently supports themost common transport protocols: HTTP andHTTPS. HTTPS provides transport level secu-rity. The set of these transport protocols may beextended in the future. Figure 7 shows the twosupported transport protocols: HttpTransportfor HTTP and HttpsTransport for HTTPS.Through the clientAuthentication property
TransportBindingElement
HttpTransport HttpsTransport
HttpsClientAuthentication
enoN+
etacifitreC+
clientAuthentication1
Fig. 7 Transport
the latter can specify whether (Certificatevalue) or not (None value) the client must alsoauthenticate itself with an X.509. certificate.
Web services use the SOAP encoding proto-col for communication. The SoaMM metamodeloffers SoapEncoding (see Fig. 8) to representthis protocol and also allows the MTOM op-tion to be enabled for increased efficiency inthe communication. The SOAP version can bespecified through the version property, andthe SOAP encoding style through the styleproperty.
Figure 9 shows the higher level middleware pro-tocols. WsAddressingProtocol, WsReliableMessagingProtocol and WsAtomicTrans-actionProtocol denote the settings of WS-Addressing, WS-ReliableMessaging and WS-AtomicTransaction respectively. Each of thesehas aversionproperty for the version number. ThedeliveryAssurance property of WsReliableMessagingProtocol defines what kind ofdelivery should be used in the WS-ReliableMessaging protocol while the inOrder propertyindicates whether the order of the messagesshould be preserved.
The most complicated protocols to con-figure are the security protocols (WsSecurityProtocol). The SoaMM metamodel makes thistask a bit easier. At first, the version num-bers for the security protocols must be specified:the WS-Security version, the WS-SecurityPolicyversion and the WS-Trust version. These are
744 B. Simon et al.
EncodingBindingElement
SoapEncoding
- mtomEnabled : booleanSoapVersion
+ Soap11
+ Soap12
SoapEncodingStyle
+ DocumentWrapped
+ DocumentLiteral
+ RpcLiteral
+ RpcEncoded
versionstyle
1
1
Fig. 8 Encoding
represented in the metamodel by WssVersion,WssSpVersion and WssTrustVersion, re-spectively (see Fig. 9). After this, the securityalgorithm suite, the layout of the SOAP head-ers and the protection order of the message el-ements must be selected. These are representedby WssAlgorithmSuite, WssHeaderLayoutand WssProtectionOrder, respectively (seeFig. 10). The security elements shown in this figureare common to all security protocols.
The various security protocols differ in thesecurity tokens that are exchanged between theparties. At first, it must be decided, whether theclient and the server will use the same kind oftokens or they will use different kind of tokens. Ifboth participants use the same kind of tokens, thesecurity configuration is easier: only the tokens
attribute has to be specified. If the participants usedifferent kind of tokens, then the client side andthe server side tokens must be configured throughthe clientTokens and the serverTokensrespectively.
There are multiple possible choices for select-ing the security tokens (see Fig. 11). The SoaMMmetamodel supports username tokens, X.509. cer-tificate tokens, issued tokens, SAML tokens andsecure conversation tokens. These are rep-resented by WssUsernameToken, WssX509-Token, WssIssuedToken, WssSamlToken andWssSecureConversationToken, respectively.Through the tokenInclusion it can also bespecified when the different tokens should beincluded during the communication between theclient and the service: always, once or never. The
ProtocolBindingElement
WsAddressingProtocol WsReliableMessagingProtocol
naeloob:redrOni-
WsAtomicTransactionProtocol
WsaVersion
01asW+
4002tsuguAasW+
WsRmVersion
11mrsW+
01mrsW+
WsRmDeliveryAssurance
ecnOyltcaxE+
ecnOtsoMtA+
ecnOtsaeLtA+
WsAtVersion
01tasW+
11tasW+
21tasW+
WsSecurityProtocol
WssSpVersion
11pSsW+
21pSsW+
WssVersion
01ssW+
11ssW+
WssTrustVersion
31tsW+
version version deliveryAssurance version securityVersion policyVersion trustVersion11 1111 1
Fig. 9 Protocols
A Metamodel for the Web Services Standards 745
ProtocolBindingElement
WsSecurityProtocol
naeloob:pmatsemiTedulcni-
naeloob:noitamrifnoCerutangiSeriuqer-
WssHeaderLayout
tcirtS+
xaL+
tsriFpmatsemiTxaL+
tsaLpmatsemiTxaL+
WssAlgorithmSuite
821cisaB+
291cisaB+
652cisaB+
seDelpirT+
51asR821cisaB+
51asR291cisaB+
51asR652cisaB+
51asRseDelpirT+
652ahS821cisaB+
652ahS291cisaB+
652ahS652cisaB+
652ahSseDelpirT+
51asR652ahS821cisaB+
51asR652ahS291cisaB+
51asR652ahS652cisaB+
51asR652ahSseDelpirT+
WssProtectionOrder
ngiSerofeBtpyrcnE+
tpyrcnEerofeBngiS+
erutangiStpyrcnEdnAtpyrcnEerofeBngiS+
WssToken
headerLayout
protectionOrder
algorithmSuite
tokensclientTokensserverTokens
1
0..*0..*
0..*
1
1
Fig. 10 Security
tokens WssIssuedToken and WssSamlTokenare issued by a security token service (STS). Inthese cases the endpoint of this STS should alsobe specified through the tokenIssuer.
A username token contains a user name anda password. In this case the version of the tokenand the inclusion mode of the password have tobe specified.
WssSecureConversationToken
naeloob:syeKdevireDeriuqer-
WssIssuedToken
IssuedKeyType
821cirtemmyS+
652cirtemmyS+
215cirtemmyS+
4201cirtemmysA+
8402cirtemmysA+
2703cirtemmysA+
SamlVersion
01lmaS+
11lmaS+
02lmaS+
ClaimSet
Claim
WssScVersion
31cSsW+
WssToken
naeloob:nekoTtpyrcne-
naeloob:nekoTngis-
naeloob:nekoTgnisrodnEsi-
naeloob:nekoTgnitroppuSsi-
WssUsernameToken
WssX509Token
WssSamlToken
WssUtVersion
01tUssW+
11tUssW+
WssUtPasswordInclusion
drowssaPoN+
drowssaPhsaH+
drowssaPtxeTnialP+
WssX509Version
01nekoT905X+
11nekoT905X+
WsSecurityProtocolEndpoint
WssTokenInclusion
syawlA+
ecnO+
reveN+
keyType tokenVersion
claims
tokenVersion
claimSet
tokenVersion
tokenVersion
tokenVersion
passwordInclusion
bootstrapProtocoltokenIssuertokenInclusion
0..*
1
1
11 1
11
1
1
0..11
Fig. 11 Security tokens
746 B. Simon et al.
An X.509. certificate token contains an X.509.certificate or a reference to such a certificate. Inthis case only the version of the token must bespecified.
An issued token contains either a symmetrickey or an asymmetric key wrapped into a SAMLassertion issued by a security token service. Inthis case the SAML version, the key type andthe token issuer have to be specified. A tokenissuer (tokenIssuer) has an address where itprovides the standard WS-Trust operations, suchas issuance, renewal, validation and cancellationof security tokens. It also has a metadata address,from where WS-Policy information can be ac-quired using the WS-MetadataExchange protocol.The token issuer is another web service and can bereferenced through an Endpoint.
A SAML token contains claims based SAMLassertions issued by a security token service. Inthis case the SAML version, the required claimsand the token issuer have to be specified.
For more efficient secure communication thesecure conversation token can be used. In thiscase the secure conversation version and the boot-strap protocol have to be specified. The bootstrapprotocol is responsible for acquiring the securitycontext token which is then used during the com-munication. The bootstrap protocol itself is also asecurity protocol and can be configured the sameway as other security protocols.
5 Example
In general, the security protocols have the mostcomplicated configuration, especially if securitytoken services are also involved. It is even harderto set the appropriate properties if different prod-ucts from different vendors are used. This sectionshows an example how easy it is to configure ascenario with a security token service (STS) usingthe proposed SoaMM metamodel and its textualconcrete syntax called SOAL.
The example is based on the sample introducedin [5]. The scenario (see Fig. 12) is the following. Aclient would like to buy wine from a webshop. Inorder to be allowed to do this, he must prove thathe is an adult. The proof is presented as a SAMLsecurity token issued by a trusted third party, the
STS
WebShopClient
1. BuyWine()
5. Token+BuyWine()
2. ERROR: Token needed
6. OK
Trus
t Trust
Fig. 12 WS-Trust sample
security token service (STS). The client authenti-cates itself at the STS with his X.509. certificateand receives a SAML token containing his birthdate signed by the STS. The webshop checks thebirthdate in the SAML token and decides whetherto allow the transaction or not.
The SOAL code describing the system can beseen in Appendix B. The correspondig SOALcode is merely 39 lines long and it is very easyto read. If the default values for the omitted pa-rameters are not suitable for us, they can also beoverridden in the code. From this code our SOALcompiler builds a model as an instance of theSoaMM metamodel. This model is then used togenerate WSDL, program code and configurationfiles for the various SOA products. In addition, itcouples these files together into projects that canbe directly opened in the SOA products, whileonly the application logic (i.e. the body of theBuyWine() method) has to be implemented. Theprojects then can be immediately deployed to theappropriate application servers.
The WS-Policy assertions for the WebShopservice and for the Sts security token serviceare themselves longer than the entire SOALcode. The corresponding WSDL is 172 lineslong, and our framework even generates productspecific configuration files and source codes, too.This means that it is much easier to describeand configure distributed SOA systems throughSOAL, than to do it manually. In addition, ourcode generator ensures that the configurations ofthe different SOA products will conform to eachother, therefore, the web services implemented in
A Metamodel for the Web Services Standards 747
different SOA products will be able to communi-cate with each other immediately.
6 Evaluation
This section evaluates our SoaMM metamodel,SOAL language and the framework built aroundthem. Our aim is to provide interoperabilitybetween SOA products without interfering withtheir operation. Our framework is only for offlineuse, i.e. generating source codes and configurationfiles. Our framework does not extend the SOAproducts and it does not provide any runtime com-ponents either. Hence, this evaluation only coversdevelopment productivity and does not deal withruntime performance issues.
We have examined the details of the WS-*standards and created sample applications withinteroperable configurations in the various SOAproducts for the WS-* standards. The products un-der examination were Microsoft WCF, GlassFishESB, Oracle SOA Suite, IBM WebSphere withRAD, Apache Axis2, Apache CXF and JBossWS.As a result, we have an extensive overview ofthe peculiarities of the individual SOA products,and we could use these experiences we gainedto construct a platform independent metamodelabove all WS-* standards and SOA products. Theend result is the SoaMM metamodel described inSection 4. There has not yet been such a compre-hensive metamodel published until now.
Our proposed SoaMM metamodel and SOALprogramming language provides a platform inde-pendent description of a distributed system of webservices. This platform independent description istransformed into WSDL files, configuration files,program codes and projects for the various SOAproducts by our code generator. The code gener-ator makes sure that the produced projects can bedirectly opened in the targeted SOA products andthey can immediately deployed to the appropriateapplication servers, while they are also interoper-able with each other even between different prod-ucts of different software vendors. The code gen-erator currently supports Microsoft WCF, Glass-Fish ESB, IBM WebSphere and RedHat JBosswith Apache CXF, however, other products areplanned to be supported, too.
As the example in the previous section showed,the proposed SOAL programming language pro-vides a compact, easily readable and maintain-able description of a distributed system built fromweb services. Security protocols are very easy toconfigure even if WS-Federation and SAML arepresent. This can be very beneficial for setting upsecurity in Grid systems, too.
The true power of our framework came outin another project we are currently working on.The project is about measuring and predicting theoverhead of using different parameter types (int,double, string, etc.) and different WS-* standardsfor web services in the various SOA products.This task required a large number of web servicesto be implemented in different combinations oftypes and WS-* standards and SOA products. Asa result, 280 web services had to be implementedper SOA product. The performance overhead ismeasured not only within a single SOA productbut between different SOA products as well. Thiswould not be possible without this frameworkdescribed in this article.
Since the Hungarian governments are deter-mined to migrate public administration processesto their electronic versions, the project for theHungarian e-Government Infrastructure has beenestablished. Unfortunately, the Hungarian gov-ernment agencies have different operating sys-tems, different development frameworks fromdifferent software vendors, and they want to pre-serve their autonomity. Therefore, the integrationof these agencies could only be solved by de-veloping a framework that supports the creationof interoperable components for different SOAproducts. Our SoaMM framework was applied ina pilot project for the Hungarian e-GovernmentInfrastructure, where a real-life public adminis-tration process (foundation of a private entre-preneurship) had to be implemented using webservices and BPEL. The pilot system included thesimulation of four government agencies. Therewere seven web services, a BPEL process anda web site in the pilot system. At first, the im-plementation of the process and the services wasdone manually, and it took about 1 month to com-plete. We published our results and the detaileddescription of the pilot system in [30]. After ourframework was ready, we reimplemented all the
748 B. Simon et al.
services by specifying them in SOAL at first, andthen we generated WSDL files, program codesand configuration files for the various SOA prod-ucts we had to use. In this second round we alsoincluded the test system of the real HungarianElectronic Governmental Portal in the pilot sys-tem. This second approach took 3 days, whichshows, that our framework can greatly increaseproductivity in the development of distributedSOA systems.
The framework was also useful in a project withthe Hungarian Police Department. In this projectwe had to implement an administration system forstoring the data of people who are banned fromsport events or sport facilities because of their illbehavior. The organizers of the sport events haveto check each person on entry whether they areallowed to enter the event or the facility. Theserequests are made online through a web service.The interface and the skeleton of the implemen-tation of this service along with the appropriateconfiguration files were generated by our frame-work from SOAL.
The most important practical use of our frame-work is in an ongoing project with the HungarianRailways. We are working on a software of a newticket vending machine which has to communicatewith the online ticketing system and with a centralmaintenance system. The interfaces of both sys-tems were designed in SOAL and the skeleton ofthe implementation and the configuration files for.NET and Java were generated from the SOALdescription. In the design phase the interface ofthe online ticketing system was changing weeklyfor about three months as new and new featureshad to be added to the ticket machines. Using ourframework these changes could be made easily andvery quickly, and it proved to be very productive.
Table 2 shows the productivity of the frame-work based on the previous examples. For eachapplication the number of lines is listed forthe SOAL source code and also for the gen-erated artifacts (XSD+WSDL, C# code, .NETconfiguration, Java code, Netbeans configuration,and the total number of generated lines, respec-tively). It can be seen from the examples howcompact SOAL is compared to the configurationsof the SOA products. Changing the service de-scriptions in SOAL and regenerating the sourcecodes and configuration files is much more pro-ductive than keeping the program codes andconfigurations in sync by hand for each of thevarious SOA products.
7 Conclusion
Our goal was to provide a top-down developmentmethod for distributed systems of web serviceswith WS-* protocols. This goal was inspired bythe fact that the different SOA products pro-vide different methods for configuring web ser-vices making it very difficult to match the variousconfiguration options between SOA products. Al-though WS-Policy assertions provide a platformindependent way for configuration, they are veryhard to construct and to maintain manually. Set-ting up security in Grid systems is also a verytedious task. Therefore, we proposed a more in-tuitive modeling approach.
UML itself is not suitable for modeling web ser-vices standards, since it lacks most of the conceptsrequired to describe these elements. Although byusing stereotypes the task can be managed, WS-* protocols cannot be modeled easily. Semanticweb service technologies are not designed for
Table 2 Productivity ofthe framework withdifferent examples innumber of lines
Application SOAL WSDL C# .NET Java NB Totalconfig config gen.
STS example 39 172 241 53 199 1566 2231WS-* performance test 2168 56276 22083 8927 29806 18118 135210Hungarian e-Gov pilot 146 614 917 233 1642 2026 5432Hungarian police 79 331 450 19 983 1689 3472Hun. railways (ticketing) 522 1565 3030 19 7452 2923 14989Hun. railways (maintenance) 128 871 917 19 2697 2229 6733
A Metamodel for the Web Services Standards 749
modeling either. Therefore, we proposed a do-main specific language for modeling distributedsystems of web services.
In this article we presented our SoaMM meta-model. We also created a programming languagecalled SOAL to describe such systems in a textualconcrete syntax. We have examined the detailsof the WS-* standards and the SOA productsimplementing them to be able to construct a trulyplatform independent metamodel for modelingweb services. There has not yet been such a com-prehensive metamodel for web services publisheduntil now.
The framework built around the metamodelcontains a compiler from SOAL to SoaMM mod-els, and a code generator to produce configurationfiles and program code for the various SOA prod-ucts. Only the application logic has to be imple-mented, and the projects can be immediately de-ployed to the appropriate application servers. Theframework primarily aids the top-down develop-ment of distributed systems. From the compact,easily readable and maintainable SOAL descrip-tions it can produce hundreds of configurationfiles and program codes for the SOA products. Asit was shown in the previous section, the frame-work can be very powerful, if a large number ofinteroperable web services have to be created orif the service interface is in the design phase and ischanging rapidly. Therefore, using our framework
the development time of such distributed systemscan be greatly reduced.
In addition to generating configuration filesfor the SOA products, we also intend to sup-port setting up Grid systems with WS-* protocols.We will extend the framework with WSDL andWS-Policy reverse engineering capabilities so thatthe descriptions of already existing systems canalso be imported into the framework. Anotherfuture direction is to support the deployment de-scription of the distributed system and to pro-duce automatic deployment scripts for the variousSOA products and application servers. Besidesthe SOAL textual concrete syntax we also plan todefine and implement a graphical concrete syntaxto be able to visually design distributed systems.
Acknowledgements The work reported in the paper hasbeen developed in the framework of the project “Talentcare and cultivation in the scientific workshops of BME”project. This project is supported by the grant TÁMOP -4.2.2.B-10/1–2010-0009
A Formal Specification of the SOAL Language
This section defines the SOAL textual concretesyntax for SoaMM formally. The structure ofSOAL follows the structure of the SoaMM meta-model. The SOAL syntax in EBNF form is thefollowing:
Main = Namespace*;Namespace = "namespace" Qualifier ("=" String)? "{" Declaration* "}";Declaration = Using | Namespace | TypeDef | Claims | Interface | Binding | Endpoint;Using = "using" Qualifier ";";Qualifier = Identifier | Qualifier "." Identifier;IdentifierList = Identifier | IdentifierList "," Identifier;QualifierList = Qualifier | QualifierList "," Qualifier;TypeDef = StructType | ExceptionType | EnumType;StructType = "struct" Identifier (":" Qualifier)? "{" Field* "}";ExceptionType = "exception" Identifier (":" Qualifier)? "{" Field* "}";EnumType = "enum" Identifier "{" IdentifierList? "}";TypeRef = BuiltInType | WrapperType | Qualifier;BuiltInType = "object" | "void" | "bool" | "byte" | "int" | "long" | "f\/loat" | "double" |
"string" | "Guid" | "Date" | "Time" | "DateTime" | "TimeSpan";WrapperType = ArrayType | NullableType;ArrayType = TypeRef "[" "]";NullableType = TypeRef "?";Field = TypeRef Identifier ";";Claims = "claims" Qualifier ("=" String)? "{" Field* "}";Interface = "interface" Identifier (":" QualifierList)? "{" Operation* "}";
750 B. Simon et al.
Operation = TypeRef Identifier "(" ParameterList? ")" ("throws" QualifierList)? ";";ParameterList = Parameter | ParameterList "," Parameter;Parameter = TypeRef Identifier;Binding = "binding" Identifier "{" "transport" Transport "encoding" Encoding
("protocol" Protocol)* "}";Transport = HttpTransport | HttpsTransport;HttpTransport = "HTTP" ";";HttpsTransport = "HTTPS" ";" | "HTTPS" "{" HttpsParam* "}";HttpsParam = "clientAuthentication" EnumValueRef ";";EnumValueRef = Qualifier;Encoding = SoapEncoding;SoapEncoding = "SOAP" ";" | "SOAP" "{" SoapParam* "}";SoapParam = "version" EnumValueRef ";" | "mtom" Boolean ";" | "style" EnumValueRef ";" ;Protocol = WsAddressing | WsReliableMessaging | WsAtomicTransaction | WsSecurity;WsAddressing = "WsAddressing" ";" | "WsAddressing" "{" WsaParam* "}";WsaParam = "version" EnumValueRef ";";WsReliableMessaging = "WsReliableMessaging" ";" | "WsReliableMessaging" "{" WsRmParam* "}";WsRmParam = "version" EnumValueRef ";" | "deliveryAssurance" EnumValueRef ";";WsAtomicTransaction = "WsAtomicTransaction" ";" | "WsAtomicTransaction" "{" WsAtParam* "}";WsAtParam = "version" EnumValueRef ";";WsSecurity = "WsSecurity" ";" | "WsSecurity" "{" WssParam* "}";WssParam = "securityVersion" EnumValueRef ";" | "policyVersion" EnumValueRef ";" |
"trustVersion" EnumValueRef ";" | "algorithmSuite" EnumValueRef ";" |"headerLayout" EnumValueRef ";" | "protectionOrder" EnumValueRef ";" |"includeTimestamp" Boolean ";" | "requireSignatureConfirmation" Boolean ";" |"tokens" "{" TokenList "}" | "clientTokens" "{" TokenList "}" |"serverTokens" "{" TokenList "}";
TokenList = Token | TokenList Token;Token = "token" WssToken ";";WssToken = WssUsernameToken | WssX509Token | WssIssuedToken | WssSamlToken |
WssSecureConversationToken;WssTokenParam = "tokenIssuer" Qualifier ";" | "tokenInclusion" EnumValueRef ";" |
"encryptToken" Boolean ";" | "signToken" Boolean ";" | "isSupportingToken" Boolean ";" |"isEndorsingToken" Boolean ";";
WssUsernameToken = "WssUsernameToken" ";" | "WssUsernameToken" "{" WssUsernameTokenParam* "}";WssUsernameTokenParam = "version" EnumValueRef ";" | "passwordInclusion" EnumValueRef ";" |
WssTokenParam;WssX509Token = "version" EnumValueRef ";" | WssTokenParam;WssIssuedToken = "version" EnumValueRef ";" | "keyType" EnumValueRef ";" |
"tokenIssuer" Qualifier ";" | WssTokenParam;WssSamlToken = "version" EnumValueRef ";" | "claims" ClaimsRef ";" |
"tokenIssuer" Qualifier ";" | WssTokenParam;ClaimsRef = QualifierList;WssSecureConversationToken = "version" EnumValueRef ";" | "bootstrapProtocol" WsSecurity |
"requireDerivedKeys" Boolean | WssTokenParam;Endpoint = "endpoint" Identifier ":" Qualifier "{" BindingRef AddressRef? "}";BindingRef = "binding" Qualifier ";";AddressRef = "address" String ";"Boolean = "true" | "false";
Where Identifier and String are the sametokens as in C#. An Identifier starts with aletter or underscore and is continued with letters,digits and underscores. A String is a literal be-
tween quotation marks and its characters can beescaped by backslashes, or it has an at sign beforethe first quote indicating a verbatim string whereescaping is done by quote signs.
A Metamodel for the Web Services Standards 751
B WS-Trust Example in SOAL
The SOAL code describing the WS-Trust example[5] (see Fig. 12) is the following:
namespace WineShoppingSample{claims SampleClaims {
string BirthDate;}interface IWebShop {
bool BuyWine();}binding WebShopBinding {
transport HTTP;encoding SOAP;protocol WsAddressing;protocol WsSecurity {serverTokens { token WssX509Token; }clientTokens {token WssSamlToken {
tokenIssuer Sts;claims SampleClaims.BirthDate;
}}
}}binding StsBinding {
transport HTTP;encoding SOAP;protocol WsAddressing;protocol WsSecurity {tokens { token WssX509Token; }
}}endpoint WebShop : IWebShop {
binding WebShopBinding;address "http://www.webshop.com/ws";
}endpoint Sts : ISecurityTokenService {
binding StsBinding;address "http://www.webshop.com/sts";
}}
Note that ISecurityTokenService is apseudo interface identifying an STS.
References
1. Anderson, A.: An introduction to the Web ser-vices policy language. In: Fifth IEEE Interna-tional Workshop on Policies for Distributed Systemsand Networks (POLICY’04). http://labs.oracle.com/projects/xacml/Policy2004.pdf (2004). Accessed 17Sept 2010
2. Anderson, A.: XACML-based Web Services PolicyConstraint language (WSPolicyConstraints). http://labs.oracle.com/projects/xacml/ws-policy-constraints-current.pdf (2005). Accessed 17 Sept 2010
3. Anderson, M.: Grid computing—security report.http://a.ijaz.angelfire.com/GridComputing.pdf (2008).Accessed 5 Jan 2012
4. Andreetto, P., Andreozzi, S., Ghiselli, A., Marzolla,M., Venturi, V., Zangrando, L.: Standards-based jobmanagement in grid systems. J. Grid Computing 8(1),19–45 (2010)
5. Bertocci, V.: WS-Trust—Under the hood. http://channel9.msdn.com/Shows/Going+Deep/Vittorio-Bertocci-WS-Trust-Under-the-Hood (2006). Accessed 17 Sept 2010
6. Cao, F., Bryant, B.R., Zhao, W., Burt, C.C., Raje,R.R., Olson, A.M., Auguston, M.: A meta-modelingapproach to web services. In: Proceedings of the IEEEInternational Conference on Web Services, ICWS ’04,pp. 796–799. IEEE Computer Society, Washington,DC (2004). doi:10.1109/ICWS.2004.1314824
7. Charfi, A., Schmeling, B., Heizenreder, A., Mezini,M.: Reliable, secure, and transacted web service com-positions with ao4bpel. In: ECOWS ’06: Proceed-ings of the European Conference on Web Services,pp. 23–34. IEEE Computer Society, Washington, DC(2006)
8. de Castro, V., Marcos, E., Vela, B.: RepresentingWSDL with extended UML. RCC 5(1) (2004)
9. Dumez, C., Nait-sidi moh, A., Gaber, J., Wack, M.:Modeling and specification of Web services compo-sition using uml-s. In: 4th International Conferenceon Next Generation Web Services Practices, 2008.NWESP ’08 (2008)
10. Elgammal, A., El-Sharkawi, M.: Using uml to modelweb services for automatic composition. Open Accesspublications from Tilburg University urn:nbn:nl:ui:12-4561873. Tilburg University (2010)
11. ESSI WSMO working group: Web Service ModelingOntology (WSMO). http://www.wsmo.org/. Accessed29 Jan 2012
12. Gronmo, R., Skogan, D., Solheim, I., Oldevik, J.:Model-driven web services development. In: The2004 IEEE International Conference on e-Technology,e-Commerce and e-Service (EEE-04) (2004)
13. Haller, A., Cimpian, E., Mocan, A., Oren, E., Bussler,C.: Wsmx—a semantic service-oriented architecture.In: Proceedings of the International Conference onWeb Service (ICWS 2005), pp. 321–328 (2005)
14. Hudert, S., Ludwig, H., Wirtz, G.: Negotiating slas-anapproach for a generic negotiation framework for ws-agreement. J. Grid Computing 7, 225–246 (2009)
15. Jegadeesan, H., Balasubramaniam, S.: An mof2-basedservices metamodel. JOT 7(8), 71–96 (2008)
16. Klusch, M.: CASCOM—Intelligent Service Coordina-tion in the Semantic Web, chapter 3. Birkhuser Verlag,Springer (2008)
17. Kolovski, V., Parsia, B., Katz, Y., Hendler, J.: Repre-senting web service policies in owl-dl. In: InternationalSemantic Web Conference (ISWC), pp. 6–10 (2005)
752 B. Simon et al.
18. Microsoft: Windows Communication Foundation. http://msdn.microsoft.com/en-us/netframework/aa663324.aspx.Accessed 29 Jan 2012
19. Moses, T.: eXtensible Access Control Markup Language(XACML). http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml (2008). Accessed 17 Sept2010
20. Nadalin, T.: Web Services Security Policy Language(WS-SecurityPolicy). http://www-128.ibm.com/developerworks/library/specification/ws-secpol/(2005). Accessed 17 Sept 2010
21. Nakajima, Y., Sato, M., Aida, Y., Boku, T., Cappello,F.: Integrating computing resources on multiple grid-enabled job scheduling systems through a grid rpc sys-tem. J. Grid Computing 6, 141–157 (2008)
22. Núñez, A., Vázquez-Poletti, J.L., Caminero, A.C.,Casta né, G.G., Carretero, J., Llorente, I.M.: Icancloud:a flexible and scalable cloud infrastructure simulator.J. Grid Computing 10(1), 185–209 (2012)
23. OMG: Service oriented architecture ModelingLanguage (SoaML). http://www.omg.org/spec/SoaML/Current (2009). Accessed 17 Sept 2010
24. Oracle: Metro. http://metro.java.net/. Accessed 21 Aug2011
25. Piprani, B., Wang, C., He, K.: A metamodel forenabling a service oriented architecture. In: Pro-ceedings of the OTM Confederated InternationalWorkshops and Posters on On the Move to Mean-ingful Internet Systems: 2008 Workshops: ADI,AWeSoMe, COMBEK, EI2N, IWSSA, MONET, On-ToContent + QSI, ORM, PerSys, RDDS, SEMELS,and SWWS, pp. 668–677. Springer-Verlag, Berlin,Heidelberg (2008)
26. Qafmolla, X., Nguyen, V.C.: Automation of web ser-vices development using model driven techniques.In: 2010 The 2nd International Conference on Com-puter and Automation Engineering (ICCAE), vol. 3,pp. 190–194 (2010)
27. Shafiq, O., Moran, M., Cimpian, E., Mocan, A.,Zaremba, M., Fensel, D.: Investigating semantic webservice execution environments: a comparison betweenwsmx and owl-s tools. In: International Conference on
Internet and Web Applications and Services, pp. 31(2007)
28. Simon, B., Goldschmidt, B.: A human readable plat-form independent domain specific language for wsdl.In: Networked Digital Technologies, pp. 529–536(2010)
29. Simon, B., Goldschmidt, B., Budai, P., Hartung, I.,Kondorosi, K., Laszlo, Z., Risztics, P.: A metamodelof the ws-policy standard family. In: The Fifth Inter-national Conference on Digital Society, ICDS 2011,pp. 57–62 (2011)
30. Simon, B., Laszlo, Z., Goldschmidt, B.: Soa interop-erability, a case study. In: Proceedings of the IADISInternational Conference, Informatics, pp. 131–138(2008)
31. Sriharee, N., Senivongse, T., Verma, K., Sheth, A.:On using ws-policy, ontology, and rule reasoning todiscover web services. In: Aagesen, F.A., Anutariya,C., Wuwongse, V. (eds.) Intelligence in Communi-cation Systems. Lecture Notes in Computer Science,vol. 3283, pp. 246–255. Springer Berlin / Heidelberg(2004). doi:10.1007/978-3-540-30179-0_22
32. Verma, K., Akkiraju, R., Goodwin, R.: R.: Semanticmatching of web service policies. In: Proceedings of theSecond Workshop on SDWP, 2005, pp. 79–90 (2005)
33. W3C: OWL-S: Semantic Markup for Web Services.http://www.w3.org/Submission/OWL-S/. Accessed 29Jan 2012
34. W3C: Semantic Annotations for WSDL and XMLSchema (SAWSDL). http://www.w3.org/TR/sawsdl/.Accessed 29 Jan 2012
35. Wada, H., Suzuki, J., Oba, K.: A model-driven de-velopment framework for non-functional aspects inservice oriented grids. In: Proceedings of the Inter-national Conference on Autonomic and AutonomousSystems, ICAS ’06, pp. 30–38. IEEE Computer Society,Washington, DC (2006). doi:10.1109/ICAS.2006.4
36. Wada, H., Suzuki, J., Oba, K.: A model-driven develop-ment framework for non-functional aspects in serviceoriented architecture. In: International Journal of WebServices Research (IJWSR), vol. 5, issue 4, pp. 1–31(2008)