B2Bi ja SOA - cs.jyu.fi · B2Bi ja SOA ... • Standards based communication Data format...

16.3.2006rissepp@cc.jyu.fi

B2Bi ja SOA

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

Tietojärjestelmien integrointi TJT ST21Kevät 2006

Ville Seppänen <rissepp@cc.jyu.fi>

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

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

Levels of integration

Data integration

Application integration

Process integration

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

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

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)

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

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/

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

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

Common SOA model and roles

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

Data integration

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)

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

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

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

– 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

data integration

Chong & Kulkarni, 2006

Application integration

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

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

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

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

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

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)

• 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

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.

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

Web service -tekniikoista

WSDL, SOAP ja UDDI

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

client(proxy stub)

Soapserver

WSDL(pointer)

request

+ params

marshaling

+ encoding

transformation/

encoding

response

decoding

decoding/

tranformation

SERVICE

Teknologiapyramidi

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 [...]

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

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

</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ä)

WSDL-esimerkki<complexType name=“Item”>

</all>

</complexType>

</restriction>

</complexContent>

</complexType>

</all>

</complexType>

WSDL-esimerkki<complexType name=“ArrayOfPurchaseOrder”>

</restriction>

</conplexContent>

</complexType>

</schema>

</types>

</message>

</message>

</message>

</message>

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

komplesityyppejä)

WSDL<portType name=“purchaseOrderPortType”>

</operation>

</operation>

</portType>

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

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

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

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

</input>

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

WSDL-esimerkki<operation name=“postPurchaseOrders”>

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

</input>

</output>

</operation>

</binding>

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

</port>

</service>

</definitions>Palvelun fyysinen sijainti

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

• 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)

SOAP, toiminta synkronisessa kommunikoinnissa

Dokumenttipohjainen-/asynkroninen kommunikointi

• Event-driven design

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

kuljetusinfran huolehtivan viestien perillemenosta)

Purchase

OrderReceive

Web servicesinterface

Invoice

Process flow

<?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">

</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">

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

SOAP-viestin rakenne

0 - n header entries: SOAP can be extended to

include additional features, such as

security, transactions, and other QoS

attributes associated with the message

<body>

message payload

soap faults<fault>

0 - n header entries: SOAP can be extended to

include additional features, such as

security, transactions, and other QoS

attributes associated with the message

<body>

message payload

soap faults<fault>

<SOAP-ENV:Body>

<m:GetOrderStatus

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

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

</t:Transaction>

</SOAP-ENV:Header>

<SOAP-ENV:Fault>

<faultcode>Client</faultcode>

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

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

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

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

</item>

</Items>

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

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

</Address>

</order>

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

SOAP with attachmentsm

envelo

encoded

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

UDDI UDDI

Business

Register data

Business

Update data

Regular data replication

Business

Search data

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.

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

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.

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

Internal integration architecture

Communications

Document

repositoryTransformer/

Converter

Service

repository

Process

Integration hub

Newcomer 2002

Business Process Execution

Language for Web Services

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

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

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

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ä

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/

BPEL4WS-prosessikulkuPeltz 2003

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

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

BPEL4WS case

<partner name=“Buyer”

serviceLinkType=“tns:requestQuoteLinkType”

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

<partner name=“Supplier1”

serviceLinkType=“tns:requestQuoteLinkType”

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

</partners>

CapeClear for Eclipse

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

BPEL4WS case

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>

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)

<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

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

BPEL4WS case<sequence>

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

operation=“request” container=“request”

createInstance=“yes”/>

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

operation=“request_quote” inputContainer=“part_request”

outputContainer=“part_quote”/>

<!--invoke other suppliers as part of the process,

done in parallel-->

</flow>

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

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

</sequence>

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ä)

<invoke partner=“Buyer”

operation=“sendError”

inputContainer=“Fault”/>

</catch>

</faultHandlers>

Eclipse + CapeClear – esimerkkejä ohjausrakenteista

B2Bi ja SOA - cs.jyu.fi · B2Bi ja SOA ... • Standards based communication Data format...

Documents

SOA introduction

Webinar Conceptos SOA & Oracle SOA Suite

STATEMENT OF APPLIAILITY (SoA) - reg.upm.edu.myreg.upm.edu.my/eISO/isms/20150528150835.OPR-UDC-SOA_06.pdf · Dokumen penyataan pemakaian Statement of Applicability (SoA) menggariskan

Lean SOA Abspecken senkt das Infarktrisiko › vortrag › lean-soa › lean-soa-vortrag.pdf · Lean SOA - Abspecken senkt das Infarktrisiko SOA Manifest Geschäftswert über technische

Aalborg Universitet NI2S3- D1.1 NEC/SOA state of the art

Business benefits of soa

Productos Soa

SOA-based Maintenance Analysis of BIT System (Built-in-Test)

Experimental data on SOA formation from mixtures Of … · 2017-02-26 · SOA formation from mixtures of anthropogenic and biogenic organic compounds 61 The oxidation processes of

Navodila za pisanje diplomskih nalog UM FERI · 2017-11-28 · Primerjava SOA zrelostnih modelov III A COMPARISON OF SOA MATURITY MODELS Key words: service oriented architecture,

Ferramentas SOA

Informativa soa

Implementation of Service-Oriented Architecture Licensing ... · Index Terms—BPMS, SOA, BPM, Web Service, BPMN 2.0, Oracle SOA-BPM. I. INTRODUCTION Implementation of licensing services

Introduccion SOA

1.0 PENGENALAN SoA) penyataan pemakaian Statement of Applicability (SoA) menggariskan control objectives dan controls di Annex A dalam Standard MS ISO/IE 27001:2013 selaras dengan

Cub Scouts of Armavir - SoA

CertificaciónInternacionalde la Society of Actuaries (SoA) · La Society of Actuaries (SoA) es una organización de actuarios fundada en 1949, la cual persigue tres metas fundamentales:

Presentacion SOA

Oracle SOA Suite 적용사례 - dbguide.net · 3 SOA-Based Integration Modern, Composite SOA Applications SOA-Enabling the Mainframe “Only 5 days to completely modify EAI project

Arquitectura SOA