Upload
lydien
View
214
Download
0
Embed Size (px)
Citation preview
1
B2Bi ja SOA
Kehittämismenetelmät ja arkkitehtuurit liiketoiminnassa (TJT SE54) &
Tietojärjestelmien integrointi TJT ST21Kevät 2006
Ville Seppänen <[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
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
3
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.”
4
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
5
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
6
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
7
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
8
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
9
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
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
SOA
and
data integration
Chong & Kulkarni, 2006
Application integration
11
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
12
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
13
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)
14
SOA and application integration
• 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
SOA and application integration
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
• 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
16
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
Teknologiapyramidi
17
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
18
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ä)
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
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ä)
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”>
<soap:body encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”
namespace=“purchaseOrderService” use=“encoded”/>
</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
WSDL-esimerkki<operation name=“postPurchaseOrders”>
<soap:operation soapAction=“PurchaseOrderService/postPurchaseOrders” style=“rpc”/>
<input name=“postPurchaseOrders”>
<soap:body encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”
namespace=“purchaseOrderService” use=“encoded”/>
</input>
<output name=“postPurchaseOrdersResult”>
<soap:body encodingStyle=“http://schemas.xmlsoap.org/soap/encoding/”
namespace=“purchaseOrderService” use=“encoded”/>
</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
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
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)
SOAP, toiminta synkronisessa kommunikoinnissa
22
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
<?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
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>
<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
Mutkikkaat tietotyypit<SOAP-ENV:Envelope
<!-- cut -->
xmlns:xsd1="http://www.xmlbus.com/PurchaseOrderService-xsd”
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/”
<!-- cut -->
<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>
<!-- ... -->
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
SOAP with attachmentsm
ultip
art
MIM
E e
nve
lop
e SO
AP
envelo
pe
encoded
bin
ary
data
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
UDDI
UDDI
UDDI UDDI
UDDI
Business
Register data
Business
Update data
Regular data replication
Business
Search data
SOAP
SOAP
SOAP
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
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
fromKeytoKeykeyedReference
fromKeytoKeykeyedReference
businessKey...
fromKeytoKeykeyedReference
fromKeytoKeykeyedReference
businessKeyserviceKeynamedescriptionbindingTemplatescategoryBag
fromKeytoKeykeyedReference
fromKeytoKeykeyedReference
bindingKeyserviceKeydescriptionaccessPoint(or) hostringRedirectortModelInstanceDetails
fromKeytoKeykeyedReference
fromKeytoKeykeyedReference
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
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
UDDI
Document
repositoryTransformer/
Converter
Service
repository
Process
flow
Integration hub
Newcomer 2002
29
Business Process Execution
Language for Web Services
BPEL4WS
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
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
31
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/
32
BPEL4WS-prosessikulkuPeltz 2003
BPEL4WS-prosessikulkuPeltz 2003
33
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
34
BPEL4WS case
<parners>
<partner name=“Buyer”
serviceLinkType=“tns:requestQuoteLinkType”
myRole=“Purchaser” partnerRole=“Provider”/>
<partner name=“Supplier1”
serviceLinkType=“tns:requestQuoteLinkType”
myRole=“Provider” partnerRole=“Purchaser”/>
<!--Set up the other suppliers used in this process-->
</partners>
CapeClear for Eclipse
35
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
<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
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
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
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”/>
<!--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ä)
<faultHandlers>
<catch faultName=“cantFulfillRequest”>
<invoke partner=“Buyer”
operation=“sendError”
inputContainer=“Fault”/>
</catch>
</faultHandlers>