f12 interoperability soa profile bre - uio.no · software developer cryptokeys frequencies subnet -...

45
1 ICT INF5120 Modellbasert systemutvikling Interoperability UML Profile for EDOC Java 2 Enterprise Edition (J2EE) Service-Oriented Architectures Web Services Forelesning 14.04.2005 Brian Elvesæter ICT Interoperability

Upload: doankhanh

Post on 09-Feb-2019

225 views

Category:

Documents


0 download

TRANSCRIPT

1

ICT

INF5120Modellbasert systemutviklingInteroperabilityUML Profile for EDOCJava 2 Enterprise Edition (J2EE)Service-Oriented ArchitecturesWeb Services

Forelesning 14.04.2005Brian Elvesæter

ICT

Interoperability

2

ICT

Diskusjonsoppgave

Sett dere sammen to-og-to og diskuter begrepet ”interoperabilitet”

ICT

Interoperability

Interoperability, key to increasecompetitiveness of enterprises

The cost of non-interoperability

are estimated to 40% of

enterprises IT budget.

System Implementation budget

Integration40%

Imp. Services

20%

Software10%

Hardware10%

Misc.20%

Interoperability (Def) is “the ability of two or more systems or components to exchange information and to use the information that has been exchanged”

IEEE Standard Computer DictionaryCarnegie Mellon, Software Technology Roadmap, 2004

Enterprise systems and applications need to be interoperable to achieve seamless operational and business interaction, and create networked organizations

European Group for Research on Interoperability, 2002

(Source: the Yankee Group 2001)

3

ICT

Integration and Networked Enterprises

Sensors andActuators

Mobile OperationalFacility (e.g., COP)

Remote OperationalTerminal (PC, PDA...)

Horizontal integration

Vert

ical

inte

grat

ion

People andOperations

Sofware Logic, Middelware, andProtocols

CommunicationNetworks

ICT

Networked Enterprise

SoftwareDeveloper

cryptoKeys

Frequencies

Subnet- nettId- nettType- name- frequency- frequencyChangeTime- newFrequency- frequencyFMprai- frequencyDigPray- areaCode- KVTid- KVTchangeTime

Main frequencies- emitterType- fr equency- emiss ionType- area(polygon, circle)- class of stati on(mobile, poi nt-point, ground-air)

Frequency requirements- emitterType- emiss oinType- area- class of station[mobil e, p oint-point, ground-air ]- timerange- usage[send, receive,. ..]- securityLabel[(NATO) unclass ifi ed, restricted, confidentia l, s ecret]

Decoding list

Telephone DirectoryAddressee

SOICOP

Realisation View(e.g. Design & Implementation Models)

op1

op2

Realis

atio

n Vi

ewpo

int

SystemIntegrator

Software Component View(e.g. Component Interface Models)

Deployed Unit #1InformationService #1

Command Center

iProcess

InformationService #2

Deployed Unit #2

iNotification iPublishNotificationService

ProcessingService

Ethernet

Satelite

Radio

InformationInformationSoftware Com

ponent

Viewpoint

BusinessAnalyst

Business View(e.g. Business Process Models)

ARCADE data

FOFAS børkunneoppdatereARCADE: COP

Actual and planned

draft TASKORG : Frequency requirements

verified list : Frequencies

From Div 6, FO/I, KA mobile avd, LV

final TASKORG : Frequency requirements

temp verified list : Frequencies

Receive ARCADE data

Generate Frequency list

Receive frequency requirements from lower level

Receive COP

Establish/maintain frequency pool

temporary list : Frequencies

Verify security level

Distribute Frequency list

Verify Frequency list

new operationnew campaign

list : Frequencies

new operationDistribute temporary Frequency list

new campaign

Joint LevelLower Echelon UnitCOPdistributorARCADE system

Busi

ness

View

poin

t

Arm y Command 1. Pre -pl anni ng

TASKORG

2 . Plann ing

<<include>>

K2 IS/NORCCIS II

COP

COP

Op erati onalPl anDevel ope r

OP lan

OPlan

CryptoCust

3. Cal cula te frequency requirements

<<include>>

5. Verify frequencies

COP

6. S earch op tions

7. Manage SOI

4 . Al loca te frequenc ies

cryp toKeys

<<i ncl ude>>

<<incl ude>>

<<i ncl ude>><<include>>

8 . M anage Comm un icati on Secu ri ty

<<inc lude>>

FEFAS

End-User

User Requirements View(e.g. Use case models)

User Requirements

Viewpoint

4

ICT

IDEAS Reference Model

Business

Knowledge

ICT

Business

Knowledge

ICT

Sem

antic

s

Sem

antic

s

Enterprise A Enterprise B

To achieve meaningful interoperability between enterprises, Interoperability must be achieved on all layers:

Business layer: business environment and business processesKnowledge layer: organisational roles, skills and competencies of employees and knowledge assetsICT layer: Applications, data and communication componentsSemantic dimension: support mutual understanding on all layers

ICT

Framework 1st Level

Framework2nd Level ONTOLOGY QUALITY ATTRIBUTES

Semantics Security Scalability Evolution

Business Decisional Model

Business

Model

Business Processes

Knowledge Organisation

Roles

Skills Competencies

QUALITY ATTRIBUTES

E N T E R P R.

M O D E L

Knowledge Assets

Performance Availability Portability

Application Solution Management

Workplace

Interaction

Application Logic

Process

Logic

Data Product Data

Process

Data

Knowledge Data

Commerce

Data

A R C H I T E C T

P L A T F O R M

Communication

IDEA

S R

efer

ence

Mod

el

5

ICT

The Waves of Client/Server Technology

Base Source: Client/Server Survival Guide, 1994Robert Orfali, Dan HarkeyOS/2 Edition, VNR Computer library + AJB update 2003

1982 1986 1990 1994 1998 1999 2000 2001 2002 2003

FileServers

Database Servers

Groupware

TP Monitors

DistributedObjects

FirstWave

SecondWave

ThirdWave

OMG CORBACOM/OLEWeb/InternettJava

J2EE/EJBCOM+Corba Comp

Server-sidecomponentsc

MDA, WebServices, .NetService-orientedArchitectureSOAP, XML

WSDL/WSFL

FourthWave

FifthWave

P2PGrid

Agents,FIPA

ICT

DeferredSynch request

Naming service

Persistence service

ServerComponents

Message

Transaction service

Concurrencyservice

XML

Synchron.request

Event - publish & subscribe

Data services &Legacy systems

Shared BusinessServices

User services(application/process)

Interaction/Presservices

Trading serviceSecurityservice

Workflowservice

Streaming

Integration service

User InterfaceDocument modelWeb interaction

System/Use Mngt

MultiMedia,QoS

6

ICT

Enterprise Model(EM, CIM)

PlatformindependentModel (PIM)

PlatformSpecificModel

AKM iiEM execution

platform

PIM execution platform(UML virtual machine +

local services developed from PSM)

PSM execution platform(web services, bpml, bpel, .net, J2EE)

Program code

Model

Executionplatform(includescode and

model-drivenservices from

the levelbelow)

Programming andcode generation.

PSM services that are coded becomepart of the PIM execution platform,

implemented PIM servicesbecome part of the AKMii.

Ad-hoc, unique processes(partial automation)

Repetitive, adaptive routine processes

Standard, repetitive, static processes

Processes executed by platformEnd user

Processdesigner

Systemdesigner

R

R

R

RRepository

Enterprise, Conceptual & ICT Platform levels

ICT

Enterprisemodel

PlatformindependentModel (PIM)

PlatformSpecificModel

AKM ii - EMexecutionplatform

PIM execution platform

PSM execution platform

Enterprisemodel

PlatformindependentModel (PIM)

PlatformSpecificModel

AKM ii - EMexecutionplatform

PIM execution platform

PSM execution platform

Ontology-.basedsemantic

interoperability?

Web services(Uddi, Soap)

Bpml, Bpel, Xpdl?

Enterprise modelinteroperability

(UEML)

Network protocols

Integrate enterprise modelsacross companies and EMtools

Exchange information despitesemantic and syntacticalincompatibility

Enable enterprises to invokeservices (and processespackaged as services) fromeach other, and include remoteservices in local processes

Interoperability objective

Interoperability Challenges

7

ICT

Bus

ines

sK

now

ledg

eS

yste

ms

year 1 year 2 year 3 year 4 year 5

persistent services

reasoning

busines process ontology

process model interoperability

modelling Collaborative Business Processes

Unified Paradigm Interoperability Infrastructure

Federated Paradigm Interoperability Infrastructure

Flexible Enterprise &Process Customisation

Support

networked EM language\

Enterprise Visual Scenes/Holistic Enterprise Design and Operation

roles and policies

enterprise model interoperability

(distributed) model generated solutions and work

places

servicedescription

Service discovery

service negotiation

Collaborative Business Process Execution

Semantic Mapping & Mediation

Autonomous Architectures

Model Driven SoA

ActiveModels

FederatedArchitectures

Non-functionalInteroperability

semantic annotation techniques and tools

Networked Enterprise Operation Support

serviceorchestration

servicebrokering & mediation

ATHENA Research Challenges in spanning the Domains Modelling, Ontology and Architecture

ICT

Scientific & technology objectives*

to define a technologically neutral reference model that provides a stable, generic foundation for specific technical innovations; to define interoperability requirements for applications, data and communications and provide solutions that meet these requirements;to provide methods which enterprises can use to manage organisational roles, skills, competencies, and knowledge assets for its own operation and for collaboration with other enterprises;to provide semantic mediation solutions which enable and support the above; to provide components of interoperability infrastructures

* objectives have been set for the 5 year programme

8

ICT

UML Profile for Enterprise DistributedObject Computing Specification

http://www.omg.org/technology/documents/formal/edoc.htm

ICT

UMLProfile

Common Model Element

UML Meta-Model

UML Profile

<<subset>>

0..*0..*

(Meta)ModelElement1..*1..*

1..*1..*

0..n

1..1

<<instance>>Additional StandardElement0..*0..*

1..*1..*

"A UML Profile is a predefined set of Stereotypes, Tagged Values, Constraints and notation icons that collectively specialize and tailor the UML for a specific domain or process (e.g., Unified Process profile). A profile does not extend UML by adding any new basic concepts. Instead, it provides conventions for applying and specializing standard UML to a particular environment or domain."

9

ICT

UML Extensions & Profiles

Data services &Legacy systems

Shared BusinessServices

User services(application/process)

Interaction/Presservices

Integration service

UML for EDOC Components- Implementation neutral- CORBA- J2EE/EJB- COM+

UML for EAI(Enterprise ApplicationIntegration)

- MQSeries- Messages, events

UML for Workflow- Workflow processUML for Real Time

- Capsules, extended state machines-

- Quality of ServiceUML for Databases- Relational- Object-Oriented

UML for Web & User Interfaces

- Web, Genova, XML

UML for Business ProcessModeling- Extended Activities

UML for Legacy Systems- Interface Modeling

UML for Prog. Languages- C++, Java, Smalltalk- Visual Basic, ...

ICT

Enterprise Collaboration Architecture (ECA)

ECA is a model-driven architecture approach for specifying Enterprise Distributed Object Computing (EDOC) systems.

recursive collaborationdifferent levels of granularity, for both business and systems modelingloosely and tightly connected systemssynchronous and asynchronous communicationcontainer managed and message-based architectures.

10

ICT

ECA Models

Component Collaboration Architecture (CCA) details how to model, at varying and mixed levels of granularity, the structure and behaviour of the components that comprise a system.Entities model describes how to model entity objects that are representations of concepts in the application problem domain and define them as composable components.Events model describes a set of model elements that may be used on their own, or in combination with the other EDOC elements, tomodel event driven systems.Business Process model specializes the CCA, and describes a set of model elements that may be used on their own, or in combination with the other EDOC elements, to model system behaviour in the context of the business it supports.

ICT

EDOC & Technology Mapping

ProcessEntities

ProcessBusinessProcess

Collaboration Component Architecture

ProcessEvent

ProcessRelationship

Component Model MappingEJBCOM CORBA

Message Model MappingebXML MOM

DCP

ebXMLebXML

FCM

WorkWorkFlowFlow

Architecture Patterns

Enterprise CollaborationArchitecture

Webservices

11

ICT

UML for EDOCCCA

ProcessComponent Structural specification (Component/Protocol)Choreography, Composition, Document ModelModel Management, CCA Notation and UML 1.4 Notation

Entities profile Entity component, Data Manager - Composite dataIdentity, Entity Data, Key, Entity role (ad hoc extension), Data ProbeEvents (Publication/Subscription flow ports), Information viewpoint, Composition viewpoint

Events profileBusiness Processes profile

BusinessProcess, CompoundTask, Activity, ProcessPortConnector, ProcessFlowPort, DataFlow, InputGroup, OutputGroup, ProcessMultiPortProcessRole, Performer, Artifact, ResponsibleParty

Relationships profilePatterns profile

ICT

ECA and viewpoints

Enterprise

ComputationalInformation

Engineering

Technology

ProcessProcessCCACCA

EntityEntity

RelationshipRelationshipEventEvent

EntityEntity

RelationshipRelationship

CCACCA

EventEvent

DCPDCPMessaging

UML for J2EE EJB/JMSUML for J2EE EJB/JMS

CORBA 3/ CCMCORBA 3/ CCM

COM

SOAP

ebXML

PatternsPatterns

PatternsPatterns

PatternsPatterns

PatternsPatterns

PatternsPatterns

12

ICT

ECA and RM-ODP viewpointsEnterprise viewpoint

(CCA, Process, Entity, Relationship, Event)

Information viewpoint (Entity, Relationship)

Computational viewpoint(CCA, Event)

Engineering viewpoint(DCP - Distributed Component Profile/Messaging)

Technology viewpoint(UML for J2EE/EJB/JMS, CORBA 3/CCM, COM, SOAP, ebXML, ...)

(Patterns - applied to all viewpoints)

ECA documents

DCP document

other documents

Part IVECA to

DCP /Messaging(this document)

ICT

The Marketplace Example

Mechanics Are UsBuyer

Acme IndustriesSeller

GetItThere FreightShipper

Order

Conformation

Ship Req

Shipped

Shipped

PhysicalDelivery

Delivered

Status

ProcessComplete

13

ICT

CCA example: Community Process

ICT

Activity diagram shows protocol

Start

Sending ProtocolMessage

sell_role_Orderbuy_role_Order

Order

OrderConfirmation

OrderDenied

BuySellProtocol

Success

Failure

Receiving ProtocolMessage

Protocol

ProtocolRole(initiator)

ProtocolMessages

TerminateSuccess

TerminateFailure

ProtocolRole

14

ICT

Deriving provided and required Component Interfaces

BuyerC

Additional communication refinement can be done:(Conversation, client/server, notification, streaming, …) + other DCP refinement

SellerC

ShipperC

buyRoleOrder buyRoleOrder

sellRoleShipping

shipRoleShippingshipRoleInfo

buyRoleInfo

ICT

Drill down to sub-components & activities with events

15

ICT

Entities & Relationships

OrderCD(from OrderBT)

+ idNumber : Integer+ custId : Integer+ companyName : String+ address : AddressCD+ items [1..n] : OrderItemCD

<<CompositeData>>OrderConfirmationCD

(from OrderBT)+ name : String+ order : Order+ total : Float+ idString : String

<<CompositeData>>AddressCD

(from OrderBT)+ addressLine1 : String+ addressLine2 : String+ city : String+ state : String+ postalCode : String+ country : String

<<CompositeData>>OrderDeniedCD(from OrderBT)

+ order : OrderCD

<<CompositeData>>OrderItemCD

(from OrderBT)+ productId : String+ quantity : Integer

<<CompositeData>>

Address<<Entity>>

+ addressLine1 : String+ addressLine2 : String+ city : String+ state : String+ postalCode : String+ country : String

Customer+ custId : Integer+ companyName : String

<<Entiry>>

1+address 1

<<Reference>>Order<<Entity>>

+ idNumber : Integer1+customer 1

<<Reference>>

Product<<Entity>>

+ productId : StringOrderItem

+ quantity : Integer

<<Entity>>

1..n +items1..n<<Assembly>>

1+product 1

<<Reference>>

ICT

Mapping to ebXML (Messaging/SOAP)

CPP: Collaboration Protocol ProfileCPA: Collaboration Protocol AgreementBT: Business TransactionBD: Business Document

Ref: www.ebxml.org

BuyerC<<BusinessServiceInterface>>

Sel lerC<<BusinessServiceInterface>>

SalesProtoco l<<CPP>>

OrderBT<< BT >>

buyRoleOrder

+ orderC onf irme d() : ord erConfB D+ orderDenied() : orderD enB D

<<P rotoc o lRole>>

sel lR ol eOrder

o rde r(Ord erBD )

<<P roto co lRole >>

buy<<Protoco lPort>>

sel l< <Prot oco lP or t>>

<<connection>>

Sal esP rotoco lS<<CPP>>

M essageAg<<CPA>>

Order< <Bu sine ssDo cum en t>>

16

ICT

Mapping to DCP - Distributed Component Profile

BuyerC<<ControllerDC>>

SellerC<<ControllerDC>>

ShipperC<<ControllerDC>>

OrderProcessC<<ControllerDC>>

ShippingC<<ControllerDC>>

ReceivablesC<<ControllerDC>>

CustomerC<<E ntit yDC>>

OrderC<<E ntit yDC>>

ProductC<<E ntit yDC>>

ICT

Java 2 Enterprise Edition (J2EE)

17

ICT

Remote MethodInvocation (RMI, IIOP)

Naming andDirectory Interface

(JNDI)

DatabaseConnectivity

(JDBC+)

Servlets &Java Server Pages + XSL

(Servlets +JSP)

EnterpriseJava Beans

(EJB)

Java MessagingService (JMS)

Transaction API (JTA, JTS)

Connectors(CICS, SAP, ERP)

XML

Java IDL(JMI)

Java Mail &Java Activation

Framework (JMI + JAF)

Data services &Legacy systems

Shared BusinessServices

User services(application/process)

Interaction/Presservices

JINI (Trading)

ICT

Java 2 Enterprise Edition

Java 2 Enterprise Edition(J2EE) ble utviklet for åadressere problemene rundtutvikling, deployering oghåndtering av flerlags system-løsninger.

En applikasjonstjener tilbyrkjøretidsinfrastrukturen ogtjenestene som er nødvendigefor å deployere applikasjonerog komponter i en distribuertomgivelse

18

ICT

J2EE API spesifikasjoner

Enterprise JavaBeans (EJB): Komponentarkitektur for å bygge gjenbrukbare tjenerkomponenter.JDBC: Javagrensesnitt mot relasjonsdatabaserJava Remote Method Invocation over the Internet-ORB Protocol(RMI-IIOP): Fjernmetodeinvokering mellom virtuelle Java maskiner. IIOP protokollen tillater integrasjon mot andre programmeringsspråk.Java Message Service (JMS): Asynkron kommunikasjon ved hjelp av meldinger.Java Interface Definition Language (Java IDL): En Java CORBA ORB som implementerer et subsett av CORBA spesifikasjonen.Connectors: Aksessintegrasjon mot andre informasjonssystemer som CICS, Tuxedo, SAP R/3 og PeopleSoft.

ICT

J2EE API spesifikasjoner (forts.)

JavaServer Pages (JSP): Dynamisk generering av websider.Java Servlets: Servlets er komponenter som deployeres på en webtjener.Java Transaction API (JTA): Transaksjonstjeneste.eXtensible Markup Language (XML): En Java XML API som gir et grensesnitt mot en XML parser.JavaMail: Elektronisk mail.JavaBeans Activation Framework (JAF): Automatisk aktivering av Java komponenter for å håndtere ulike objekter.Java 2 Platform Standard Edition (J2SE): Java 2 plattformen som inneholder standard kjernetjenester.

19

ICT

J2EE Components for Alternative Architectures

ICT

Java 2 Enterprise Edition (J2EE)

Enterprise JavaBean (EJB)

20

ICT

Goals of EJB

Standard component architecture for distributed business applications written in JavaEasy to write applications. Hide details of such areas as transaction and state management, multi-processing, resource pooling etc.Maintain the “Write-once, run anywhere” philosophy of JavaCompatible with other programming languages than JavaCompatible with CORBA

ICT

EJB 2.0

Integration of Enterprise JavaBeans with the Java Message Service™ (JMS). Improved Support for Persistence for Entity Beans. Support for Relationships among Enterprise JavaBeans. (Support for Inheritance and Subclassing of Enterprise JavaBeans. - not in 2.0)Query Syntax for Entity Bean Finder Methods Support for Additional Methods in the Home InterfaceLocal Interfaces Mechanisms for Container Extensions EJB Server Network Interoperability Protocol

21

ICT

EJB Container Framework

The server-side container provides the following to the enterprise Beans :

Component packaging and deployment (JAR, manifest, deployment descriptors)Declarative transaction management (your component do not need to do any explicit transaction management)Bean activation and passivation (bean is notified when it is loaded into memory and when it is deactivated from memory)Bean state managementContainer metadataSecurity

ICT

What the container providesThe diagram illustrates the view that a session container provides to its clients

22

ICT

The runtime objects

At runtime there is three objects involved for each enterprise beanThe home and remote objects are generated by the container, and forwards messages to the “real” bean

ICT

EJB - Session beans

CharacteristicsExecutes on behalf of the clientCan be transaction-awareUpdates shared data in an underlying databaseDoes not represent directly shared data in the databaseIs relatively short-livedIs destroyed if the EJB server crashes - in such cases the client must re-establish a new session object to continue

23

ICT

EJB - Entity beans

CharacteristicsRepresents data in the databaseIs transactionalAllows shared access for multiple usersCan be long-lived (lives as long as the data in the database)Survives crashes of the EJB server. A crash is transparent to the client

Entity beans are persistent, allow shared access, and have primary keys.

ICT

Enterprise Bean’s home interface

The home interface allows the client to :create new EJB objectsremove existing EJB objectsget the metadata for the enterprise beanfind existing EJB objects (only for entity beans)

The Home interface can be located using the Java Naming and Directory Interface (JNDI)

24

ICT

Enterprise Bean’s remote interface

The remote interface defines the “business” methods of the enterprise beanThe methods defined in this interface must follow the rules for Java RMI. This means that their arguments and return values must be of valid types for Java RMI, and their throws clause must include the java.rmi.RemoteException.For each method defined in the remote interface, there must be amatching method in the enterprise Bean’s class. The matching method must have:

The same name.The same number and types of its arguments, and the same return type.All the exceptions defined in the throws clause of the matching method of the enterprise Bean class must be defined in the throws clause of the method of the remote interface.

ICT

EJB - Session and Entity Beans

25

ICT

Java 2 Enterprise Edition (J2EE)

UML Profile for EJB

ICT

UML for EJB- from Java Community Process

JSR - JAVATM SPECIFICATION REQUEST 26This document describes a standard mapping between the Enterprise JavaBeansTM architecture and the Unified Modeling Language. The mapping lets software designers use UML to describe software systems based on the EJB architecture.

Supported by tools from Summer 2001

26

ICT

Virtual metamodel (VMM)

ICT

27

ICT

ICT

28

ICT

ICT

29

ICT

Physical Model

ICT

Example

30

ICT

ICT

31

ICT

ICT

32

ICT

ICT

33

ICT

ICT

Service-Oriented Architecture

34

ICT

What is a Service-Oriented Architecture (SOA)?

“A set of components which can be invoked, and whose interface descriptions can be published, discovered and invoked over a network.” (W3C)

[http://www.w3.org/]

“The policies, practices, frameworks that enable application functionality to be provided and consumed as sets of services published at a granularity relevant to the service consumer. Services can be invoked, published and discovered, and are abstracted away from the implementation using a single, standards-based form of interface.” (CBDI)

[http://www.cbdiforum.com/index.php3]

ICT

SOA Characteristics

Well-defined interfacesServices usually represent a business function or domain.

Business services (business functionality)Infrastructure services (“middleware services”)

Modular designCompositions and granularity

Services are loosely coupledDynamic discovery and binding

Services are standardized (“platform independent”)Using Internet/Web protocols and standards as the common “glue”provide “syntactical interoperability”

35

ICT

Service-Orientation

Any service-oriented environment is expected to support several basic activities:1. Service creation 2. Service description 3. Service publishing to Intranet or Internet repositories for potential

users to locate4. Service discovery by potential users5. Service invocation, binding6. Service unpublishing in case it is no longer available or needed,

or in case it has to be updated to satisfy new requirements.

ICT

Service Model

Invoke/Bind

Service Provider

Service Broker Service Requester

Publish, Unpublish, Update

Discover

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 finds the required services via a service broker and binds to services via the service provider. Service broker: provides a searchable repository of service descriptions whereservice 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, Integration).

36

ICT

Benefits of SOA

The service concept applies equally well to the business as it does to software applications.Service orientation offers a level of flexibility far exceeding that of Component Based Development (CBD).

A component is built or bought once and integrated into an organisation’s application architecture.A service is invoked dynamically when required, allowing providers to continuously improve their service and users to select the best available service at any one time.

Services reduce complexity by encapsulationServices provide the ‘units of business’ that represent value propositions within a value chain or within business processesServices promote interoperability by minimizing the requirements for shared understandingServices enable interoperability of legacy applications

ICT

Web Services

37

ICT

What is a Web service?

“Applications identified by a URI, whose interfaces and bindings are capable of being defined, described and discovered as XML artefacts. A Web service supports direct interactions with other software agents using XML-based messages exchanged via Internet-based protocols.” (W3C)

[http://www.w3.org/]

“Self contained, modular business applications that have open, Internet-oriented, standards-based interfaces.”(UDDI Consortium)

[http://www.uddi.org/]

ICT

Web services

Web services are an accurate instantiation of the service-oriented model.They adhere to the set of roles and operations specified by the service oriented model.They have also managed to establish a standardized protocol stack.

38

ICT

Overview of the Web service stack

SOAP, WS−Security, WS−ReliableMessaging, WS−Routing

WSDL, WS−PolicyebXML CPP/CPA

OASIS BTP

ebXML Messaging Service

Composition/Choreography Transactions

Description Advertisement/Discovery

WS−Coordination/TransactionBPEL4WS, WSCIebXML BPSS

UDDI, WS−InspectionebXML Registry

Unicode, XML, XML Schema

Format and Encoding

HTTP, HTTPS, SMTP

Transport

Messaging

ICT

Web Service Description Language (WSDL)

XML-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

39

ICT

WSD

L M

etam

odel

(1/2

)WSDL 1.1 Metamodel based onhttp://www.w3.org/TR/wsdl

Port+ Name

Service+ Name

Binding+ Name

Port Type+ Name

Operation+ Name

Message+ Name

Part+ Name+ Type+ Element

Include+ Locat ion

Element+ Name+ BaseType+ MinOccurs+ MaxOccurs

Import+ NameSpace+ Location

Definition+ Name+ TargetNameSpace

Types Schema+ TargetNameSpace

WSDL Document

WSDL Component

0..10..1

ICT

WSD

L M

etam

odel

(2/2

)

W SDL 1.1 M etamodel based onhttp://www.w3.org/TR/wsdl

WSDL DocumentW SDL Com ponent

0..10..1

Port+ Name

Operat ion+ Name

Service+ Name

1..*1..*

Binding+ Name

1

1

1

1

Port Type+ Name

11 11

Message+ Name

1..*

0..1

1..*

+input

0..1 0..1+output

0..10..1+fault 0..1

Import+ NameSpace+ Location

Part+ Name+ Type+ Element

0.. *0.. *

Include+ Locat ion

Elem ent+ Name+ BaseType+ MinOccurs+ MaxOcc urs

Definition+ Name+ TargetNameSpace0..*0..*

0..*0..* 0..*0..*

0..*0..*

0..*0..*

Schema+ TargetNameS pace

Types

0..10..1

40

ICT

Simple Object Access Protocol (SOAP)

XML-based protocol for structured message exchanges.It relies on existing transport protocols such as HTTP and MQSeries.A SOAP message contains two parts: the header and the body.

The header includes information such as intended purpose (e.g., service invocation, invocation results), sender's credentials, response type, and so on.The body contains an XML representation of a service invocation request (i.e., name of operation to be invoked, values of input parameters) or response (i.e., results of service invocation).

SOAP implementations exist for several programming languages including Java and C.

ICT

XML - a Metameta Language

Metameta/How to define schema

Meta/Schema

Instances/Documents

XML SGML

MathML XSL SMIL OFX HTML

XSL Doc HTML DocXML Doc

41

ICT

XMLDocument

XSLTTo transform

from XML doc.to XML doc orto add style,

such as html/svg etc

Web ServicesInternet accesibleservices described

by WSDL, WSFL etc

XML ToolsProvide

automatic validationof XML documents

XML Queryto query sets ofXML documents

in an SQL-like manner

XML ParsersStandardised

language neutralAPIs (DOM, SAX,XML Data Binding)

are defined andimplemented in variousprogramming languages

XMLSchema /

DTDValidated by

XLinkto createcomplex

links

ICT

Universal Description Discovery and Integration (UDDI)

Specification of an XML-based registry for Web services.Defines an interface for advertising and discovering Web services.The UDDI information model identifies three types of information

white pages, yellow pages, and green pages White pages contain general information such as business name (i.e, service provider's name) and contact information (e.g., provider's phone numbers).Yellow pages contain meta-data that can used to effectively locate businesses and services based on classification schemes.Green pages contain service access information including servicedescriptions and binding templates.

A binding template represents a service end point (i.e, a service access interface). It refers to an entity called the tModel.

42

ICT

Business Process Execution Language for Web Services (BPEL4WS)

BPEL4WS – 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.A partner link type models this relationship between two services with their role within the relationship and their port type.Partner links specify the servicesthat a business process interactswith and is introduced as a WSDLextension element.

Link Name

PortType PortType

Role 1 Role 2

ICT

Security

Authentication – Who is it?Authorisation – What can they do?Integrity – Ensure that information is intact.Signature – Create and verify electronic signaturesConfidentiality – Make content unreadable by unauthorised parties.Privacy – Limit access and use of individually identifiable informationDigital Rights Management – Limit use and sharing of content according to license agreements.

43

ICT

WS-Security (by Microsoft/IBM)WS-License

How to define a set of commonly used license types and to specify how they can be included within the WS-Security <credentials> tag

WS-Policy Specify security requirements, capabilities, constraints and policies on Web Services intermediaries and endpoints

WS-Trust Define security trust model allowing interoperation across security trust domains

WS-Privacy Define a model for web service clients and services to state privacy preferences and practices The second phase is intended to include those specifications for meeting more advanced requirements, specifically:

WS-SecureConversationHow to dynamically establish trust across trust domains using key exchange

WS-Federation How to manage identities and other information across heterogeneous federated systems

WS-Authorisation How to manage authorisation data and policies in a Web Services environment.

ICT

Web services and the semantic Web

XML

XOL SHOE OML RDF

RDF Schema

DAML - OIL

DARPA DAML OIL

OWL LiteOWL DLOWL Full

RDF(S)

DAML-S 0.9

OWL-S 1.0

44

ICT

Resource Description Framework (RDF)

Framework that enables describing and interchanging metadata with a few simple constructors.The most important feature of RDF is simplicity, so that provides a very well understood metadata structure for information modeling, based on three assumptions:

Resource: Anything that can have an URI such as a web site or a Web Service.Property: A property of the thing that the statement describes.Statement: A link between a resource and its property.

Practically each statement is composed of three terms:Subject: An URI that indicates a resource.Predicate: The property of the subject.Object: The value of the property.

ICT

RDF example

author

Name of the authorhttp://thispaper

Subject(resource) Predicate

(property)Object(value)

<rdf:Description rdf:about=“http://thispaper”><s:Author>name of the author</Author>

</rdf:Description>

45

ICT

Web Ontology Language for Web Services (OWL-S)

OWL-S is a W3C recommendation that provides a complete framework

based on the RDF syntax and the OWL ontology model fordescribing Web Services in terms of what they can do andhow they can work

OWL-S was born for solving challenges related to Web Services such as

semantic Web Services discoverydynamic Web Services composition andWeb Services execution monitoring.

ICT

OWL-S model of serviceResource

Web Service

provides

ServiceProfile

ServiceModel

ServiceGroundingsupports

DescribedBy

presents

The ServiceProfile has the similar functions of a registry, such as UDDI. It describes organizations that present the service, provides a list of the I/O parameters, preconditions and effects used by the service and describes additional information such as the quality and the accuracy.The ServiceModel provides the fundamental information needed for the composition and interoperation of services. OWL-S allows three different kinds of processes: Atomic, Simple and Composite.The ServiceGrounding specifies explicitly the input and output links between the atomic processes of the service, showing how the communications between these processes are to be realized as messages. However, the real implementation of the Service Grounding is a set of elements which links each atomic process to the corresponding WSDL file.