F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA...

46
1 1 ICT F11: SOA og Web Services realisering David Skogan, Arne-Jørgen Berre, Brian Elveseter SINTEF 2 ICT 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)

Transcript of F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA...

Page 1: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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)

Page 2: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 3: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 4: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 5: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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.

Page 6: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

6

11ICT

Web Services Architecture

BPEL

12ICT

Web services architecture

Page 7: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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?

Page 8: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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.

Page 9: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 10: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 11: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 12: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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”.

Page 13: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 14: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 15: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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)

Page 16: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og 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

Page 17: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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.

Page 18: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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>

Page 19: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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.

Page 20: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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.

Page 21: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 22: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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.

Page 23: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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)

Page 24: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 25: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 26: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 27: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 28: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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.

Page 29: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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.

Page 30: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 31: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 32: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

32

63ICT

RSM and UML profile for Web services

64ICT

Web Services Business Process Execution Language (WS-BPEL)

Page 33: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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.

Page 34: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 35: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 36: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

36

71ICT

BPEL example

72ICT

BPEL example

PO : POMessage

Invoice : InvMessage

receive

reply

shippingInfo

shippingSchedule

flow

sequence sequence sequence

Page 37: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 38: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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>

Page 39: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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>

Page 40: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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>

...

Page 41: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 42: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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.

Page 43: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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.

Page 44: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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

Page 45: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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 [email protected], med "Student OMG" i subject.

Page 46: F11: SOA og Web Services realisering - Universitetet i oslo · SOA og Web Services realisering MDA og PIM -> PSM transformasjoner SOA og Web Services UDDI Registry SOAP XML og XSD

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”