B2Bi ja SOA - cs.jyu.fi · B2Bi ja SOA ... • Standards based communication Data format independent of programming language, OS, network transport, ... number of inter-application

1

[email protected]

B2Bi ja SOA

Kehittämismenetelmät ja arkkitehtuurit liiketoiminnassa (TJT SE54) &

Tietojärjestelmien integrointi TJT ST21Kevät 2006

Ville Seppänen <[email protected]>

[email protected]

B2B integration

• Coordination of inter-organizational information flows

• Significant factor in gaining a competitive advantage and improved efficiency– For example, just-in-time

• A trend towards integration solutions that are flexible and easy to manage; improved business agility

• Changes in organization structures– Networked ’virtual’ organizations

– Short-termed sourcing contracts

• A number of technologies increases; a common technology subset shrinks

2

[email protected]

Teknologiavalinnat ja kustannukset 1/2 (Järvinen 2002 mukaan)

• Arkkitehtuuripäätökset tehdään yhä‘korkeammalla’ � talousasiat korostuvatpäätöksenteossa

• Avoimet, yleiset, helpot teknologiat:

– helpottavat sovellusten kehittämistä� säästyy aikaa � säästyy rahaa

– yksinkertaisemmille teknologioille löytyyenemmän osaajia �

palkkakustannukset, korvattavuus

[email protected]

Levels of integration

Data integration

Application integration

Process integration

3

[email protected]

Heterogeneity

• System level

– Hardware platforms

– Operating systems

• Syntactic level

– Programming languages

– Data representation models

• Structural level

– Data models

• Semantic level

– Terms used in interchange and their meaning

System, syntax, structure,

semantics

and Interoperability

[email protected]

Service-oriented architecture in a nutshell

• ”SOA is the architectural style that

supports loosely coupled services to

enable business flexibility in an

interoperable, technology-agnostic

manner. SOA consists of a composite set of business-aligned services that support a

flexible and dynamically re-configurable

end-to-end business processes realization

using interface-based service

descriptions.”

4

[email protected]

One service definition & some characteristics

• ”A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services.”-- Barry 2002

• A service as an intangible product that is– Heterogenious ( = seemingly similar but do not

necessarily provice the same output � difficult to evaluate the actual value, suitability for purpose, etc.)

– Substitutable ( = can be replaced with other (seemingly) similar services)

– Supplementary ( = value depends on other related services; e.g., core service + supporting or value-added services)

[email protected]

Viewpoints to loose coupling

• In a loosely coupled system elements affect each other

”suddenly (rather than continuously), occasionally (rather than constantly), negligibly (rather than significantly), indirectly (rather than directly), and eventually (rather than immediately)”-- Weich 1982 (a viewpoint of organization theory)

• ”Loose coupling in an approach to the design of distributed applications that emphasizes agility – the ability to adapt to changes. Loose coupling intentionally sacrifices interface optimization to achieve flexivle interoperability among systems that are disparate in technology, location, performance, and availability. A loosely coupled application is isolated from internal changes in others by using abstraction, indirection, and delayed binding in the interfaces between the applications”-- Kaye 2003

5

[email protected]

Real & artificial dependency

Coupling is the dependency between interacting systems.

Real dependency

- set of features or services

consumed from other systems

- always exists and cannot be

reduced

Artificial dependency

- factors that requesting party must

comply with in order to consume

features or services (e.g., platform

dependency, API dependency)

- always exists but costs can be

reduced

Loose coupling describes the configuration in

which artificial dependencyhas been reduced to the minimum.

http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/

[email protected]

Loose coupling

• Artificial dependency reduced to minimum

• Opacity of services: consumer should not

require knowledge of the implementation details of the underlying service

• Standards based communication

Data format independent

of programming language,

OS, network transport,

and data storage mechanism

Data typing and structure

abstracted from underlying

implementations of services

Map out

Map in

6

[email protected]

Tight versus loose coupling

UnexpectedAnticipatedConsequences

Broad applicabilityRe-use, efficiencySoftware objective

Via transformationBy re-codingSemantic adaptation

DelayedFixed and earlyBindings

Published schemaBy conventionSyntactic definition

IndependentDependentData types

HeterogeneousHomogeneousTechnology mix

RoutedHard codedMessage paths

DocumentRPCMessaging style

AsynchronousSynchronousInteraction

Loosely coupledTightly coupledKaye 2003, pp. 133

[email protected]

Common SOA model and roles

7

[email protected]

Teknologiavalinnat ja kustannukset 2/2 (Järvinen 2002 mukaan)

• Teknologian astettainen käyttöönotto

– “Big bang” -malli riskialtis ja kallis (käyttöönotto vaatii

toiminnan pysäyttämistä ja tuplaympäristöä)

– Web servicejen käyttö ei poissulje muita / rinnakkaisiateknologioita

• Arkkitehtuuri-investoinnit olemattomia

– kehitystyökalut, sovelluspalvelimet alkaen 0€

• vrt. esim. kaupallinen ORB

– laitteistokustannukset haluettaessa pienet

– ylläpito helppoa � pienet kustannukset

[email protected]

Data integration

8

[email protected]

SOA and data integration

”Data integration initiatives, undertaken without the foundation of a data services layer, have resultedin a further proliferation of the siloed systems that they were meant to integrate. For instance, a retailer

might have deployed an ETL tools to synchronize point-of-sale data from retail outlets into an SAP

financials application. A second instance of the tool might servce to move SAP financials information into

a DB2 data warehouse for analysis. A third instance might work on the front end of the value chain to feedproduct procurement data to an operational data store.” (Figure & quote: Chong & Kulkarni 2006 SOA Web

Services Journal)

[email protected]

SOA and data integration

• Ground-level data integration platform =

another component-based service in SOA

• SOA as a framework to tie EAI and data integration technologies

– EAI to manage transactions and processes among applications

– Data integration platform to perform atomic-level data processing beyond the scope of EAI systems

9

[email protected]

Three functional components of data integration technology (Chong &

Kulkarni, 2006)

• Universal data access – Scope of data

– Prebuilt connectivity and mapping environments as a mechanism to tap into information from a variety of sources (e.g.,

packaged and homegrown apps, mainframe systems, relational databases)

– Fetching, cleansing, and transformation; data formats and semantic definitions

[email protected]

Three functional components of data integration technology (Chong &

Kulkarni, 2006)

• Metadata repository and services – Meaning of data

– An underlying foundation to understand the lineage of

data

– A framework to store and manage datamodels, transformations, workflows, and dependencies

– A means to reconcile data semantics accross

heterogenious systems

• Data integration engine

– A host of options for moving, integrating, and

delivering data among various consumers in SOA

10

[email protected]

SOA

and

data integration

Chong & Kulkarni, 2006

[email protected]

Application integration

11

[email protected]

API-level interoperability

• Integrability requires interoperability– The ability of distributed software components to exchange

services and data with one another despite of their implementation differences (i.e., heterogeneity)

• Two ways to achieve the interoperability– Bridging

• Bi-directional custom-made mappings between client and server APIs

• Flexible; easy to alter and add new features

• For example, point-to-point adapters

– Standardization• Common standardized API

• Rigid; standardization process, proprietary expansions

• The SOA way

[email protected]

A need for standardization

• According to research by PwC & Meta Group, the avarage number of applications in use in organizations is 68

• Assume that each application is required to be able to communicate with each other, a theoretical number of inter-application mappings inside one organization would be [n(n-1)]/2 = 2278*

(*this seldom is the actual need: see, for example, Levine 2003: The Myth of the Disappearing Interfaces)

Point-to-point

12

[email protected]

A need for standardization

• However, API level interoperability is not enough

• How data is coded, how it is structured, how it is

labeled, what does it mean, for what purposes it is used, and how is it used, how is it transferred between the systems, in what format is it transferred, ...

• ASCII, EBCDIC, XML, RDBMS, OODBMS, ebXML, RosettaNet, IDL, WSDL, CORBA, DCOM, XML-RPC, TCP/IP, HTTP, BEEP, …plus everything proprietary

[email protected]

Integration strategies

• Point-to-point:

custom mappings as-

needed basis;

complex, costly,

difficult to maintain

• EAI (message bus or

middleware):

proprietary bus APIs

and application APIs

Figures 1&2: Ramanathan 2004

13

[email protected]

Some short-comings of the previous (Ramanathan, 2004)

• Require either custom or proprietary integration between each application or communication bus

• Different and proprietary data formats involved in each integration point

• Communication bus and applications are tightly coupled: all the applications need to know the inner workings of the other applications with which they communicate

• Programmatic rather than abstracted data sources: custom adapters for accessing data sources; transformation engines for reformatting data; replication for physically consolidating the data– Lack of abstraction; Multiple data formats; Custom information

integration framework (inconsistent and difficult to maintain); Tight coupling; Limited reusability

[email protected]

SOA and application integration

• SOA’s standards based communication similar to that of many communication middleware systems, such as RPC, CORBA, DCOM, EJBs,

and RMI

• However, SOA is

– Technology-agnostic; e.g., open Web services

standards are technology- and platform

independent

– Free of granularity limitations; e.g., functions for

RPC or objects for CORBA (an SOA service can be

as well a component, application, or a entire

process)

14

[email protected]


• Practically any existing functionality provided by applications can be exposed as a service

– Instead of altering the existing solution to provide a

standards based interface the functionality is wrapper

with a service interface layer

Application

functionality

w/ internal logic,

data types ... SOAP serverimplementation

Open standards

service interface

(de)marshal,(de)code/transform

Describe

Consumer

[email protected]


Ramanathan 2004

The architecture of

enterprise applications

that use service-based

integration is similar

to the architecture shown

in Figure 2, but

this system uses

standards-based

services

and includes

process/data services,

orchestration, and

composition.

15

[email protected]

• The Application Architecture. This is the business facing solution which consumes services from one or more providers and integrates them into the business processes.• The Service Architecture. This provides a bridge between the implementations and the consuming

applications, creating a logical view of sets of services which are available for use, invoked by acommon interface and management architecture.• The Component Architecture. This describes the various environments supporting theimplemented applications, the business objects and their implementations.

[email protected]

Web service -tekniikoista

WSDL, SOAP ja UDDI

16

[email protected]

Web services –teknologioillatoteutettuna

UDDI registry

Service

consumer

Software

component

or any other

functionality

publish

search

interoperate

Business name,

address, contactinformation,

Web site name,DUNS, ...

Type of business,location, products

(NAICS, UN/SPSC,ISO3166)

Technical informationabout how to

interact with aservice,

business processdefinitions, a

pointer to WSDL

Soap

client(proxy stub)

Soapserver

SOAP

SOAP

SOAP

WSDL(pointer)

request

+ params

marshaling

+ encoding

transformation/

encoding

response

decoding

decoding/

tranformation

SERVICE

[email protected]

Teknologiapyramidi

17

[email protected]

WSDL (Web Services Description Language)

• IBM, Microsoft + 25 muuta

• WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate [...]

[email protected]

WSDL:n rakenne

<service> Where is the service located?

<binding> How will the messages be transmittedon the wire? What SOAP-specific details are there?

<portType> What operations are supported?

<message> What messages will be transmitted?

<types> What data types will be transmitted?

<definitions> Root WSDL element

18

[email protected]

WSDL-esimerkki

<?xml version=“1.0” encoding=“UTF-8”?>

<definitions name=“PurchaseOrderService”

targetNamespace=“PurchaseOrderService”

xmlns=“http://schemas.xmlsoap.org/wsdl”

xmlns:SOAP-ENC=“http://schemas.xmlsoap.org/soap/encoding/”

xmlns:soap=“http://schemas.xmlsoap.org/wsdl/soap/”

xmlns:tns=“PurchaseOrderService”

xmlns:xsd=“http://www.w3.org/2001/XMLSchema”

xmlns:xsd1=“PurchaseOrderService-xsd”

xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>

<types>

<schema targetNamespace=“PurchaseOrderService-xsd”

xmlns=“http://www.w3.org/2001/XMLSchema”

xmlns:wsdl=“http://schemas.xmlsoap.org/wsdl/”>

<complexType name=“PurchaseOrder”>

<all>

<element name=“CompanyName” type=“xsd:string”/>

<element name=“Items” type=“xsd1:ArrayOfItem”/>

<element name=“Address” type=“xsd1:Address”/>

</all>

</complexType>

Määritellään käytettävät

tietotyypitPurchaseOrder-tyyppi koostuu- CompanyName (merkkijono)- Items (taulukko Item-tyyppejä,

joka määritellään seuraavalla

kalvolla)- Address (joka myös määritellään

jäljempänä)

[email protected]

WSDL-esimerkki<complexType name=“Item”>

<all>

<element name=“Price” type=“xsd:float”/>

<element name=“PartID” type=“xsd:string”/>

<element name=“Description” type=“xsd:string”/>

<element name=“Quantity” type=“xsd:int”/>

</all>

</complexType>

<complexType name=“ArrayOfItem”>

<complexContent>

<restriction base=“SOAP-ENC:Array”>

<attribute ref=“SOAP-ENC:arrayType” wsdl:arrayType=“xsd1:Item[]”/>

</restriction>

</complexContent>

</complexType>

<complexType name=“Address”>

<all>

<element name=“State” type=“xsd:string”/>

<element name=“PostalCode” type=“xsd:string”/>

<element name=“City” type=“xsd:string”/>

<element name=“Country” type=“xsd:string”/>

</all>

</complexType>

19

[email protected]

WSDL-esimerkki<complexType name=“ArrayOfPurchaseOrder”>

<complexContent>

<restriction base=“SOAP-ENC:Array”>

<attribute ref=“SOAP-ENC:arrayType” wsdl:arrayType=“xsd1:PurchaseOrder[]”/>

</restriction>

</conplexContent>

</complexType>

</schema>

</types>

<message name=“postPurchaseOrderRequest”>

<part name=“order” type=“xsd1:PurchaseOrder”/>

</message>

<message name=“postPurchaseOrderResult”>

<part name=“return” type=“xsd:float”/>

</message>

<message name=“postPurchaseOrdersRequest”>

<part name=“orders” type=“xsd1:ArrayOfPurchaseOrders”/>

</message>

<message name=“postPurchaseOrderResult”>

<part name=“return” type=“xsd:float”/>

</message>

...

Vaihdettavat viestit ja niihin liittyvättietotyypit (vakiotyyppejäkuten float tai itse määriteltyjä

komplesityyppejä)

[email protected]

WSDL<portType name=“purchaseOrderPortType”>

<operation name=“postPurchaseOrder”>

<input message=“tns:postPurchaseOrderRequest” name=“postPurchaseOrder”/>

<output message=“tns:postPurchaseOrderResult” name=“postPurchaseOrderResult”/>

</operation>

<operation name=“postPurchaseOrders”>

<input message=“tns:postPurchaseOrdersRequest” name=“postPurchaseOrders”/>

<output message=“tns:postPurchaseOrdersResult” name=“postPurchaseOrdersResult”/>

</operation>

</portType>

<binding name=“purchaseOrderBinding” type=“tns:purchaseOrderPortType”>

<soap:binding style=“rpc” transport=“http://schemas.xmlsoap.org/soap/http/”/>

<operation name=“postPurchaseOrder”>

<soap:operation soapAction=“PurchaseOrderService/postPurchaseOrder” style=“rpc”/>

<input name=“postPurchaseOrder”>

<soap:body encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”

namespace=“purchaseOrderService” use=“encoded”/>

</input>

<output name=“postPurchaseOrderResult”>



</output>

</operation>

Palvelun tarjoamat operaatiot, operaatioiden tarvitsemat viestit sekä

viestien suhteet (mikä input, mikä output; vrt. message)

Viestintätyylin (rpc/message), siirtotavan (tässä soap http:n päällä) ja koodauksen

määrittely

20

[email protected]

WSDL-esimerkki<operation name=“postPurchaseOrders”>

<soap:operation soapAction=“PurchaseOrderService/postPurchaseOrders” style=“rpc”/>

<input name=“postPurchaseOrders”>



</input>

<output name=“postPurchaseOrdersResult”>



</output>

</operation>

</binding>

<service name=“purchaseOrderService”>

<port name=“purchaseOrderPort” binding=“tns:purchaseOrderBinding”>

<soap:address location=“http://http:127.0.0.1:9000/PurchaseOrderService”/>

</port>

</service>

</definitions>Palvelun fyysinen sijainti

[email protected]

SOAP (Simple Object Access Protocol) versiosta 1.2 lähtien ei enää akronyymi

• XML-pohjainen protokolla, joka toteuttaapalvelujen välisen kommunikoinnin– Laajennettu XML-RPC:stä; IONA ja IBM mukaan

2000 → v1.1– Toteutettu kymmeniin ohjelmointikieliin

• Määrittelee– kirjekuoren (envelope) XML-dokumentin siirrolle

– lisätoiminnallisuuksia (tietoturva, transaktioidenhallinta jne.) mahdollistavien otsikoiden esittelyn

– datan sarjallistamistavan dokumenttien siirtoa jaRPC-interaktioita varten

– HTTP-sidonnan

21

[email protected]

SOAP

• Kuljetusprotokollana tavallisesti HTTP (sidontamääritelty), mutta yhtälailla BEEP, SMTP, FTP, UDP, IIOP jne. tulevat kysymykseen

• Määritelty yksisuuntaisen viestintämalli, jonka päällevoidaan rakentaa erilaisia hajautettuja sovelluksia, esim– Request / Response interaction style familiar to object- and

procedure-oriented programming (RPC)

– Asynchronous messaging familiar to message-oriented middleware (MOM) systems (document style messaging)

– Unacknowledged messages

– Broadcast messaging

– Forwarding via SOAP intermediaries (e.g., routing or cache services)

[email protected]

SOAP, toiminta synkronisessa kommunikoinnissa

22

[email protected]

Dokumenttipohjainen-/asynkroninen kommunikointi

• Event-driven design

• Documents w/ self-contained context• Message queues (sovellusten tulee voida luottaa protokollan/

kuljetusinfran huolehtivan viestien perillemenosta)

Purchase

OrderReceive

Check

Ship

Send

Web servicesinterface

Invoice

Process flow

MQ

[email protected]

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

<e:Envelope xmlns:d="http://www.w3.org/2001/XMLSchema"

xmlns:e="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:i="http://www.w3.org/2001/XMLSchema-instance">

<e:Body e:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<n0:CelsiusTOFahrenheit xmlns:n0="http://DefaultNamespace">

<temp i:type="d:float">0.0</temp>

</n0:CelsiusTOFahrenheit></e:Body>

</e:Envelope>

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

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body><ns1:CelsiusTOFahrenheitResponse

soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="http://DefaultNamespace">

<CelsiusTOFahrenheitReturn href="#id0"/>

</ns1:CelsiusTOFahrenheitResponse>

<multiRef id="id0" soapenc:root="0"

soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="xsd:float">32.0</multiRef>

</soapenv:Body>

</soapenv:Envelope>

23

[email protected]

SOAP-viestin rakenne

<envelope>

0 - n header entries: SOAP can be extended to

include additional features, such as

security, transactions, and other QoS

attributes associated with the message

<header>

<body>

message payload

soap faults<fault>

[email protected]

<envelope>

0 - n header entries: SOAP can be extended to

include additional features, such as

security, transactions, and other QoS

attributes associated with the message

<header>

<body>

message payload

soap faults<fault>

<SOAP-ENV:Body>

<m:GetOrderStatus

xmlns:m=“www.xmlbus.com/OrderEntry”>

<orderno>36</orderno>

</m:GetOrderStatus>

...

</SOP-ENV:Body>

<SOAP-ENV:Header>

<t:Transaction

xmlns:t=“www.xmlbus.com” SOAP-ENV:mustUnderstand=“1”

SOAP-ENV:actor=“http://www.trans.com/transappl/”>

82

</t:Transaction>

</SOAP-ENV:Header>

<SOAP-ENV:Fault>

<faultcode>Client</faultcode>

<faultfactor></faultfactor>

<faultstring>Tilausnumero ei ole kokonaisluku.</faultstring>

<detail>

<soapVal xsi:type=“xsd:string”>kolkytkuus</soapVal>

</detail>

</SOAP-ENV:Fault>

<?xml version=“1.0”>

<SOAP-ENV:Envelope

xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/”

xmlns:SOAP-ENC=“http://schemas.xmlsoap.org/soap/encoding/”>

...

<SOAP-ENV:Envelope>

24

[email protected]

Mutkikkaat tietotyypit<SOAP-ENV:Envelope



xmlns:xsd1="http://www.xmlbus.com/PurchaseOrderService-xsd”

xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/”



<SOAP-ENV:Body>

<ns1:postPurchaseOrder

xmlns:ns1="http://www.xmlbus.com/purchaseOrderService">

<order xsi:type="xsd1:PurchaseOrder">

<CompanyName xsi:type="xsd:string">IONA</CompanyName>

<Items xsi:type="SOAP-ENC:Array" SOAP-ENC:arrayType="xsd1:Item[1]">

<item xsi:type="xsd1:Item">

<Price xsi:type="xsd:float">129.99</Price>

<PartID xsi:type="xsd:string">1234</PartID>

<Description xsi:type="xsd:string " >SkateBoots</Description>

<Quantity xsi:type="xsd:int">40</Quantity>

</item>

</Items>

<Address xsi:type="xsd1:Address">

<Street xsi:type="xsd:string">200 West Street</State>

<Zip xsi:type="xsd:int">02451</Zip>

<City xsi:type="xsd:string">Waltham</City>

<State xsi:type="xsd:string">MA</State>

</Address>

</order>



[email protected]

SOAP with attachments

• MIME-kuoressa kuljetettavaan SOAP-

viestiin lisätyt liitteet

– mm. binääridata, kokonaiset XML-dokumentit

– mm. ebXML ja RosettaNet käyttävät SwA-kommunikointia

• Base64

25

[email protected]

SOAP with attachmentsm

ultip

art

MIM

E e

nve

lop

e SO

AP

envelo

pe

encoded

bin

ary

data

[email protected]

Universal description, discovery, and integration (UDDI)

• Industry consortium (originally Microsoft,

IBM & Ariba) established service directory

• To publish, promote and search information about businesses and their

services

• Both public and private UDDI registries

exist

26

[email protected]

UDDI

UDDI

UDDI UDDI

UDDI

Business

Register data

Business

Update data

Regular data replication

Business

Search data

SOAP

SOAP

SOAP

[email protected]

Types of information

• White pages– Business name and address, contact information,

Web site name, and Data Universal Numbering System (DUNS) or other identifying number

• Yellow pages– Type of business, location, and products, including

various categorization taxonomies for geographical location, industry type, business ID, and so on

• Green pages– Technical information about business services, such

as how to interact with them, business process definitions, etc.

27

[email protected]

The basic UDDI data model

• UDDI registration information:– businessEntity, the top-level structure, describing the business

or other entity for which information is being registred. The other structures are related via references to this structure

– businessService, the name and description of the service being published

– bindingTemplate, information about the service, including an entry-point address for acessing the service

– tModel, a fingerprint, or collection of information uniquely identifying the service specification

– publisherAssertion, a relationship structure putting into association two or more businessEntity structures according to a specific type of relationship, such as subsidiary of department of

[email protected]

The basic UDDI data model

businessKeyauthorizedNameoperatordiscoveryURLsnamedescriptioncontactsbusinessServicesidentifierBagcategoryBag

fromKeytoKeykeyedReference



businessKey...



businessKeyserviceKeynamedescriptionbindingTemplatescategoryBag



bindingKeyserviceKeydescriptionaccessPoint(or) hostringRedirectortModelInstanceDetails



tModelKeyauthorizedNameoperatornamedescriptionoverviewDocidentifierBagcategoryBag

businessEntitypublishedAssertion

businessService

bindingTemplate

tModel

businessEntity

The binding template provides information

for physically accessing a Web service or

other type of service registered with UDDI.A business may register multiple binding

templates for a given business service and

identify different access point for that service

(e.g., mailto:, http:, fax:, phone:)

A tModel is the mechanism to exchange metadata

about a Web service, such as the Web service

description, or a pointer to a WSDL file. [...] The

UDDI registry aims to be general enough to support

any type of service accessible over the Internet.

That’s why UDDI doesn’t use only WSDL.

28

[email protected]

UDDI for private use

• Inside the firewall as a directory of internal Web services, or internal integration points

• Applications can be wrapped using XML integration technologies and registered with the internal UDDI

• When using Web services technology for integrating internal applications, registering the integration points in a common registry makes it easier for other departments to come along later and discover applications ready to be integrated with

[email protected]

Internal integration architecture

Communications

UDDI

Document

repositoryTransformer/

Converter

Service

repository

Process

flow

Integration hub

Newcomer 2002

29

[email protected]

Business Process Execution

Language for Web Services

BPEL4WS

[email protected]

BPEL4WS

• Business Process Execution Language for Web Services on mm. IBM:n, Microsoftin ja BEA:ntukema ehdotus, joka määritteleeverkkopalvelujen toiminnanliiketoimintaprosessien integroinnissa– Yhdistää IBM:n Web Services Flow Languagen ja

Microsoftin XLANG-kielen

• Määritelmä koostuu XML-sanastosta, joka kuvaaprosessikulun kontrollointilogiikan

• BPEL-kuvaukset tulkitsee ja suorittaa prosessin‘omistajan’ prosessimoottori

30

[email protected]

BPEL4WS

• Prosessikuvaukset käyttävät “inside-out” -lähestymistapaa eli ne kuvaavatsuoritettavan prosessin sen yhdenosapuolen (omistajan) näkökulmasta

• Prosessit kytkeytyvät verkkopalveluihinWSDL-rajapintojen kautta– WSDL määrittelee prosessin operaatiot

– BPEL määrittelee, kuinka operaatioidensuorittaminen jaksotetaan

[email protected]

BPEL4WS

• Myös prosessit julkaistaan verkkopalveluinaniiden omien WSDL-rajapintojen kautta

– WSDL kuvaa prosessin julkiset aloitus- ja

päätepisteet (entry ja exit points)

• Prosessit käyttävät WSDL:n määrittelemiätietotyyppejä prosessiin kuuluvien kutsujensisällä

• WSDL-rajapintojen kautta prosessiin voidaanliittää myös sen tarvitsemia ulkoisia palveluja

31

[email protected]

BPEL4WS

• Määrittely erottaa perus- ja rakenteisettoiminallisuudet (basic ja structured activities)– Perustoiminnallisuuden mahdollistavat

vuorovaikutuksen prosessin osapuolten välillä(mm. receive, reply, invoke)

– Rakenteiset toiminnallisuudet määrittelevätprosessin kokonaiskulun; ts. mitäperustoiminnallisuuksia suoritetaan, miten jamissä järjestyksessä

[email protected]

BPEL4WS

• Poikkeustenhallinta- ja transaktio-

ominaisuudet rakennettu WS-Coordination

ja WS-Transaction -määritysten päälle

– http://www-106.ibm.com/developerworks/library/ws-coor/

– http://www-106.ibm.com/developerworks/webservices/libr

ary/ws-transpec/

32

[email protected]

BPEL4WS-prosessikulkuPeltz 2003

[email protected]

BPEL4WS-prosessikulkuPeltz 2003

33

[email protected]

BPEL4WS casePeltz 2003

• Prosessimääritysdokumentin aloittaa process-elementti, joka sisältää prosessin nimen sekäviittaukset käytettäviin nimiavaruuksiin

• Seuraavaksi määritellään prosessiin kuuluvatosapuolet (partners) sekä näiden roolitprosessissa– Buyer: tilauksen tekijä

– Agent: tilauksen tekijän puolesta toimivaagenttiohjelmisto

– Supplieri: joukko osien toimittajia

[email protected]

BPEL4WS case

• serviceLinkType on viite WSDL-

dokumentissa määriteltyyn palvelun

porttityyppiin

– Esimerkissä oletetaan palvelun tarjoavanasiakkaalleen operaation requestQuote

• Seuraavassa partners-määrittely agentin

näkökulmasta; ostajan toimiessa agentin

kanssa, roolit määritellään toisin

34

[email protected]

BPEL4WS case

<parners>

<partner name=“Buyer”

serviceLinkType=“tns:requestQuoteLinkType”

myRole=“Purchaser” partnerRole=“Provider”/>

<partner name=“Supplier1”

serviceLinkType=“tns:requestQuoteLinkType”

myRole=“Provider” partnerRole=“Purchaser”/>



</partners>

[email protected]

CapeClear for Eclipse

35

[email protected]

BPEL4WS case

• BPEL-kuvaus käyttää containers-elementtiäprosessissa tarvittavan informaationmäärittelyyn

• Case-tapauksessa1. Ostaja tekee prosessin käynnistävän pyynnön, joka sisältää

toivotun tuotekokonaisuuden tiedot (koostuu osista) sekähankittavan kappalemäärän

2. Agentti muodostaa toimittajille osista yksittäiset tarjouspyynnöt, jotka sisältävät osanumerot ja kappalemäärät

3. Toimittaja vastaa pyyntöön hintatiedoilla

4. Agentti kokoaa pyynnöistä tarjousehdotuksen ja palauttaa senostajalle

[email protected]

BPEL4WS case

<containers>

1 <container name=“request”

messageType=“tns:request”/>

2 <container name=“part_request”

messageType=“tns:partRequest”/>

3 <container name=“part_quote”

messageType=“tns:partQuote”/>

4 <container name=“proposal”

messageType=“tns:proposal”/>

</containers>

36

[email protected]

BPEL4WS case

• correlationSets määrittelee asynkronisessa jatilattomassa prosessissa vaihdettavien viestienidentiteetit (correlation, ts. X ja Y kommunikoivatasynkronisesti � ID:n perusteella voidaanvarmistua, että X keskustelee oikeaaidentiteettiä olevan Y:n kanssa tai päinvastoin)

<correlationSets>

<correlationSet name=“Quote”

properties=“cor:quoteID”/>

<correlationSet name=“Proposal”

properties=“cor:proposalID”/>

</correlationSets>

Lisää: http://www.computing.dcu.ie/~rbarrett/wsbpel.html#WS-BPEL+Correlation

[email protected]

BPEL4WS case

• Prosessikuvauksen keskeinen osa on osuus, joka määritteleeperustoiminnallisuuksista rakenteisentoiminnallisuuden, l. prosessikulun– sequence ilmaisee, että elementin sisällä

olevat operaatiot suoritetaanperäkkäisjärjestyksessä

– flow elementti käynnistää rinnakkaisensuorituksen

– receive, reply ja invoke edustavatperustoimintoja, jotka vastaavat prosessinosapuolten vuorovaikutusta

37

[email protected]

BPEL4WS case<sequence>

<receive name=“receive” partner=“Buyer”

operation=“request” container=“request”

createInstance=“yes”/>

<flow name=“supplier_flow”>

<invoke name=“quote_supplier1” partner=“Supplier1”

operation=“request_quote” inputContainer=“part_request”

outputContainer=“part_quote”/>



</flow>

<reply name=“reply” partner=“Buyer”

operation=“send_proposal” container=“proposal”/>

</sequence>

[email protected]

BPEL4WS case

• Prosessin poikkeustenhallinta määritelläänfaultHandlers-elementillä

– Virheet määritellään sovelluskohtaisesti

– Yleensä tarvitaan kompensoivia operaatioita (esim.

peruutetaan muut tilaukset kun yhteen prosessintoimittajaan ei saada yhteyttä)

<faultHandlers>

<catch faultName=“cantFulfillRequest”>

<invoke partner=“Buyer”

operation=“sendError”

inputContainer=“Fault”/>

</catch>

</faultHandlers>

38

[email protected]

Eclipse + CapeClear – esimerkkejä ohjausrakenteista