Post on 28-May-2020
1
1ICT
F11: SOA og Web Services realisering
David Skogan,
Arne-Jørgen Berre, Brian ElveseterSINTEF
2ICT
SOA og Web Services realisering
MDA og PIM -> PSM transformasjoner
SOA og Web Services
UDDI Registry
SOAP
XML og XSD (metamodel, profile, transformations)
WSDL, Web Services (metamodel, profile, transformations)
BPEL (metamodel, profile, transformations)
2
3ICT
LæremålPrinsipper og metamodell for SOA (PIM4SOA og COMET arkitektur modell) og mapping til ulike PSM realiseringer - fra forrige forelesning, F10i F11 fokuserer vi spesielt på grunnlaget for å kunne gjøre transformering til PSM Web services i Oblig 2.
Web services med SOAP (XML + HTTP)Prinsipper og arkitektu/referansemodeller for Web ServicesPrinsipper for UDDI og Registries/RepositoriesKonsepter, metamodell og UML profil for XML-XSDKonsepter, metamodell og UML profil for WSDLKonsepter og metamodell for BPEL
Maping/Transformasjon fra PIM4SOA til PSM Web Services til kode/tekst for Web Services
Oblig 2: Mapping/Transformasjon fra PIM arkitektur modell til PSM Web services modell (XML/XSD, WSDL ) med ATL (XMF) og til kode/tekst med MOFScript (XMF) (N.B. – Det kreves ikke mapping/transformasjon til BPEL, selv om dette kunne vært mulig og relevant (ref. tidligere eksamen)).
4ICT
OMG Model Driven Architecture (MDA)
Platform Independent Model
Platform Specific Model
Executable Code
Transformation
Code Generation
QVTSpecify
Transformations
UMLSpecify
Applications
MOFSpecify
Languages
Computation Independent Model
TransformationBusinessEnterprise
models
+ similar for Microsoft DSL Domain Specific Languages
3
5ICT
PIM4SOA goalsThe goal of creating the PIM4SOA was to define a metamodel or language that could be used to describe SOAs at a platform independent level.The PIM4SOA model should bridge the gap between the business analysts and the IT developers and support mapping and alignmentbetween enterprise and IT models.The PIM4SOA model should define a platform neutral abstraction that can be used to integrate and define mappings to Web service, business process, agent and P2P execution platforms.The PIM4SOA aims to integrate “traditional” service-orientation with adaptive software architecture (SOA) to form an “advanced” service-oriented architecture (ASOA).
Note: Other PIM Services models, like the COMET Architecture model can also be used similarly
6ICT
Metamodel for (software) services Metamodel for (automated software) processes
Metamodel for information Metamodel for quality of service (QoS)
PIM4SOA – 4 system aspects
4
7ICT
PIM4SOAMetamodel
Web ServicesMetamodel
Agent Metamodel(AgentMM)
P2PMetamodel
GridMetamodel
PIM
PSM
s
Symbols
Metamodel
Concept
RelationshipCorrespondence
PIM4SOA → platform specific models
8ICT
PIM4SOA → platform specific models
PIM4SOAsourcemetamodel
Web servicestargetmetamodels
Mappingmodel
5
9ICT
Generic Service-oriented model(& web services realisation )
Service provider: A service provider is the party that provides software applications for specific needs as services. Service providers publish, unpublish and update their services so that they are available on the Internet.Service requester: A requester is the party that has a need that can be fulfilled by a service available on the Internet. A requester could be a human user accessing the service through a desktop or a wireless browser; it could be an application program; or it could be another service. A requester finds the required services via a service broker and binds to services via the service provider. Service broker: A service broker provides a searchable repository of service descriptions where service providers publish their services and service requesters find services and obtain binding information for these services. Examples of service brokers are UDDI (Universal Description, Discovery, and Integration) and XMethods. In many cases the role of the service broker is not explicitly needed. Services can be discovered by marketing channels or by referrals.
(UDDI)
(SOAP)(WSDL)
10ICT
Web services og port 80Interessen for Web-tjenester har mye av sitt utgangspunkti problemet for CORBA, MS DCOM og Java RMI med åslippe igjennom for kommunikasjon med ukjente klienter, på grunn av sperrer i brannmurer. Det ble raskt oppdaget at port 80 (for http Web-browser) kommunikasjon var åpen i de fleste brannmurer, og man begynte å pakke inn informasjon (tunneling) i meldingersom ble sendt gjennom port 80, først innpakket i HTML, deretter i XML.Dette gav både en teknologi- og markedsmulighet somførst Microsoft, deretter IBM var tidlig ute med å utnytte og promotere.
6
11ICT
Web Services Architecture
BPEL
12ICT
Web services architecture
7
13ICT
What is a Web service?The term “Web services” is confusing.There are many things that are referred to as “Web services”.Adding to the confusion is the term “services” which is interpreted differently by different people.
14ICT
WebWeb serviceservice
Web is short for World Wide Web.
Work performed or offered by a software system (possibly including human resources as well.)
Software services performed or offered on the Web, using open Internet standards and technologies.
What is a Web service?
8
15ICT
Definition (W3C): Web service
“A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.”
- W3C Web Services Glossary, http://www.w3.org/TR/ws-gloss/
16ICT
Characteristics of a basic Web service
Fundamental requirements:It receives service requests and sends service replies over HTTP
Service requests – input data/parametersService replies – output data/parameters
Data is normally formatted as an XML document SOAP (Simple Object Access Protocol) + WSDL (Web Service Description Language)REST (Representational State Transfer)
http://www.myBroker.com/quote?ticket=FAST
Additionally, a Web service may:Be registered with a discovery agent through which it can be located, typically UDDI.
9
17ICT
Web services stack
Technologystack
Conceptualstack
This part of the tutorial focuses on understanding the Web service technologies for messaging, description and composition such as XSD, WSDL and WS-BPEL.
18ICT
Web services – a conceptual view
Underlying Protocols
Messaging Encoding
Business EntitiesWeb Service Interfaces
HTTP/WEB
VANsFTP
SMTP/EMAIL MQ-Series
SOAP
EDI“Binary”
Raw XML ebXML
BPEL____________________________________________________________
EGO-CentricWorkflow ProcessDescription
WSDL____________________________________________________________
(Syntactic) Web Service Interface Description
Bindings and Endpoint Descriptions
WS-CHOR____________________________________________________________
Interaction Sequencing
(Co)Constraints
XSD____________________________________________________________
XML MessageSchemaDefinition
10
19ICT
Elementer i tjenesteorientertarkitektur
Composition
Description & Basic Operations
Mana-gement
•Capability•Inteface•Behavior•QoS
•Coordination•Conformance•Monitoring•QoS
•Publication•Discovery•Selection•Binding
Service provider
Service client
Service aggregator
performs
publishes
uses
Role actions
becomes
Operations•Assurance•Support
Market•Certification•Rating•SLAs
Service operator
Market maker
Managed services
Composite services
Basic services
Composition
Description & Basic Operations
Mana-gement
•Capability•Inteface•Behavior•QoS
•Coordination•Conformance•Monitoring•QoS
•Publication•Discovery•Selection•Binding
Service provider
Service client
Service aggregator
performs
publishes
uses
Role actions
becomes
Operations•Assurance•Support
Market•Certification•Rating•SLAs
Service operator
Market maker
Managed services
Composite services
Basic services
CACM,Oct. 2003
20ICT
UDDI Registry
UDDI Business Registry
3. UBR assigns a programmatically unique identifier to each service and business registration
Marketplaces, search Marketplaces, search engines, and business apps engines, and business apps query the registry to query the registry to discover services at other discover services at other companiescompanies
44..
Service TypeRegistrations
SW companies, standards SW companies, standards bodies, and programmers bodies, and programmers populate the registry withpopulate the registry withdescriptions of different types descriptions of different types of servicesof services
11..
BusinessRegistrationsBusinesses Businesses
populate populate the registry withthe registry withdescriptions of descriptions of the services they the services they supportsupport
22..
Business uses this Business uses this data to facilitate easier data to facilitate easier integration with each integration with each other over the Webother over the Web
55..
Universal Description, Discovery and Integration
11
21ICT
Registry Data
• Businesses register public informationabout themselves
• Standards bodies, Programmers, Businesses register information about their Service Types
22ICT
The Global UDDI Business Registry
Business ServiceRegistrator
Application
Application
Application
12
23ICT
UDDI - Four Information Types
<businessEntity>name, contacts,description, indentifiers, categories
<businessService> sService> (1..n)
namedescription, categories
<bindingTemplate>(1..n)technical information
<tModel>namedescriptionURL pointers to specificaitons
24ICT
Januar 2006 - UDDI ?Microsoft og IBM slutter markedsføring og støtte for UDDI tjenester i januar 2006.Den vanlige bruk av UDDI er nå internt i organisasjoner eller grupperinger som har egne avtaler rundt bruk av tjenesterDisse inneholder vanligvis flere søke-attributter enn detsom er definert av UDDI i utgangspunktetMangel på standarder rundt SLA (Service Level Agreement) og pris/betalings teknologi har vært en av de medvirkende årsaker til at UDDI så langt ikke har nådd de opprinnelige mål om å være ”tjenestenes telefonkatalog”.
13
25ICT
SOAP(Simple Object Access Protocol)
26ICT
Use of SOAP
network protocol
SOAP
application -service
requester
network protocol
SOAP
serviceprovider
request(soap request message)
respons(soap response message)
1 4 23
14
27ICT
SOAP (Simple Object Access Protocol)
• SOAP er en protokoll for å sende meldinger og utveksle informasjon i en Internet-omgivelse. Den definerer hvordan meldinger skal struktureres og hvordan data skal kodes på XML-format og består av tre deler: En konvolutt (envelope) som definerer rammeverk for innholdet og prosesseringsregler for meldinger, kode-regler (encoding-rules) for å uttrykke instanser av datatyper og en konvensjon for å representere fjernprosedyrekall og svar. SOAP kan brukes i kombinasjon med en rekke andre protokoller, selv om spesifikasjonen i utgangspunktet definerte bindinger til HTTP.
28ICT
Making a SOAP function call over HTTP
Body
XMLData
HeaderHTTP Request
Body
XMLData
Header
HTTP Response
15
29ICT
The SOAP Envelope<SOAP:Envelope>
<SOAP:Header></SOAP:Header>
<SOAP:Body><m:FunctionName>
<paramName1>paramValue1</paramName1><paramName2>paramValue2</paramName2>
</m:FunctionName></SOAP:Body>
</SOAP:Envelope>
Optional
30ICT
XML Schema Definition (XSD)
16
31ICT
XML - a MetametaLanguage
Metameta/How to define schema
Meta/Schema
Instances/Documents
XSD SGML
MathML XSL SMIL OFX HTML
XSL Doc HTML DocXML Doc
32ICT
DocumentType
Definition(DTD)
XMLDocument
XSLto rearrange/restructure
an XML document…
and to prepare a document
for rendering based on an XSL document
XPointerto positiona cursor
in an XMLdocument
XLinkto createcomplex
links
XML Schemato represent the DTD in
XML syntax and expressadditional constraints
XML-QLto query sets ofXML documents
XQLto query
a complexdocument
RDFResource
DescriptionFramework -
to add metadata
17
33ICT
XML Schema Definition (XSD)Description
An XML schema describes the structure of an XML document.XSD is a comprehensive data modelling language for XML documents.The one XML schema specification that has received the broadest industry support.The XML schema definition language is also referred to as XML Schema Definition (XSD).XML schema is an XML-based alternative to DTD. It replaces/superseedes DTD.
W3C, "XML Schema Part 0: Primer Second Edition", World Wide Web Consortium (W3C), W3C Recommendation, 28 October 2004. http://www.w3.org/TR/xmlschema-0/
34ICT
XSD: Purpose
Define the legal building blocks of an XML document:Defines elements that can appear in a document.Defines attributes that can appear in a document.Defines which elements are child elements.Defines the order of child elements.Defines the number of child elements.Defines whether an element is empty or can include text.Defines data types for elements and attributes.Defines default and fixed values for elements and attributes.
18
35ICT
XSD: Approaches for specification
Several different ways of specifying an XSD. This tutorial gives three different examples:
XML text editorXML schema design editorUML profile for XSD
36ICT
XSD: XML text editor
Can also be built using simple text editorsXML editors gives contextual support, e.g. like auto-completion, suggestions for elements, etc., as well as validation of the XML document.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name=“XMLRequest">
<xs:complexType>
…
</xs:complexType>
</xs:element>
</xs:schema>
19
37ICT
XSD: XML schema design editor (1/3)
Visual language for schema designSupported by e.g. XMLSpy
38ICT
XSD: XML schema design editor (2/3)
Terminal: This is the graphical representation of terminal elements. They usually contain text, numbers or another type of basic data.
Intermediate: The intermediate elements represents the structure of the document. The "+" symbol indicates us that the element can contain more elements.
Element types
Relationship types
Sequence: This schema represents that bankingInformation contains element accountNumber and bankData.
Choice: This schema represents that fileId contains fileUri or (exclusive or) fileName.
20
39ICT
XSD: XML schema design editor (3/3)
We have seen the types and relationship between elements, but not the times that an element can appears.
Zero or one: Tell us that the element is optional (can appear zero or one times).
Cardinality modifier
One or more: Tell us that the element appears at least one time, but can appear all times we want.
Zero or more: Tell us that the element appears zero or more times.
40ICT
XSD: UML profile for XSD
UML representation of XML schema.Useful in a UML-centric development method if the modelling environment supportsgeneration/import of XSD documents.
21
41ICT
UML profile for XSD (1)Stereotype UML
construct Tagged value Description
<<any>> Class, Property
The stereotyped class or attribute will be relaced by an 'any' or 'anyAttribute' element. The tagged values are copied into the corresponding attributes of the generated element
namespace As defined in XML Schema specification processContents As defined in XML Schema specification
• values="skip | lax | strict" • default="strict"
<<attribute>> Property Assigned to UML attribute or association end. Indicates item is to be generated as an attribute within complexType and not as an element
default As defined in XML Schema specification fixed As defined in XML Schema specification form Overrides the attributeFormDefault for this
schema • values="qualified | unqualified"
use As defined in XML Schema specification • values="prohibited | optional | required" • default="optional"
<<choice>> Class Elements marked with this stereotype represent a Choice model group conatined within a complexType definition
<<complexType>> Class ComplexType definition generated in XML Schema
memberNames Overrides the package-level default for naming complexType definitions • values="qualified | unqualified"
42ICT
UML profile for XSD (2) mixed Determines whether this element may contain
mixed element and character content. • values="true | false" • default="false"
modelGroup Overrides the package-level default model group • values="all | sequence | choice"
<<element>> Property Assigned to UML attribute or association end. Indicates item is to be generated as element within complexType and not as attribute
anonymousRole The class type will be directly embedded within the complexType definition. Omit attribute or role type wrapper • values="true | false" • default="false"
anonymousType The class type will be anonymous for XML documents generated by the schema • values="true | false" • default="false"
form Overrides the elementFormDefault for this schema • values="qualified | unqualified"
position If assigned, indicates position in the sequence model group
<<facet>> Property A facet is a single defining aspect of a value space. Generally speaking, each facet characterizes a value space along independent
22
43ICT
UML profile for XSD (3)UML representation Text representation
44ICT
Transformation to XSDThe XSD artefacts are generated from the Information part of the PIM4SOA model. The starting point for the transformation is a PIM4SOA document. The strategy is to convert one PIM4SOA Document into one XML schema. The mappings between the most relevant PIM4SOA elements and XSD are listed next.
23
45ICT
PIM4SOA main mappings to XSD
If the ItemType from the PIM4SOA model is not an
entity (meaning it is a simple type) a SimpleType
definition is created in the schema.
SimpleTypeElement
Attributes having simple types are mapped to Attributes
in complex types. Attributes with complex types in the
PIM4SOA model are mapped in the same way as
Associations.
AttributeAttribute
An association between entities is transformed into an
element in the containing type with a reference to the
complex type generated for the target Entity
ElementAssociation
ComplexTypeEntity
SchemaDocument
NotesXSD equivalentPIM4SOAelement
46ICT
Web Services Description Language(WSDL)
24
47ICT
Web Services Description Language (WSDL)
PurposeWeb services need to be defined in a consistent manner so that they can be discovered by and interfaced with other services andapplications.The Web Services Description Language is a W3C specification providing the foremost language for the description of Web service definitions.
W3C, "Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language", World Wide Web Consortium (W3C), W3C Working Draft, 3 August 2004. http://www.w3.org/TR/2004/WD-wsdl20-20040803/
48ICT
WSDL: DescriptionXML-based language for describing functional properties of Web services.A service consists of a collection of message exchange end points.An end point contains an abstract description of a service interface and implementation binding.The abstract description of a service contains:
(i) definitions of messages which are consumed and generated by the service(ii) signatures of service operations.
The implementation binding provides a means to map abstract operations to concrete service implementations.
It essentially contains information about the location of a binding and the communication protocol to use (e.g., SOAP over HTTP) for exchanging messages
25
49ICT
WSDL: Conceptual view
Underlying Protocols
Messaging Encoding
Business EntitiesWeb Service Interfaces
HTTP/WEB
VANsFTP
SMTP/EMAIL MQ-Series
SOAP
EDI“Binary”
Raw XML ebXML
WSDL____________________________________________________________
(Syntactic) Web Service Interface Description
Bindings and Endpoint Descriptions
50ICT
WSDL: Conceptual model
WS Provider
WSClient
WS Interface
Ports
Operations
Name,Abstract Message Parts SchemaMessage Exchange Pattern
Porttype
Operation
Concrete Message EncodingConcrete Messaging Protocol
(Reusable) Binding
Concrete Endpoint Address
Operations Invoked through Ports
26
51ICT
WSDL: Message exchange patterns
WS Provider
WSClient
Time
Request-Response
Solicit-Response
One-Way
Notification
52ICT
PIM4SOAMetamodel
Web ServicesMetamodel
Agent Metamodel(AgentMM)
P2PMetamodel
GridMetamodel
PIM
PSM
s
Symbols
Metamodel
Concept
RelationshipCorrespondence
PIM4SOA → platform specific models
27
53ICT
Web services architecture metamodel
Registry<<Metamodel>>
+ UDDI.
Endpoint Description<<Metamodel>>
+ WS-MetadataExchange.+ WS-Policy.
+ WS-PolicyAttachement.
Service Interface Description
<<Metamodel>>
+ WSDL 1.1.+ WSDL 2.0.
Reliability<<Metamodel>>
+ WS-ReliableMessaging.Coordination
<<Metamodel>>
+ WS-Coordination.
Eventing<<Metamodel>>
+ WS-BaseNotification.+ WS-BrokeredNotification.
+ WS-Eventing.+ WS-Topics.
Resource Access and Management
<<Metamodel>>
+ WS-Enumeration.+ WS-Resource.
+ WS-ResourceLifetime.+ WS-ResourceProperty.
+ WS-Transfer.
Transport<<Metamodel>>
+ HTTP.
Messaging<<Metamodel>>
+ SOAP.+ WS-Addressing.
XML<<Metamodel>>
+ XML Core / XSD.+ XML Encryption.+ XML Signature.
+ XPATH.
Security<<Metamodel>>
+ WS-Security.
eContract<<Metamodel>>
+ ATHENA eContract Extensions.
Composition<<Metamodel>>
+ ACE-GIS Composition Extensions.+ WS-BPEL.+ WS-CDL.
54ICT
WSDL 1.1 metamodelWSDL DocumentWSDL Component
0..10..1
Port+ Name
Operation+ Name
Part+ Name+ Type+ Element
Service
+ Name
1..*1..*
Binding
+ Name
1
1
1
1
Port Type
+ Name11 11
Message+ Name
1..*
0..1
1..*
+input
0..1 0..1+output
0..10..1+fault 0..1
0..*0..*
Import
+ NameSpace+ Location
Include
+ Location
Element+ Name+ BaseType+ MinOccurs+ MaxOccurs
Definition
+ Name+ TargetNameSpace0..*0..*
0..*0..*0..*0..*
0..*0..*
0..*0..*
Schema+ TargetNameSpace
Types
0..10..1
A collection of related endpoints
A single endpoint defined as a combination of a binding and a network address
A concrete protocol and data format specification for a particular port type
An abstract set of operations supported by one or more endpoints
An abstract, typed definition of the data being communicated
An abstract, description of an action supported by the service
A container for data type definitions
28
55ICT
PIM4SOA model (.uml2)
WS-* model (.uml2)
UML profile for Web services
Web service artefacts
EMF EcoreMetamodels/Models
RSMUML Models and Profiles
XSD
WSDL
BPEL
XSD
WSDL
BPEL
M2M
M2M
UML profilefor PIM4SOA
PIM4SOA model (. ecore)
WS-* models (.ecore)
M2MM2T
M2M
1
2
3 4
X
Eclipse/RSM modelling environment1. Build your PIM4SOA (.uml2) model in
RSM using the UML profile for PIM4SOA and transform it to a PIM4SOA (.ecore) model in EMF.
2. Transform the PIM4SOA (.ecore) model to Web service (.ecore) models.
3. Transform the Web service (.ecore) models to Web service artefacts.
4. Model transformation for UML profiles for Web services
• Eclipse Modelling Framework (EMF)
• Rational Software Modeler (RSM)
56ICT
UML profile
Business Modelling
Annotated Business Modelling
Detailed Design
PIM
PSM
Annotated PIM
Business Idea
WSDLWSDL POLICIESPOLICIESCLASSESCLASSES
Information System SolutionPIM
«Annotated» IS SolutionPIM
Platform Ready SolutionPSM
Deploymentdecisions
Business Expert
Platform Expert
BusinessLevel
PlatformLevel
RunningLevel
Transformation rules
generationUML profile
annotationUML profile
We have defined a basic metamodel for Web services that covers those basic aspects that all Web services have to fulfil, and two extended metamodels that extend the basic specification with important concepts for Web services technology, such as faults and security. Starting from these metamodels, we have defined three different UML profiles that try to make easy the specification and development of Web services.
29
57ICT
UML profile for Web servicesWeb Service Basic Profile
This plugin implements the base UML modelling support for how to specify and develop Web services.This plugin can be extended with other specific Web service technology profiles (e.g. XSD, WSDL and BPEL) each covering different parts of the Web service stack.
UML Profile for XSDThis plugin implements UML modelling support for XML schema definitions
UML Library for XSDThis plugin defines XSD types to be used when modelling XML schema definitions in UML.
UML Profile for WSDLThis plugin implements UML modelling support for WSDL.
UML Profile for BPELThis plugin implements UML modelling support for BPEL.
58ICT
UML profile for WSDL (1)Stereotype UML
construct Tagged value Description
<<binding>> Class A concrete protocol and data format specification for a particular port type. A concrete protocol and data format specification for a particular port type. A <<binding>> class represents a binding component of the WSDL metamodel.
binding Binding type • default=”soap:binding”
style The style attribute indicates whether the operation is a remote procedure call (RPC) or a document-oriented operation. • default=”rpc”
transport The transport attribute specifies the type of binding to be used. • default=”http://schemas.xmlsoap.org/soap/http”
<<definition>> Class A <<definition>> class represents a definition component of the WSDL metamodel.
targetNameSpace TargetNameSpace is an URI (Uniform Resource Identifier). It is mandatory and identifies the namespace which it will belong all of the component names.
<<element>> Class An <<element>> class represents an element of the XML Schema.
baseType The base type maxOccurs The maximum number of occurrences minOccurs The minimum number of occurrences name The name of the element <<fault>> Association An <<fault>> association represents a relationship
between an operation and a message in the WSDL metamodel.
<<import>> Class An <<import>> class represents an import component of the WSDL metamodel.
30
59ICT
UML profile for WSDL (2) location Location is an URI. It is optional and indicates the
location of some information for the namespace. namespace Namespace is an URI (Uniform Resource Identifier). It is
mandatory and indicates that the containing WSDL document can contain references to the WSDL definitions in that namespace.
<<input>> Association An <<input>> association represents a relationship between an operation and a message the WSDL metamodel.
<<message>> Class An abstract, typed definition of the data being communicated. A <<message>> class represents a message component of the WSDL metamodel.
<<operation>> Class An abstract, description of an action supported by the service. An <<operation>> class represents an operation component of the WSDL metamodel.
<<output>> Association An <<output>> association represents a relationship between an operation and a message the WSDL metamodel.
<<part>> Class A <<part>> class represents a part component of the WSDL metamodel.
type Type is a base type XSD. It is optionally and must be defined when the part component uses a base type but not when the part component uses an element of the XML Schema.
<<partElement>> Association A <<partElement>> association represents a relationship between a part component of the WSDL metamodel and
60ICT
UML profile for WSDL (3)UML representation Text representation
31
61ICT
Transformation to WSDLThe WSDL artifacts are generated from the Service part of the PIM4SOA model.While the mapping of the PIM4SOA to XSD was quite straight forward, the mapping to WSDL is a bit more complex.The WSDL generated has links to the XML schema, as the messages in the PIM4SOA model get their structural information from the Information part of the PIM4SOA models.
62ICT
PIM4SOA main mappings to WSDL
A binary Collaboration (only two roles) that does not contain
any CollaborationUses (leaf Collaboration) is transformed into
an operation. If only one of the Roles in the Collaboration
have Messages an asynchronous pattern is generated
meaning that two operations are created, each in different
PortTypes; one for the provider and one for the consumer.
OperationCollaboration
A role binding within a CollaborationUse is a potential
PortType. It is transformed into a PortType if the role it is
bound to is part of a binary Collaboration without any
CollaborationUses (a leaf collaboration)
PortTypeRoleBinding
If the PIM4SOA Message has a type assigned to it, the
WSDL message is created with one Part corresponding to
hat type. If not one Part is created for each of the Items
contained by the PIM4SOA Message.
MessageMessage
The transformation takes a complete PIM4SOA model as
input and creates on WSDL artefact per model.
DefinitionPackage
NotesWSDLequivalent
PIM4SOAelement
32
63ICT
RSM and UML profile for Web services
64ICT
Web Services Business Process Execution Language (WS-BPEL)
33
65ICT
Web Services Business ProcessExecution Language (WS-BPEL)
DescriptionWS-BPEL (or BPEL for short) is a language based on XML that allows for controlling the process flow of a set of collaborating Web services.It can be seen as a (business) extension to the Web services paradigm. Partner interaction is based on the notion of peer-to-peer interaction between Web services.BPEL introduces concepts to express the peer-to-peer conversational relationships between services.Partner links specify the services that a business process interacts with and is introduced as a WSDLextension element.
T. Andrews, F. Curbera, H. Dholakia, Y. Goland, J. Klein, F. Leymann, K. Liu, D. Roller, D. Smith, S. Thatte, I. Trickovic, and S. Weerawarana, "Business Process Execution Language for Web Services Version 1.1", May 2003. ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf
66ICT
BPEL: Simplified viewA BPEL process is a composite Web service with a WSDL description.
34
67ICT
BPEL: Roles in the Web ServicesWorld
As a public specification of abstract services protocolsbusiness partners can supply precise information about semanticsof a service and its message properties......without revealing internal (opaque) details of implementation
As an intermediate language for implementing business processes:
relatively portableextensible for platform-specific operations possible
As a programming language for internet-scale distributed applications
messagingconcurrencyerror handling...
68ICT
BPEL Foundations
35
69ICT
BPEL: Details• Two Uses
– Executable process descriptions– Business protocol descriptions – Abstract
processes• Partner links
– Paired WSDL interfaces– Correlation sets
Bind messages to process/activity instances.– Endpoint references
• Partner– Grouping constraint on partner links to a single
business partner.• Process Activities
– Basic - assign, throw, terminate, wait, empty, compensate
– Partner interaction - receive, reply, invoke– Structured - sequence, switch, while, pick,
flow, scope
Process
Partner - Links
WSDL PortType
70ICT
BPEL: Process and scope activities
PrimaryActivity
Partner Links
Partners<process/> only
Fault HandlersCompensation
Handler
Event Handlers
Install special purpose activities in scope
Compensation of completed scopes
Variables
Message variables shared by activities in <scope/>
Correlation SetsCorrelation sets for associating messages with process/activity instances
36
71ICT
BPEL example
72ICT
BPEL example
PO : POMessage
Invoice : InvMessage
receive
reply
shippingInfo
shippingSchedule
flow
sequence sequence sequence
37
73ICT
WSDL PortType XML syntax
<portType name="purchaseOrderPT"><operation name="sendPurchaseOrder">
<input message="pos:POMessage"/>
<output message="pos:InvMessage"/>
<fault name="cannotCompleteOrder"
message="pos:orderFaultType"/></operation>
</portType>
74ICT
Partner Link Types
38
75ICT
Purchase Order WSDL<message name="POMessage">
<part name="customerInfo" type="sns:customerInfo"/>
<part name="purchaseOrder" type="sns:purchaseOrder"/>
</message>
<message name="InvMessage">
<part name="IVC" type="sns:Invoice"/>
</message>
<message name="orderFaultType">
<part name="problemInfo" type="xsd:string"/>
</message>
<message name="shippingRequestMessage">
<part name="customerInfo" type="sns:customerInfo"/>
</message>
<message name="shippingInfoMessage">
<part name="shippingInfo" type="sns:shippingInfo"/>
</message>
<message name="scheduleMessage">
<part name="schedule" type="sns:scheduleInfo"/>
</message>
76ICT
Port Types supported by the purchase order process<!-- portTypes supported by the purchase order process --><portType name="purchaseOrderPT">
<operation name="sendPurchaseOrder"><input message="pos:POMessage"/><output message="pos:InvMessage"/><fault name="cannotCompleteOrder"message="pos:orderFaultType"/>
</operation></portType><portType name="invoiceCallbackPT">
<operation name="sendInvoice"><input message="pos:InvMessage"/>
</operation></portType><portType name="shippingCallbackPT">
<operation name="sendSchedule"><input message="pos:scheduleMessage"/>
</operation></portType>
39
77ICT
Partner Link Types
<plnk:partnerLinkType name="purchasingLT"><plnk:role name="purchaseService">
<plnk:portType name="pos:purchaseOrderPT"/></plnk:role>
</plnk:partnerLinkType>
<plnk:partnerLinkType name="invoicingLT"><plnk:role name="invoiceService">
<plnk:portType name="pos:computePricePT"/></plnk:role><plnk:role name="invoiceRequester">
<plnk:portType name="pos:invoiceCallbackPT"/></plnk:role>
</plnk:partnerLinkType>
78ICT
BPEL Process<process name="purchaseOrderProcess"
targetNamespace="http://acme.com/ws-bp/purchase"
xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:lns="http://manufacturing.org/wsdl/purchase"><partnerLinks>
<partnerLink name="purchasing"
partnerLinkType="lns:purchasingLT"
myRole="purchaseService"/>
<partnerLink name="invoicing"
partnerLinkType="lns:invoicingLT"
myRole="invoiceRequester"
partnerRole="invoiceService"/>
<partnerLink name="shipping"
partnerLinkType="lns:shippingLT"
myRole="shippingRequester"
partnerRole="shippingService"/>
<partnerLink name="scheduling"
partnerLinkType="lns:schedulingLT"
partnerRole="schedulingService"/>
</partnerLinks>
40
79ICT
BPEL process<sequence><receive partnerLink="purchasing"
portType="lns:purchaseOrderPT"operation="sendPurchaseOrder"
variable="PO"></receive>
<flow><links>
<link name="ship-to-invoice"/><link name="ship-to-scheduling"/>
</links>
<sequence><assign>
<copy><from variable="PO" part="customerInfo"/><to variable="shippingRequest"part="customerInfo"/>
</copy></assign>
80ICT
BPEL process<invoke partnerLink="shipping"
portType="lns:shippingPT"operation="requestShipping"inputVariable="shippingRequest"outputVariable="shippingInfo">
<source linkName="ship-to-invoice"/></invoke>
<receive partnerLink="shipping"portType="lns:shippingCallbackPT"operation="sendSchedule"variable="shippingSchedule">
<source linkName="ship-to-scheduling"/></receive>
...
41
81ICT
UML profile for BPEL (1)Stereotype UML
construct Description
<<assign>> Action An assign activity maps to a BPEL assign activity with each entry action mapping to a copy element. The right-hand side of each assign statement provides the details of a from element and the left-hand side provides then details of the to element.
<<catch>> Action When an invoked operation throws an exception, or a throw activity explicitly throws an exception, normal execution within the containing scope is terminated.An exception can be caught within the containing scope so that error recovery behavior can be performed. This is modelled as an <<catch>> activity.
<<compensate>> Action Compensation can be triggered by a compensate activity. We follow the BPEL semantics for compensation and when it can be triggered. In particular, a compensate activity is only permitted in the following places: • In a catch activity of the scope that immediately encloses the
scope for which compensation is to be performed. • In the compensation handler of the scope that immediately
encloses the scope for which compensation is to be performed.
<<compensationHandler>> Action Compensation handler activities can be defined to reverse the work performed by a scope, if necessary. Compensation handler activities are not executed when control reaches the parent activity. If the parent activity completes successfully then the compensation handler is installed.
<<correlation>> Class, Property A correlation set is defined by a class stereotyped by <<correlation>> containing attributes with names and types matching those of properties defined within its namespace. A process specifies that it uses a correlation set through an attribute with the type of the correlation set. The stereotype <<correlation>> can also be applied (redundantly) to the attribute to distinguish it from other attributes.
82ICT
UML profile for BPEL (2)the attribute to distinguish it from other attributes.
<<data>> Class A message type has a number of parts, each of which is of a specified data type. Data types are represented by classes stereotyped as <<data>>.
<<external>> Package External packages contain elements that are defined in another model or elements that are defined directly as platform-specific artifacts (such as Web services or BPEL documents). External packages are not mapped to platform-specific artifacts. Elements that are reused can be modeled explicitly and placed in a package stereotyped with <<external>>.
<<invoke>> Action An invocation of an operation on a partner is represented as an activity with stereotype <<invoke>> with an entry action indicating the operation to be invoked and the attribute containing the input message. For two-way messages, assignment notation is used to indicate the attribute that is updated with the reply message.
<<loop>> Action A looping node is shown as an activity with the stereotype <<loop>>, which contains a decision node and an activity to be repeated, with a control link from the decision node to the activity. The guard on the control link provides the Boolean expression which determines whether the activity is executed each time round the loop.
<<messageContent>> Class A message type has a number of parts, each of which is of a specified data type. Message types are represented by classes stereotyped as <<messageContent>>
<<pick>> Action, It is often useful to group a set of receive activities and
42
83ICT
UML profile for BPEL (3)
84ICT
Transformation to BPELStarting point for a BPEL transformation
PIM4SOA ServiceProvider participating in at least one Collaboration and implementing a Behaviour as a PIM4SOA Process.
The transformation from PIM4SOA to BPEL are closely tied to the generation of the WSDL interfaces The WSDL transformation allows
collaborations in which a ServiceProvider participates to be converted to Services and Porttypes, and Partnerlink types to be referenced in the BPEL.
43
85ICT
PIM4SOA main mappings to BPEL
This defines a specific use of a PartnerLink, alongside what role we
are playing, and even the PortType being used. See links to the
WSDL transformation described below.
PartnerLink, Role(…) CollaborationUsePath
The CollaborationUses defined for the ServiceProvider tell us what
PartnerLinks we will need. See CollaborationUsePath.
PartnerLinkCollaborationUseRoleBinding
All messages sent and received must have appropriate variables
defined within the BPEL
VariableMessage
Interactions have a role to play both in determining collaboration type
(see Task (ii) above), and passing particular parts of messages
between tasks (data flow, a BPEL assign).
AssignInteraction, Pin
The structure of flows between Steps must be analysed to deduce the
applicable BPEL structure.
Sequence, Flow, (…)Flow
This might be a task requiring further implementation or human
interaction beyond the scope of the PIM4SOA.
EmptyTask (ii) (no collaboration use)
The type of communication with other service providers must be
deduced from parameters passed to or from the task in question.
Receive, Invoke, ReplyTask (i) (participating in collaboration)
ProcessServiceProviderProcess
NotesBPELequivalent
PIM4SOA element
86ICT
Hvordan håndtere SikkerhetHva slags overordnet strategi bør man ha for sikring av informasjon?
For å kunne realisere en effektiv strategi for sikring av sensitiv informasjon er det viktig at alle nivåer i en organisasjon har begreper om hva informasjonssikkerhet innebærer. Begrepene bør først innarbeides og forankres i organisasjonens ledelse, slik at det blir avsatt nok ressurser på å gjøre det nødvendige arbeidet. Ved å kartlegge hva slags informasjon man egentlig sitter på og klassifisere dette etter sensitivitet og hvilken verdi informasjonen har for organisasjonen, kan man få et bilde av hvilke tiltak som kan være hensiktsmessig å implementere. En risikoanalyse av hele organisasjonens systemer kan derfor være med på å avdekke risika og støtte opp under en vurdering om hvilke risika som må håndteres. Det vil alltid være en avvegning mellom bekvemmelighet og sikkerhet, slik at det er viktig å innføre mekanismer og policy-er som harmonerer med det som skal sikres. Dette gjelder også i forhold til systemytelse, hvor sterkere sikkerhetsmekanismer krever mer ressurser. Av den grunn er det også viktig å inkorporere sikkerhetsaspekter så tidlig som mulig, siden de kan ha signifikante innvirkninger på flere forretningsprosesser, i flere nivåer. Det bør altså utvikles en sikkerhetspolicy som spenner om hele organisasjonens virke, samt lages policy-er som spenner over ett eller flere domener innenfor organisasjonen som deler spesielle behov for informasjonssikring. Alle disse policy-ene må så reflekteres ned i systemene som behandler informasjonen.
I hvilken grad kan sporbarhet oppnås?Ofte kan det være ønskelig at alle transaksjoner som følger av en forespørsel skal kunne spores til hvilken entitet som først initierte forespørselen. Dvs at hvis f.eks. en lege gjør en forespørsel om en pasients journal kan identiteten til legen, eller noe som kan knyttes til legens identitet, følge forespørslene videre til andre systemer som eventuelt innehar informasjon som er en del av pasientens journal. Ved å loggføre all aksess til informasjonen i alle ledd kan man spore forespørslene nedover i systemene og derfor oppnå god sporbarhet i informasjonsflyten.
Hvordan kan man effektivt kontrollere tilgangen til tjenester?En bør søke å integrere autentiserings- og autorisasjonsprosessene mest mulig med eksisterende løsninger for brukerstyring. Det letter administrasjonen av hele livssyklusen til hver enkelt bruker ved å sentralisere opprettelse, oppdatering og sletting av brukere ogderes attributter.
Hvilke strategier kan man ha i forhold til intern identitetshåndtering?Mange systemer er lagd for å være fullstendig autonome og har derfor sin egen brukerdatabase som må vedlikeholdes. Hvis en organisasjon har mange slike systemer kan det være fornuftig å relatere alle disse kontoene til én identitet vha en metakatalog. Denne metakatalogen kan da distribuere brukerattributter til de forskjellige systemene slik at informasjonen hele tiden er oppdatert. I enkelte situasjoner kan det t.o.m. være ønskelig å holde to systemers brukere separate for å oppnå større kontroll og uavhengighet mellom systemene. I slike tilfeller kan metakataloger også være til nytte.
Hvilke strategier kan man ha for ekstern identitetsføderering?Idag er det to alternative rammeverk som kan håndtere føderasjon av identiteter. Liberty ID-FF har allerede blitt implementert i produksjonssystemer, mens WS-Trust fortsatt ikke har kommet til ferdigstillelse og har derfor smalere støtte. OASIS opprettet en komité i desember 2005 som skal drive standardiseringsprosessen for denne spesifikasjonen til sluttførelse.
44
87ICT
Hvordan håndtere sikkerhet (2)Web services standarder
Hvordan kan man sikre konfidensialitet?WS-Security definerer bruk av XML Encryption, en W3C standard, som mekanisme for å kunne kryptere hele eller utvalgte deler av et XML-dokument.
Hvordan kan man sikre integritet?WS-Security definerer bruk av XML Signature, W3C standard, som mekanisme for å signere hele eller utvalgte deler av et XML-dokument.
Hvilke krav bør man ha til autentisering?Avhengig av informasjonen som skal beskyttes kan man autentisere på flere forskjellige måter. Den vanligste formen for to-faktor autentisering er passord og brukernavn. For å oppnå sterk autentisering kan det f.eks. brukes sertifikater. Sertifikater er mer ressurskrevende for systemet, krever en mer omfattende infrastruktur og koster mer å distribuere.
Hvilke krav bør man ha til kryptering?Datatilsynet anbefaler 128 bits trippel-DES (Data Encryption Standard) som krav til cipher som skal sikre konfidesialitet for sensitive opplysninger. Denne formen for kryptering er anslått som forholdsvis sikker men er ressurskrevende. Den nyere AES (Advanced Encryption Standard) som ble standardisert av National Institute ofStandards and Technology (NIST) i 2000 og ble en Federal Information ProcessingStandard (FIPS) i 2002 er vesentlig raskere og har etterhvert også blitt videntimplementert. Forøvrig har AES foreløpig kun anbefalt-status i WS-Is Basic Security Profile 1.0.
88ICT
Semantic web architecture – parallell utvikling - vil bidra til semantiske web tjenester i fremtiden
45
89ICT
Some Referenceswww.w3c.orgwww.xml.comwww.xml.orgwww.oasis-open.org
www.bizTalk.orgwww.UDDI.orgwww.ebXML.org
www.oasis-open.org/cover/xml.html
90ICT
HUSK - Onsdag 19. april 2006 kl. 0900-1630
– OMG MDA Information Day -GSK Konferansesenter , Blindern, Oslo(over jordet fra Ifi – i retning SINTEF og Rikshospitalet)
Gratis for INF-5120 studenter
Andrew Watson, OMG - om MDA, SOA og BPM m.m.
Program og påmelding: www.jaoo.dk/omgVelg Invoice som betalingsform. Når du har registreret deg send en mail til mai@eos.dk, med "Student OMG" i subject.
46
91ICT
Neste Forelesning, F12, torsdag 20/4Professor emiritus Trygve Reenskaug(Tidligere ansvarlig for forløperen til INF5120, IN-MMO, Modelleringmed objekter”) – og opphavspersonen for MVC (i Smalltalk fra Xerox PARC) og OORAM rolle-modell metodikken (Bok 1996).
Forelesnings tittel:"MVC and DCA: Two complimentary system architectures”
The Model View Controller pattern/paradigm was developed as a suitable abstraction for many system architectures. The new DCA (Programs = Data + Communication + Algorithms) pattern provides a recommended approach for describing system architectures in general – with a foundation in OOram and UML 2.0”