IS402-P09

7/25/2019 IS402-P09

1/19

PREDMET

IS402 Razvoj sistema za e-poslovanje

Predavanje broj 9

IS402-P09

Servisno-orijentisana arhitektura

Nedelja as Tematskajedin ica

PredavanjaLekcija ili aktivnost

Rezultat znanja ili vetinekoje student treba da dobije

9

1Razvoj sistemaza

e-poslovanje

Komponentni razvoj softveraza e-poslovanje

Web servisi Sticanje znanja neophodnog zaprojektovanje veb servisa

2 SOAP, WSDL i UDDI

Copyright 2012 UNIVERZITET METROPOLITAN, Beograd. Sva prava zadrana. Bez prethodne pismene dozvole od

strane Univerziteta METROPOLITAN zabranjena je reprodukcija, transfer, distribucija ili memorisanje nekog dela ili itavihsadraja ovog dokumenta., kopiranjem, snimanjem, elektronskim putem, skeniranjem ili na bilo koji drugi nain.

Copyright 2012 BELGRADE METROPOLITAN UNIVERSITY. All rights reserved. No part of this publication may bereproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying,recording, scanning or otherwise, without the prior written permission of Belgrade Metropolitan University.

Februar, 2012.

7/25/2019 IS402-P09

2/19

IS402 Razvoj sistema za e-poslovanjePredavanje br. 9

Naziv predavanja: SERVISNO-ORIJENTISANA ARHITEKTURA

2/19

SADRAJ

Uvod ........................................................................................................................................................ 3

ta je SOA? ......................................................................................................................................... 3

SOA i BPM ........................................................................................................................................... 5

SOA i servisi ........................................................................................................................................ 6

Osnovni SOA koncepti ............................................................................................................................ 7

Servisi .................................................................................................................................................. 7

Web servisi .......................................................................................................................................... 7

SOAP............................................................................................................................................... 9

UDDI (Universal Description, Discovery and Integration).............................................................. 12

Paterni razmene poruka (Message Exchange Pattern, MEP)....................................................... 13

WSDL (Web Service Description Language)................................................................................. 14

Uvod u drugu generaciju tehnologija Web servisa (WS-*) ................................................................ 17

Kompozicija Web servisa ................................................................................................................... 18

Orkestracija .................................................................................................................................... 18

Koreografija .................................................................................................................................... 18

WS-BPEL ........................................................................................................................................... 19

7/25/2019 IS402-P09

3/19



3/19

Predavanje br. 9

Servisno-orijentisana arhitektura (SOA)

Uvod

ta je SOA?Termin servisno orijentisan postoji ve due vreme i korien je u razliitim kontekstima i u razliitesvrhe. Jedna konstanta koja se pominje u svim tim kontekstima je da on predstavlja jedinstven pristupza razbijanje problema. Ovo znai da se logika koja je potrebna da se rei neki vei problem moebolje konstruisati, izvriti i da se njome moe lake upravljati ako se ona razloi na skupove manjihpovezanih delova. Svaki od ovih delova se odnosi na jedan, specifian, deo problema.

Servisno orijentisana arhitektura (Service Oriented Architecture (SOA)) opisuje koncepte, arhitekturu, iprocesni okvir, da bi obezbedila jeftin razvoj, integraciju i odravanje informacionih sistema krozsmanjenje kompleksnosti i stimulaciju integracije i njihovog ponovnog korienja.

Moemo rei da je SOA (Servisno orijentisana arhitektura) skup servisa ili grupa komponenti kojeizvode poslovne procese kao to je, na primer, verifikacija kredita, konverzija valuta ili proveraraspoloivosti robe. Prilikom izgradnje aplikacija SOA primenjuje koncept arhitekture kombinujui

labavo povezane i interoperabilne servise. Budui da su labavo povezane, aplikacije ne treba darazumeju tehnike detalje servisa kojeg pozivaju. Rezultat je taj da SOA omoguava nezavisnost odpojedinih platformi i nije vezana za odreenu tehnologiju.

SOA ne predstavlja radikalno novu arhitekturu, ve vie evoluciju poznatih distribuiranih arhitektura iintegracionih metoda. SOA poboljava i proiruje fleksibilnost ranijih integracionih metoda (EAI Enterprise Application Integration) i distribuiranih arhitektura, i fokusira se na ponovno korienjepostojeih aplikacija i sistema, efikasnu interoperabilnost i integraciju aplikacija, kao i kompozicijuposlovnih procesa preko servisa obezbeenih aplikacijama. Vana osobina SOA je sposobnost daprimeni promene, koje e nastati u budunosti, na relativno jednostavan i lak nain.

SOA predstavlja vie od skupa tehnologija. SOA nije direktno povezana sa bilo kojom tehnologijom,mada se esto implementira korienjem Web servisa. Web servisi predstavljaju najpodesnijutehnologiju za realizaciju SOA. Grafiki prikaz tehnologija koje obezbeuju realizaciju SOA koncepata

prikazan je naSlika 1.

7/25/2019 IS402-P09

4/19



4/19

a

UDDI

BPEL

Various programming

language (Java, C#, C++, etc)

WSDL

SOAP

ESB

WS-Security

WSCoordination,

WSAtomic

Transact.,

WSBusinessActivita

WS-ReliableMessaging

WS-Addressin

g

WS-Inspection

WS-Policy

WS-Eventing

ESBmanagementfe

atures

Quality of Service

Slika 1: Grafiki prikaz tehnologija koje obezbeuju realizaciju SOA koncepata

Kao to je prikazano naSlika 2,najvaniji SOA koncepti su:

- servisi - Servisi obezbeuju poslovnu funkcionalnost, kao to je na primer aplikacija zaprodaju. Servisi u SOA obezbeuju poslovnu vrednost, sakrivaju implementacione detalje iautonomni su;

- interfejsi - Korisnici servisu pristupaju preko interfejsa. Interfejs servisa definie skup javnihpotpisa operacija. Interfejs predstavlja ugovor izmeu servis provajdera i servis korisnika.Interfejs je odvojen od njegove implementacije, samoopisujui je i nezavisan od platforme.Opis interfejsa obezbeuje osnovu za implementaciju servisa od strane servis provajdera, kaoi osnovu za implementaciju servisa od strane servis korisnika. Svaki interfejs definie skupoperacija;

- poruke - Operacije su definisane kao skup poruka. Poruke specificiraju podatke koji e serazmenjivati, i opisuju ih na nain nezavisan od platforme i jezika korienjem ema. Servisirazmenjuju samo podatke, to se razlikuje od objektno-orijentisanog pristupa, gde seponaanje, odnosno implementacioni kod takoe moe razmeniti. WSDL predstavlja jezik kojise koristi za opis poruka;

- sinhrona i asinhrona komunikacija - Korisnici servisa mogu koristiti sinhroni i asinhronikomunikacioni mod da bi pozivali operacije servisa. U sinhronom modu, operacija servisavraa odgovor servis korisniku po zavretku obrade. Servis korisnik mora da eka da seoperacija zavri. U asinhronom modu, operacija servisa ne vraa odgovor servis korisniku,mada moe obezbediti informaciju da je operacija izvrena uspeno;

- slabo povezivanje - Slabo povezani servisi su servisi koji prikazuju samo neophodnezavisnosti i smanjuju sve vrste vetakih zavisnosti. Minimalna zavisnost osigurava da e u

sluaju promene jednog servisa biti potrebne minimalne promene kod drugih povezanihservisa. Posledica je unapreenje robusnosti, to ini sisteme elastinim u odnosu napromene i preporuuje ih za ponovno korienje;

- registri - Servis provajderi publikuju servise u registre, dok servis korisnici servisa pretraujuregistre da bi pronali potreban servis. Primer servis registra predstavlja UDDI;

- kvalitet servisa - Atributi kao to su sigurnost, pouzdano razmenjivanje poruka, transakcije,korelacija, adresiranje, obezbeuju kvalitet servisa, to kod Web servisa obezbeuju WS-*specifikacije;

- kompozicija servisa u poslovni proces - Verovatno najvaniji SOA koncept. Kompozicijaservisa dozvoljava nam da obezbedimo podrku za poslovne procese na fleksibilan i relativnojednostavan nain. Takoe omoguava brze promene poslovnih procesa i sa manje napora.

BPEL predstavlja jezik za kompoziciju poslovnih procesa.

7/25/2019 IS402-P09

5/19



5/19

ServiceRegistry

Business Process

(Composition of Services)

Service Implementation

Service Description

Service Protocol

Service Bus

Security

Coordination&Tra

nsactions

ReliableMess

aging

MessageCorre

lation

Introspection

PolicyEncha

nge

EventMod

el

Manageme

nt

Quality of Service

Slika 2: Grafiki prikaz najvanijih SOA koncepata

SOA i BPMBPM (Business Process Management) osposobljava poslovne analitiare da usaglase IT sisteme sastratekim poslovnim ciljevima, kreirajui dobro poznate poslovne procese preduzea, nadledajuinjihove performanse i optimizujui ih da bi bili efikasniji. Svaki poslovni proces je modeliran kao skupindividualnih zadataka obrade. Ovi zadaci su uobiajeno implementirani kao servisi u okvirupreduzea. BPM sistem obezbeuje skup alata koji dozvoljava poslovnom analitiaru da kreira modeleprocesa, koristi notacije kao to je BPMN (Business Process Modelling Notation), i obavljaautomatizaciju poslovnih procesa, ili izvrava model, pozivajui servise. Dodatno, BPM sistem moeobezbediti nadgledanje i upravljanje.

SOA obezbeuje aplikacionu platformu koja povezuje poslovne procese i operativne resurse, kao toje prikazano na Slika 3. Na nivou poslovnog procesa, SOA obezbeuje interfejse koji direktno

podravaju izvravanje poslovnih zadataka, ali definie te interfejse na nain da podri konzistentnosti mogunost ponovnog korienja. Na nivou operacionih resursa, SOA podrava postojeemogunosti kao integracione servise. Ali to ne ini takoto direktno mapira postojee aplikacije kaoservise. U stvari, SOA obezbeuje interfejse za novi servis, koji se zasniva na semantici preduzea ifunkcionalnim zahtevima, i mapira ih u postojee sisteme. Na kraju, to povezuje najvie i najnie nivoezajedno, preko kompozicije servisa da bi se kreirao aplikacioni nivo.

Slika 3: BPM i SOA

7/25/2019 IS402-P09

6/19



6/19

Zajedno, BPM i SOA obezbeuju prilino dobru kombinaciju za automatizaciju poslovanja preduzeakao i za razvoj e-buzinis aplikacija. BPM obezbeuje na visokom nivou apstrakciju za definisanjeposlovnih procesa, kao i mogunost nadgledanja i upravljanja procesima. Servisi obezbeuju funkcijekoje podravaju te procese. SOA obezbeuje mogunost kombinovanja servisa i podrku da se kreiraagilno, fleksibilno preduzee, tj. sistem e-poslovanja. BPM bez SOA je korisno za kreiranje aplikacija,ali teko proirivo. SOA bez BPM je korisna za kreiranje viestruko korienih i konzistentnih servisa,

ali bez sposobnosti da se ti servisi ukljue u agilno, konkurentno preduzee ili za kreiranje e -biznisaplikacija.

SOA i servis iServisno orijentisana arhitektura je termin koji predstavlja model u kojem se automatizovana logikarazlae na manje, jedinstvene delove. Zajedno, ovi delovi ine deo velike poslovne automatizovanelogike. Individualno, ovi delovi se mogu distribuirati. Delovi su nezavisni, ali ipak nisu skroz izolovanijedan od drugoga. Oni moraju biti u skladu sa grupom principa koji im omoguavaju da se razvijajunezavisno, a istovremeno da zadre odreenu koliinu zajednikih karakteristika i standarda. Ovidelovi logike se nazivaju servisi.

Servisi koji nude deskriptore i koji komuniciraju porukama ine osnovu servisno orijentisanearhitekture (videti sliku Slika 4). Ova arhitektura koju smo opisali do sada, deluje vrlo slino nekim

starijim distribuiranim arhitekturama koji podravaju razmenu poruka i razdvajanje interfejsa odizvravane logike (videti predavanje broj 08). Ono to je ipak razlikuje je nain na koji su ove triosnovne komponente (servisi, deskriptori i poruke) dizajnirani.

Slika 4: Dizajnerski problemi koje reava SOA

Neki od kljunih aspekata principa SOA su:

slaba veza (loose coupling) servisi odravaju vezu koja minimizuje zavisnost, i kojasamo zahteva da oni (servisi) budu svesni jadan drugog

ugovor servisa servisi se dre komunikacionog dogovora, onako kao to je opisano ujednom ili vie deskriptora (i drugim relevantnim dokumentima)

autonomija servisi imaju kontrolu nad logikom koju enkapsuliraju

apstrakcija svu logiku koja se nalazi van ugovora servisa, servisi sakrivaju odspoljanjeg sveta

ponovno korienje logika je podeljena u servise s ciljem promovisanja ponovnogkorienja

kompozitnost kolekcije servisa mogu biti sklopljene u cilju formiranja kompozitnih

servisa

7/25/2019 IS402-P09

7/19



7/19

ne uvanje prethodnog stanja (engl., statelessness) servisi minimizuju zadravanjeinformacija koje su specifine za neku aktivnost

otktrivanje servisi su dizajnirani da budu deskriptivni tako da se mogu nai i da im semoe pristupiti preko postojeih mehanizama za otkrivanje.

Imajui u vidu kako komponente koje ine osnovnu arhitekturu, tako i skup dizajnerskih principa koje

moemo koristiti da bi oblikovali i standardizovali ove komponente, neophodno je definisatiimplementacionu platformu koje omoguava da se sklope ovi delie i da se napravi servisnoorijentisana automatizovana reenja. Skup tehnologija koji ine Web servise nude takvu platformu.

Kao to smo pomenuli ranije, termin servisno orijentisan je postojao pre dolaska Web servisa. Ipak,nijedan tehnoloki napredak nije bio toliko pogodan, i uspean, u manifestovanju SOA kao to su Webservisi. Sve velike platforme danas, podravaju kreiranje servisno orijenitsanih reenja, i to tako da jeponuena podrka za SOA bazirana na korienju Web servisa.

Osnovni SOA koncepti

ServisiServisi su samoopisujue otvorene komponente koje podravaju brzu i jeftinu kompozicijudistribuiranih aplikacija. Ponuene su od organizacija koje pruaju usluge. One osiguravajuimplementaciju servisa, nabavljaju njihove opise i omoguavaju sline tehnike i poslovne podrke.Kako servisi mogu biti ponuene od raznih preduzea i komuniciraju putem Interneta, organizacijekoje se odlue za ovaj pristup razvoju sistema e-poslovanja podravaju distribuiranu infrastrukturu zainternu i spoljnu aplikacijsku integraciju i saradnju.

Opisi servisa slue za oglaavanje njihovih mogunosti i kvaliteta. Objavljivanjem takvih informacija oraspoloivim servisima pruaju se potrebna sredstva za otkrivanje, selekciju, povezivanje i kompozicijuservisa.

Opis mogunosti servisa definie konceptualnu svrhu i oekivane rezultate (koristei izraze i pojmove

koji su definisani u aplikacijskom domenu). Opis interfejsa servisa objavljuje potpis servisa (njegoveulaz/izlaz/greka parametre i tipove poruka). Oekivano ponaanje servisa tokom izvravanjaspecificirano je u opisu ponaanja. QoS definie vane funkcionalne i nefunkcionalne atribute kvalitetakao to su trokovi, performanse, sigurnosni atributi, integritet, pouzdanost, sposobnost rasta idostupnost. Klijenti servisa (krajnje organizacije ili pojedinci koji koriste odreenu uslugu) kao iorganizacije koje integriu vie usluga u novu, jedinstvenu uslunu ponudu, koriste opise usluga kakobi dosegli svoje ciljeve.

Web servisiEvolucijom informatike javila se potreba za kompleksnijom komunikacijom izmeu klijenta i servera. Iztog razloga nastaju Web servisi koje pruaju generiku, standardizovanu klijent -server paradigmu zapokretanje programa na serveru. Najraireniji nain korienja Web servisa je jednostavno pozivanje

metoda na udaljenim raunarima.Standardni Web servis treba da:

omogui opis servisa koji barem sadri WSDL (Web Service Description Language)dokument videti sekcijuWSDL (Web Service Description Language);

budu sposobni da prenesu XML dokument koristei SOAP - Simple Object AccessProtocol (preko HTTP-a) videti sekcijuSOAP.

Zajedniko svim Web uslugama je: mogu se ponaati i kao provajderi i kao potraivai usluga da budu registrovane kod agenta za otkrivanje preko kojeg mogu biti locirane.

Klijent koji pokree zahtev za Web servisom je takoe Web servis kao to je prikazano na sledeojslici (Slika 5):

7/25/2019 IS402-P09

8/19



8/19

Slika 5: Uloge Web servisa

Svaka funkcionalnost izloena preko klijentovog servisa takoe je kvalifikovana kao servis (iz kogadrugi servisi mogu crpiti informacije). Samim tim Web servis se ne moe smestiti u standardni klijent-server model, ve ostvaruju peer-to-peer sistem u kome svaki servise moe igrati ulogu klijenta iliservera.

Slika 6: Nain rada Web servisa

Slika 6 prikazuje nain rada Web servisa. Brojevi iznad ili pokraj strelica upuuju na redosled

izvravanja. Korakom broj jedan provajder servisa objavljuje opis servisa. U koraku broj 2 locira se

7/25/2019 IS402-P09

9/19



9/19

odrei servis na Web-u. Korak broj tri obino se naziva spajanje sa servisom, a omoguavae gaSOAP.

U osnovu SOA su sledee tehnologije/specifikacije:

WSDL- Web Services Description Language; opisuje interfejsa (XML) servisa (opis servisa).

UDDI- Universal Description, Discovery and Integration; protokol koji objavljuje opise Webservisa; standardni mehanizam za dinamiko otkrivanje opisa servisa

SOAP- Simple Object Access Protocol; protokol za izmenu XML poruka koristei HTTPprotokol.

Veza izmeu gore navedenih specifikacija prikazana je naSlika 7.

Slika 7: Veza tehnologija Web servisa

Veza izmeu ove tri tehnologije (SOAP, WSDL, UDDI) moe da se opie na sledei nain: aplikacijakoja predstavlja klijenta Web servisa treba da locira drugu aplikaciju ili deo poslovne logike koji senalazi negde na Web-u. Klijent pretrauje UDDI registar da bi pronaao servis, bilo po imenu,kategoriji, identifikatoru ili podranoj specifikaciji. Kada je pronae klijent uzima informaciju o lokacijiWSDL dokumenta iz UDDI registra. WSDL dokument sadri informacije o tome kako kontaktirati Webservis, i informacije o formatu za poruke, najee u XML emi. Klijent pravi SOAP poruku u skladu saXML emom koju je naao u WSDL-u i alje zahtev raunaru na kome se nalaziservis. (Web servismoe pristupati i enkapsulirati druge Web servise da bi izvrio svoju funkciju).

SOAP

Poto je sva komunikacija izmeu servisa bazirana na porukama, izabrano okruenje (engl.,framework) za razmenu poruka mora biti standardizovano tako da svi servisi, bez obzira na poreklo,koriste isti format i transportni protokol. Dodatno, unutar SOA, veliki naglasak je stavljen na dizajnaplikacije baziran na porukama (engl., message-centric) tako da je sve vea koliina poslovne i

aplikacione logike sadrana u porukama. Ovo postavlja zahtev da samo okruenje za razmenu porukabude ekstremno fleksibilno i proirivo.

7/25/2019 IS402-P09

10/19



10/19

SOAP specifikacija zadovoljava ove zahteve i ona je univerzalno prihvaena kao standardantransportni protokol za poruke procesirane od strane Web servisa. Od verzije 1.2 SOAP specifikacije,re SOAP nije vise akronim Simple Object Access Protocol (ona sada postoji kao samostalna re).

SOAP je protokol baziran na XMLu, slui za razmenu podataka u decentralizovanoj, distribuiranojsredini. SOAP se oslanja samo na XML i standardne web protokole (HTTP, FTP, SMTP). Glavnasvrha SOAP specifikacije je da definie standardan format poruke. Struktura ovog formata je prilinojednostavna, ali mogunost njegovog proirenja i prilagoavanja je ono to je pozicioniralo SOAP kaoosnovu za SOA.

Svaka SOAP poruka je spakovana u kontejner koji se naziva envelope (u njemu se nalaze svi deloviporuke videti Slika 8). Svaka poruka moze sadrzati zaglavlje (header) prostor predvien zauvanje metapodataka. U velikom broju servisno orijentisanih reenja, zaglavlje je vaan deocelokupne arhitekture, i iako je opciono retko se izostavlja. Njegova vanost se ogleda u upotrebiblokova zaglavlja (header blokova) kroz koje se moe implementitari vei broj proirenja.

Slika 8: Osnovna struktura SOAP poruke

SOAP envelop takoe sadri i SOAP telo (body) koje sadri poslovne informacije. Npr. SOAP telomoe sadrati zahtev za servisom (engl., service request) i ulazne podatke za servis koji se procesira.Telo sadri informacije specifine za aplikaciju i ono se procesira na strani krajnjeg primaoca. U tokuprocesiranja SOAP poruke, SOAP vor moe izgenerisati greku. Ako se to desi, SOAP vorvraaSOAP poruku koja sadrzi SOAP greku.

Primarna karakteristika SOAP komunikacionog okruenja je kreiranje nezavisnih (samostalnih)poruka. Ova nezavisnost je implementirana kroz korienje blokova zaglavlja. Blokovi zaglavljadopunjuju poruku sa svim informacijama koje su neophodne servisima sa kojima poruka dolazi ukontakt - informacije koje omoguavaju servisima da procesiraju i rutiraju poruku u skladu sa prateimpravilima i instrukcijama. Ovo, u stvari, znai da kroz korienje blokova zaglavlja,SOAP poruke moguda sadre dodatne informacije o isporuci i procesiranju sadraja poruke. Ovo pak oslobaa servise odpotrebe uvanja i odravanja logike koja je specifina za poruke (message-specific). I dalje, ovodoprinosi konceptima SOA, naglaavajui interoperabilnost i mogunost ponovnog korienja(praktino sva WS-* proirenja su implementirana koristei blokove zaglavlja. WS-* proirenja emopokriti u sledeim poglavljima videti sekcijuUvod u drugu generaciju tehnologija Web servisa(WS-*)).

Neke od informacija kojima blokovi zaglavlja mogu dopuniti poruke:- procesne instrukcije koje mogu izvriti servisni posrednici (intermediaries) ili krajnji primalac

7/25/2019 IS402-P09

11/19



11/19

- informacije o rutiranju

- sigurnosne mere koje poruka implementira

- informacije o pouzdanosti isporuke poruke

- informacije o upravljanju transakcijama

- informacije korelacije (tipino identifikator koji se koristi za povezivanje poruka za zahtev, saporukama za odgovor)

SOAP vorovi (nodes)

SOAP vorovi predstavljaju procesnu logiku zaduenu za slanje, primanje i obavljanje razliitihtaskova na SOAP porukama. Implementacija SOAP vora je tipino platformski specifina i esto seoznaava kao SOAP server ili SOAP oslukiva (engl., listener). Ali, bez obzira na nain na koji suimplementirani, SOAP vorovi moraju biti u skladu sa SOAP specifikacijom koju podravaju jedinotako je mogue komunikaciono okruenje nezavisno od proizvoaa.

SOAP vorove delimo po tipu, u zavisnosti od toga u kojoj formi procesiranja oni uestvuju uodreenom scenariju. Tipovi koje vezujemo za SOAP poruke su:

SOAP poiljalac (sender) SOAP vor koji alje poruku

SOAP primalac (receiver) SOAP vor koji prima poruku

SOAP posrednik SOAP vor koji prima i alje poruku, i opciono procesira poruku prenjenog slanja

inicijalni SOAP poiljalac prvi SOAP vor koji alje poruku

krajnji SOAP primalac poslednji SOAP vor koji prima poruku

Primer SOAP poruke koju alje klijent pri zahtevu za konkretnim podatkom od poiljalaca servisa datje u nastavku. Primalac eli da zna koji podatak odgovara ID-u 827635.

827635

Odgovor poiljalaca servisa na zahtev primalaca je sledea SOAP poruka:

Toptimate 3-Piece Set

827635

3-Piece luggage set. Black Polyester.

96.50

true

7/25/2019 IS402-P09

12/19



12/19

Kada se greka desi tokom procesiranja SOAP poruke, specifikacija nudi model za obradu greaka.Informacija o grekama se nalazi unutar elementa. SOAP specifikacija definie petkodova greaka:

1. VersionMismatch poruka ne odgovara SOAP verziji na voru

2. MustUnderstand ciljni vor ne razume zaglavlje u poruci koja sadrzi mustUnderstandatribut

3. DataEncodingUnknown ciljni vor ne razume enkodiranje podataka u poruci

4. Sender poruka je neispravno formirana kada ju je primio procesni vor

5. Receiver primajui vor ili krajnji primalac (receiver) ne mogu da procesiraju poruku

Za veinu kompanija SOAP je najprihvatljivije reenje. Sve to je ustvari potrebno, je unapred

dogovorena ema za XML podatke koji se razmenjuju, i SOAP server koji je sposoban da rukujedolazeim XML-om. Sa softverske strane, poiljaoci moraju da pakuju svoje podatke u XML, ali veinakompanija je to ve i uradila, pa im to predstavlja minimalan trud. Eventualno samo treba da napraveXSLT (XSL Transformations) emu da bi automatizovale taj proces.

UDDI (Universal Descript ion, Discovery and Integration)

Jedan od fundamentalnih koncepata servisno orijentisane arhitekture je mehanizam kojim bipotencijalni potraivai otkrili deskriptore Web servisa (metapodatke koji opisuju Web servise). Timetapodaci moraju biti u formi koja se lako pretrauje, i otkriva, od strane potraivaa. Potrebno jeove metapodatke skupiti, i sauvati, u neki centralni direktorijum. Takav jedan direktorijum moepostati integralni deo organizacije ili internet zajednice.

Ovo je razlog zasto je UDDI (Universal Description, Discovery and Integration1) specifikacija postala

vana. Kljuni deo UDDI specifikacije je standardizacija podataka unutar takvog direk torijuma, koji sejo naziva i registar (registry), kao i specificiranje naina za njegovu pretragu i auriranje (engl.,update). UDDI nudi standardan nain za opis poslova (engl., business), ukljuujui i njihovukategorizaciju po razliitim kriterijumima (npr. geografska lokacija, sektor industrije, itd. ), kao i nainna koji ih potencijalni klijenti mogu traiti na osnovu odreenih zahteva.

UDDI repozitorijum se mogu nuditi na jedan od tri naina:

1. javni UDDI ovo su UDDI repozitorijumi koji mogu posluiti kao resurs za internet baziraneWeb servise. Primer je UDDI poslovni registar koji podravaju velike kompanije (ponekadnazivane i operatori vorova), koje predvode IBM, Microsoft i SAP, i kojeg replicira veliki brojdrugih organizacija (UDDI podaci se repliciraju automatski izmeu instanci repozitorijuma).

2. intra enterprise UDDI preduzee ima privatni interni UDDI repozitorijum koji nudi mnogo viekontrole nad time kojim deskriptorima servisa je dozvoljeno da budu stavljeni u repozitorijum, iko sme da ih koristi

3. inter enterprise UDDI opseg su mu servisi koji su deljeni izmedju vie poslovnih partnera

Slika 9.pokazuje kako opisi servisa mogu biti objavljeni u registru servisa (service registry) gdemogu biti pronaeni od strane potencijalnih klijenata Web servisa. Universal Description,Discovery, and Integration (UDDI) projekt definie takav registar Web servisa. Sam Web servisopisan je u XML formatu zove se Web Services Description Language (WSDL). Jednom kad jeservis pronaen,i kada je uspostavljena veza zasnovana na informacijama u registru, interakcijaizmeu aplikacije i Web servisa moe da pone.

Pozivanje servisa ukljuuje slanje XML poruke servisu i primanje povratne XML poruke. Ove XMLinterakcije su definisane standardom zvanim Simple Object Access Protocol (SOAP). SOAPdefinie zaglavlje poruke koje opisuje poruku i oznaava koja operacija je pozvana. Zaglavlje je

1http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm
http://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htmhttp://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htmhttp://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htmhttp://www.oasis-open.org/committees/uddi-spec/doc/tcspecs.htm

7/25/2019 IS402-P09

13/19



13/19

omotnica koja sadri telo XML poruke u kojem se prenose parametri. SOAP podrava i pozivudaljene procedure i optu paradigmu prolaska XML dokumenta. SOAP poruke se morajuprenositi na komunikacijskom sloju, najee HyperText Transport Protocol-om (HTTP).

Slika 9: UDDI i Web servisi

Paterni razmene poruka (Message Exchange Pattern, MEP)

Pre nego krenemo sa opisivanjem WSDL-a, pomenuemo paterne razmene poruka.

Svi poslovi koji su automatizovani od strane Web servisa se mogu razlikovati po prirodi aplikacionelogike koja se izvrava, kao i po ulozi koju servis ima u tom poslu. Bez obzira na to koliko je

kompleksan posao, skoro svi poslovi zahtevaju prenos vie poruka. Izazov lei u koordinaciji ovihporuka u odreeni redosled, tako da individualne akcije koje poruke izvre, se izvre na pravi nain.MEP (Message Exchange Pattern) predstavlja skup ablona koji nudi grupu ve mapiranih sekvenciza razmenu poruka. Najei primer je patern zahtev-odgovor (engl., request-response). Zahtev-odgovor je najpopularniji MEP u upotrebi u distribuiranoj sredini, i on najee definie sinhronukomunikaciju (iako se ovaj patern moe primenjivati i asinhrono). Ovaj patern utvruje prosturazmenu, u kojoj se poruka prvo prenosi od izvora (servis potraiva) do destinacije (servis provajder).Po prijemu poruke, destinacija (servis provajder) onda odgovara porukom nazad izvoru (servispotraiva). Treba primetiti da u okviru ovog MEP-a, servisi obino zahtevaju nain da pridrue porukukoju alju kao odgovor sa odgovarajuom porukom koja je predstavljala zahtev. Ovo se moe postiikorelacijom.

Jedan od fundamentalnih zahteva za razmenu informacija Web servisima je mogunost da se sauvakontekst i stanje tokom isporuke veeg broja poruka. Poto je servisno orijentisan komunikacionookruenje slabo povezano (engl., loosely coupled), ne postoji mehanizam za povezivanje poruka kojese razmenjuju pod zajednikim kontekstom, ili kao deo zajednike aktivnosti.

MEP igraju vanu ulogu u WSDL-u (opisan u sekciji WSDL (Web Service Description Language)), jerpaterni mogu koordinisati ulazne i izlazne poruke koje su u vezi sa operacijom. Iako emo opisativerziju 2 WSDL specifikacije u narednoj sekciji, ovde emo pomenuti i koje paterne podravaprethodna verzija 1.1 WSDL specifikacije2 radi boljeg razumevanja. Verzija 1.1 podrava etiripaterna. Ovi paterni se primenjuju na operacije u okviru servisa, iz perspektive servis provajdera ilikrajnje take. Dakle podrani paterni u verziji 1.1 WSDL specifikacije su (Slika 10):

operacija zahtevodgovor (request-response) po prijemu poruke, servis mora odgovoritistandardnom porukom ili pak porukom o greci

2http://www.w3.org/TR/wsdl

7/25/2019 IS402-P09

14/19



14/19

operacija trai odgovor (solicit-response) po slanju poruke servisu potraivau, servisoekuje standardnu poruku kao odgovor, ili pak poruku o greci

operacija u jednom smeru (one-way) - servis oekuje jednu poruku i nije u obavezi daodgovori

operacija obavetavanja (notification) servis poanje poruku i ne oekuje odgovor.

Slika 10: etiri osnovna paterna

Verzija WSDL specifikacije 2.0 definie samo tri paterna (patern samo-ulaz, patern robustan samo-ulaz i patern ulaz-izlaz), ali nudi mogunost korienja i dodatnih paterna (patern ulaz-opcioni-izlaz,patern samo-izlaz, robustan-samo-izlaz, izlaz-ulaz, izlaz-opcioni-ulaz), tako da emo ovde predstavitisvih osam paterna:

patern ulaz-izlaz (in-out) analogan MEP-u zahtev-odgovor (ekvivalentan WSDL 1.1 operacijizahtev-odgovor)

patern izlaz-ulaz (out-in) je suprotan prethodnom paternu gde servis provajder inicirarazmenu slanjem zahteva (ekvivalentan WSDL 1.1 operaciji trai odgovor)

patern samo-ulaz (in-only) podrava standardan MEP poalji-i-zaboravi (ekvivalentan WSDL

1.1 operaciji u jednom smeru) patern samo-izlaz (out-only) suprotan je paternu samo-ulaz. Koristi se uglavnom za podrku

objava dogaaja (event notification. Ekvivalentan WSDL 1.1 operaciji obavetavanja)

patern robustan-samo-ulaz (robust in-only) varijacija paterna samo-ulaz koja nudi opcijuslanja poruke o greci kao rezultat greke koja nastaje u prenosu ili u procesiranju

patern robustan-samo-izlaz (robust out-only) koji kao i patern samo-izlaz, ima spoljnu(outbound) poruku koja inicira prenos. Razlika je to poruka o greci moe da se poalje kaoodgovor na prijem ovakve poruke

patern ulaz-opcioni-izlaz (in-optional-out) koji je slian paternu ulaz-izlaz sa jednimizuzetkom. Ova varijacija uvodi pravilo koje kae da je isporuka poruke koja predstavljaodgovor opciona, i samim tim servis potraiva koji je zapoeo komunikaciju ne bi trebalo daje oekuje. Ovaj patern takoe podrava generisanje poruka o greci

patern izlaz-opcioni-ulaz (out-optional-in) je suprotan paternu ulaz-opcioni-izlaz, gde jedolazna poruka opciona. Ovaj patern takoe podrava generisanje poruka o greci.

WSDL (Web Service Description Language)

WSDL nudi klju za uspostavljanje slabo povezane komunikacije izmeu servisa implementiranih kaoWeb servisi. WSDL opisuje taku kontakta za servis provajdera, esto nazivanu servisna krajnja taka(engl., service endpoint). On nudi formalnu definiciju interfejsa krajnje take (tako da potraiva kojieli da komunicira sa servis provajderom zna tano kako da sastavi poruku (npr. tip i broj parametarakoji se prosleuju servisu, tip i struktura vraenog rezultata) i takoe utvruje fiziku lokaciju (adresu)servisa. Dakle, jednom kada se web servis otkrije (preko UDDI-a) WSDL obezbeuje detalje kako sestvarno povezati, i interagovati sa tim servisom.

WSDL je jezik zasnovan na XML-u, razvijen je zajedniki od strane Microsofta i IBM-a i predstavljaW3C specifikaciju. Okruenje Web servisa uvodi integracijski sloj (Slika 11), koji utemeljuje

7/25/2019 IS402-P09

15/19



15/19

standardno, opte poznato programsko okruenje. WSDL omoguuje komunikaciju izmeu tih slojevadajui standardizovani opis krajnjih taaka.

Slika 11: Integracijski sloj

WSDL je dizajniran oko sledeih koncepta:

1. proirivost neke stvari su neophodne za opis servisa (format podataka koji se razmenjuje,nain nakoji poruke treba da se alju, njihova destinacija itd.) ali ta je sa stvarima tipa: kolikokota korienje servisa, koje su sigurnosne karakteristike, itd. WSDL reava taj problem takoto se limitira samo na bitne stvari, a za ove druge nudi mogunost proirenja (odnosno morase napraviti nova jezika sintaksa i umetnuti na pravo mesto u WSDL-u)

2. razdvajanje ta od kako i gde - prva stvar koju klijent mora da zna je ta servis radi.Onda mora da zna kako da koristi servis i gde se on nudi. To je osnovni princip WSDL-a onrazdvaja ta servis radi (izraeno u formi u WSDL-u 1.1 odnosno formi u WSDL-u 2.0), od toga kako treba interagovati sa servisom (izraeno u formi u verziji 1.1 i 2.0), kao i od toga gde se servis nudi (izraeno u formi uWSDL-u 1.1 odnosno formi u WSDL-u 2.0). Ovo razdvajanje dozvoljava da isti opista servis radi bude ponueno u razliitim formama interakcije na razliitim lokacijama(apstraktni opis servisa) odnosno imamo mogunost njegovog ponovnog korienja.

3. podrka za vie protokola - WSDL nije direktno zavisan od HTTP-a i SOAP-a. WSDLspecifikacija nema nikakva ogranienja po pitanju protokola koji mogu da se koriste za prenosparametara i rezultata. Ona nudi proirivu arhitekturu za podrku za bilo koji protokol. opisuje kako pristupiti servisu preko specifinog protokola.

4. bez redosleda servis koji WSDL opisuje se tipino sastoji od veeg broja operacija. Meutimnigde se ne specificira kojim redosledom se te operacije moraju izvravati. Taj redosled senekad naziva apstraktni proces Web Servisa. Business Process Execution Language zaWeb service (WS-BPEL) ukljuuje koncept apstraktnog procesa.

5. bez semantike - WSDL namerno opisuje ta servis radi samo na strukturnom nivou, on nezalazi u opisivanje semantike Web Servisa.

WSDL specifikacija je trenutno u verziji 2.0, i u odnosu na prethodnu verziju (WSDL 1.13) ona jeprostija, ali praktinija za opise servisa. Mala je verovatnoa da e WSDL specifikacija biti daljerazvijana (naravno greke e se ispravljati, ali se ne oekuje verzija 3.0 bar ne u skorije vreme). Izprostog razloga to je WSDL specifikacija osnova za mnoge druge specifikacije i njena promena bizahtevala menjanje i ostalih specifikacija. Ipak, verzija 2.0 je relativno nova, i proi e neko vreme pre

3http://www.w3.org/TR/wsdl

7/25/2019 IS402-P09

16/19



16/19

nego to ona zameni verziju 1.1. Svi ozbiljniji alati podravaju WSDL 1.1, i potrebno je neko vreme dabi WSDL 2.0 bio u potpunosti prihvaen od strane industrije.

U nastavku je objanjeno kako je WSDL organizovan. WSDL specifikacija definie jezik za opisivanjeapstraktne funkcionalnosti, kao i okruenje (framework) za opisivanje konkretnih detalja opisa servisa(videti slikuSlika 12).

Slika 12: Struktura WSDL dokumenta

Na apstraktnom nivou WSDL opisuje Web servis u terminima poruka koje alje i prima (poruke suopisane bez obraanja panje na to kako i gde se servis nudi) koristei neki sistem tipova najeeXML emu. Operacija ( element) povezuje patern razmene poruka (tj. MEP) sa jednom ilivie poruka. MEP identifikuje sekvencu i kardinalnost poslatih i/ili primljenih poruka. Interfejs( element) grupie zajedno operacije.

Na konkretnom nivou, element, specificira detalje transportnog formata za jedan ili vieinterfejsa. element pridruuje mrenu adresu sa elementom. I na kraju, element grupie zajedno elemente koji implementiraju zajedniki interfejs.

Preslikavanje karakteristika Web servisa u WSDL dokument je prikazano na sliciSlika 13.

7/25/2019 IS402-P09

17/19



17/19

Slika 13: Preslikavanje karakteristika Web servisa u WSDL dokument

Uvod u drugu generaciju tehnologija Web servisa (WS-*)Izraz WS-* je postao esto koriena skraenica koja se odnosi na drugu generaciju specifikacijaWeb servisa. Ovo su proirenja osnovnom okruenju Web servisa, koji ine standardi prve generacije,a koji su predstavljeni sa WSDL, SOAP i UDDI specifikacijama. Termin WS-* je postao popularanzato to veina naziva data Web servis specifikacijama druge generacije poinje prefiksom WS-*.

Glavna motivacija za proirivanje mogunosti prve geracije Web servisa je bila da se omoguiservisno orijentisanim arhitekturama da predstave (i poboljaju) iri opseg poslovnih funkcija koja suneophodna za savremena preduzea. Da bi razumeli zato su ove specifikacije stvorene, moramouzeti u obzir neke od fundamentalnih zahteva poslovne automatizacije, koji nisu bili zadovoljeni prvomgeneracijom Web servisa.

- Poslovni (engl., business) procesi

Da bi mogli da povezujemo Web servise potrebno je da imamo neki standardni renik. WebServices Business Process Execution Language (WS-BPEL) nudi renik za opis procesa kojise moe kompajlirati u skripte, koje bi izvravali posrednici koji podravaju orkestraciju. WS-

BPEL zajedno sa drugim renicima poslovnih procesa dovodi Web servise u domen poslovne (enterprise) integracije (WS-BPEL specifikacija)

- Upravljanje (engl., management) kontekstom i transakcijama

Poetni skup tehnologija Web servisa nije imao mogunost da podri strukturno odravanjekonteksta kroz aktivnost servisa. Bez aktivnog konteksta koji je svestan prethodnih stanja(engl., stateful), Web servisi deluju nezavisno i ne mogu podrati distribuirane transakcije.WS-Coordination standard nudi sistem upravljanja kontekstom, koji se primenjuje pri podrciatomskih transakcija, koristei protokol koji je opisan u WS-Transaction specifikaciji (WS-Coordination, i WS-Transaction specifikacija)

- Sigurnost

Verovatno najveu prazninu u prvoj generaciji Web servisa je predstavljao nedostatak realnih

sigurnosnih standarda. Kao posledica toga organizacije nisu ba bile voljne da izloe svojeposlovne procese na internetu. WS-Security okruenje (framework) uspostavljaju detaljan

7/25/2019 IS402-P09

18/19



18/19

sigurnosni model, sastavljen od standarda koji se meusobno nadopunjuju. On utvrujesigurnosne mere za zatitu SOAP poruka na putanji poruka, i podrava stvaranje kursevadelovanja (engl., policies). Osnovne WS-Security specifikacije su dopunjene serijom XMLsigurnosnih standarda (WS-Security specifikacija)

- Pouzdano slanje poruka

Da bi neko reenje bilo robusno, njegovo komunikaciono okruenje mora biti otporno nagreke. Unutar servisno orijentisane arhitekture, ovo zahteva sistem za garantovanu isporukuporuka, to takoe podrazumeva i nain za komuniciranje o grekama o neuspelom prenosu.WS-ReliableMessaging nudi takav sistem, zajedno sa skupom kurseva delovanja koji se moekoristiti za podrku poslovnim pravilima vezanim za isporuku (WS- ReliableMessagingspecifikacija

- Kursevi delovanja (engl., policies)

Unutar servisno orijentisane arhitekture bi bilo korisno ako bi mogli da apstrakujemo poslovnapravila i sigurnosna pravila, tako da se ona mogu primeniti na grupu servisa kao kursevidelovanja. WS-Policy okruenje se sastoji od skupa specifikacija koja omoguavaju opistakvih kurseva delovanja, kao i standardan nain za njihovo pridruivanje Web servisu (WS-Policy specifikacija

Kompozicija Web servisaU ovoj sekciji emo prvo dati kratak uvod u orkestraciju i koreografiju Web servisa, a zatim emo ukratkim crtama objasniti i WS-BPEL specifikaciju.

OrkestracijaUmesto da imamo Web servise koji se pozivaju meusobno koristei jedan ili vie paterna za razmenuporuka, moe se koristiti orkestracija za kreiranje kompleksnih paterna interakcije u poslovnojkomunikaciji, sa obradom izuzetaka, grananjem i paralelnim izvravanjem. Da bi ovo postigla,orkestracija mora da sauva kontekst i da ponudi korelacioni mehanizam za vie servisa.

Sa orkestracijom razliiti procesi se mogu povezati, bez potrebe da se ponovo razvija reenje koje je

prvobitno automatizovalo procese pojedinano. Orkestracija premouje razlike izmeu procesa,uvodei novu logiku. Dalje, upotreba orkestracije moe smanjiti kompleksnost reenja. Logika jeapstrakovana i lake se njome upravlja nego kada je ubaena unutar individualnih komponenti. Krozkorienje proirenja koja dozvoljavaju poslovnoj logici da se izrazi preko servisa, orkestracija moeprezentovati i izraziti poslovnu logiku na standardizovan, servisno baziran nain.

Kljuni aspekt pozicioniranja orkestracije unutar SOA jeste injenica da orkestracija sama postoji kaoservis. Samim tim, nadograivanjem na orkestracionu logiku standardizuje se i predstavljanje procesau okviru organizacije. Primarna industrijska specifikacija koja standardizuje orkestraciju je WS-BPEL(Web Services Business Process Execution Language).

Orkestracija nudi model gde je procesna logika centralizovana ali ipak proiriva. Kroz korienjeorkestracije servisno orijenitisana reenja postaju proiriva i prilagodljiva. Sama orkestracija tipinoutvruje zajedniku taku integracije za druge aplikacije. Ove osobine dovode do poveane

organizacione aktivnosti jer: logika koju enkapsulira orkestracija moe biti modifikovana ili proirena na centralnoj lokaciji;

centralno pozicioniranje orkestracije moe znaajno olakati spajanje poslovnih procesa.

KoreografijaOrganizacije imaju realnu potrebu za razmenom podataka. Mala je ansa da e se ba sveorganizacije dogovoriti o tome kako njihovi interni procesi treba da budu struktuirani, tako da u sluajupotrebe za meusobnom komunikaciom, sve te organizacije imaju gotova automatizovana reenja.WS-CDL (Web Service Choreography Description Language) je jedna od nekoliko specifikacija kojapokuava da organizuje razmenu informacija izmeu vie organizacija (ili vie aplikacija unutarorganizacija), sa naglaskom na javnu saradnju.

7/25/2019 IS402-P09

19/19


19/19

Vana karakteristika koreografije je da je ona namenjena javnoj razmeni poruka. Cilj je da seuspostavi neka vrsta organizovane kolaboracije izmeu servisa koji predstavljaju razliite entitete, priemu ni jedan entitet (organizacija) ne kontrolie kolaboracionu logiku.

Unutar bilo koje koreografije, Web servis zauzima jednu od nekoliko predefinisanih uloga. Ovoutvruje ono to servis radi i ono to servis moe da uradi unutar konteksta nekog poslovnog zadatka.Svaka akcija koja se mapira unutar koreografije se moe razbiti na seriju poruka koje se razmenjujuizmeu dva servisa.

Iako obe predstavljaju kompleksne paterne razmene poruka, postoji jedna razlika koja razdvajatermine orkestracija i koreografija. Orkestracija izraava poslovni proces specifian za organizaciju.Ovo znai da organizacija poseduje i kontrolie logiku koja stoji iza orkestracije, ak iako ta logikaobuhvata interakciju sa spoljnim poslovnim partnerima. Koreografija sa druge strane ne mora (i nije) uposedu jednog entiteta. Ona deluje, kao zajedniki patern za razmenu poruka koji se koristi zasaradnju servisa koji pripadaju razliitim provajderima.

WS-BPELBPEL4WS4 (Business Process Execution Language for Web services) specifikacija je nastala jula2002. godine, i ona predstavlja zajedniki trud kompanija IBM, Microsoft, i BEA. Ovaj dokument je

predloio jezik za orkestraciju koji je bio inspirisan prethodnim varijacijama, IBM-ovim WSFL (WebServices Flow Languge5), i Microsoft-ovoj XLANG specifikaciji6. Verzija 1.1. BPEL4WS specifikacije,nastala u saradnji sa kompanijama SAP i Siebel Systems, je nastala u maju 2003. Ova verzija jedobila vie panje i podrke industrije. U to vreme je BPEL4WS specifikacija bila predata OASIStehnikom komitetu, u cilju da specifikacija bude razvijena u oficijelni otvoreni stantard. Sam jezik jepreimenovan u WS-BPEL (Web Services Business Process Execution Langage).

WS-BPEL je procesno orijentisan kompozicioni jezik za Web servise, koji se oslanja na WSDL. Ondozvoljava kreiranje apstraktnih procesa koji mogu opisati poslovne protokole, kao i izvrnih procesakoji se mogu kompajlirati u izvrne skripte. WSDL dokument koji opisuje WS-BPEL proces sadriinterfejse za sam proces servis, kao i za sve ostale poslovne servise koji uestvuju u izvravanjuprocesa.

WS-BPEL se oslanja na WS-Coordination da bi ponudio okruenje za upravljanjem kontekstom.

Koordinacioni tip poslovne aktivnosti, kao to je definisan u WS-Transaction, se koristi za utvrivanjemstandardnog mehanizma za upravljanjem aktivnostima koje dugo traju.

Krajnji cilj jezika poslovnih procesa je da kompletno apstrakuju Web servise koji se nalaze u pozadini,tako da ustvari sam jezik poslovnih procesa postane API za Web servise. Takav apstraktni jeziknaravno ne bi bio pogodan za sve scenarije bazirana na Web servisima, ali bi on sigurno bio koristanza neke scenarije.

4

stara specifikacija:http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel1.pdf5http://www.ibm.com/developerworks/library/ws-ref4/

6http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htm
http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel1.pdfhttp://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel1.pdfhttp://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel1.pdfhttp://www.ibm.com/developerworks/library/ws-ref4/http://www.ibm.com/developerworks/library/ws-ref4/http://www.ibm.com/developerworks/library/ws-ref4/http://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htmhttp://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htmhttp://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htmhttp://www.gotdotnet.com/team/xml_wsspecs/xlang-c/default.htmhttp://www.ibm.com/developerworks/library/ws-ref4/http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel/ws-bpel1.pdf

Documents

IS402-P09