Primerjava pristopov k razvoju spletnih storitev z ...WCF – Windows Communication Foundation HTTP – Hypertext Transfer Protocol WS – Web Services WSDL –Web Service Description

Jure Hrastnik

PRIMERJAVA PRISTOPOV K RAZVOJU

SPLETNIH STORITEV Z OGRODJEM WCF

Diplomsko delo

Maribor, julij 2013

I

PRIMERJAVA PRISTOPOV K RAZVOJU SPLETNIH

STORITEV Z OGRODJEM WCF

Diplomsko delo

Študent: Jure Hrastnik

Študijski program: Visokošolski strokovni študijski program prve stopnje

Informatika in tehnologije komuniciranja

Smer: Razvoj informacijskih sistemov

Mentor: viš. pred. Mag. Boštjan Kežmah

Lektorica: Tina Lorenčič, prof. slovenščine

ii

iii

ZAHVALA

Zahvaljujem se mentorju, viš. pred. mag.

Boštjanju Kežmahu, za pomoč in vodenje pri

opravljanju diplomskega dela. Posebna zahvala

pa je namenjena staršem, ki so mi omogočili

študij, ter mojemu dekletu, ki mi je ves čas

študija stala ob strani.

iv

Primerjava pristopov k razvoju spletnih storitev z

ogrodjem WCF

Ključne besede: WCF, SOAP, REST, XML, varnost, zanesljivost, transakcije

UDK: 004.777(043.2)

Povzetek

V diplomskem delu smo raziskali in opisali spletne storitve, ki temeljijo na protokolu SOAP

in RESTful spletne storitve. Raziskali in primerjali smo področja zagotavljanja varnosti,

zanesljivosti in transakcij pri obeh pristopih spletnih storitev. Pri SOAP spletnih storitvah

smo raziskali in opisali WS.* protokole, za RESTful spletne storitve pa smo raziskali dobre

prakse razvoja zanesljivosti in transakcij ter za varnost raziskali in uporabili OAuth

protokol. Pridobljeno znanje smo nato uporabili pri implementaciji teh dveh različnih

pristopov k razvoju spletnih storitev z Microsoftovim ogrodjem za razvoj usmerjeno

storitveno arhitekturo. Merili smo hitrost pošiljanja sporočil pri različnem številu zahtev in

opisovali tehnično izvedbo pristopov.

v

Comparison of Web Services development

principles using WCF framework

Key words: WCF, SOAP, REST, XML, security, reliable, transaction

UDK: 004.777(043.2)

Abstract

In the Diploma sheet we have investigated and described Web services based on SOAP

protocol and RESTful web services. We studied and compared the areas of safety,

reliability and transactions in both approaches online services. In the case of SOAP web

services are studied and described the WS. * Protocols. For RESTful web services, we

have studied the development of security best practices and transactions, and to

investigate the safety and use the OAuth protocol. The acquired knowledge was then

used in the implementation of the two different approaches to the development of Web

services with Microsoft's framework for the development of service-oriented architecture.

We measured the speed of sending messages to a different number of requirements and

describe the technical implementation approaches.

vi

VSEBINA

1 UVOD ........................................................................................................................................ 1

1.1 Opredelitev področja in problema ........................................................................... 1

1.2 Cilji in omejitve diplomskega dela ........................................................................... 1

1.3 Struktura diplomskega dela .................................................................................... 1

2 STORITVENO USMERJENA ARHITEKTURA ................................................................. 3

3 SPLETNE STORITVE ............................................................................................................ 4

3.1 Arhitekturni stili ...................................................................................................... 4

3.2 Ključni gradniki ....................................................................................................... 5

4 WS.* SPECIFIKACIJE ......................................................................................................... 13

4.1 Varnost ................................................................................................................ 13

4.1 Zanesljivo sporočanje ........................................................................................... 14

4.2 Transakcije ........................................................................................................... 15

5 REST SPLETNE STORITVE .............................................................................................. 18

5.1 Viri ........................................................................................................................ 19

5.2 URI naslavljanje ................................................................................................... 19

5.3 Enotni vmesnik ..................................................................................................... 20

5.4 Predstavitev virov ................................................................................................. 21

6 WINDOWS COMMUNICATION FUNDATION ............................................................. 22

vii

6.1 Ogrodje ................................................................................................................ 22

6.1.1 Naslavljanje .................................................................................................................................... 24

6.1.2 Pogodbe ......................................................................................................................................... 26

6.1.3 Vezave ............................................................................................................................................ 27

6.1.4 Končne točke.................................................................................................................................. 29

6.2 Gostovanje ........................................................................................................... 29

7 PRIMERJAVA SOAP IN REST PRISTOPA ..................................................................... 31

7.1 Tehnologija .......................................................................................................... 31

7.2 Pasovna širina ...................................................................................................... 31

7.3 Oblika sporočila .................................................................................................... 31

7.4 Protokol ................................................................................................................ 31

7.5 Varnost................................................................................................................. 31

7.6 Transakcije ........................................................................................................... 32

7.7 Interoperabilnost .................................................................................................. 32

7.8 Opis storitev ......................................................................................................... 32

8 IMPLEMENTACIJA SOAP IN REST PRISTOPA ........................................................... 34

8.1 Implementracija WCF SOAP storitve .................................................................... 34

8.1.1 Varnost ........................................................................................................................................... 34

8.1.2 Zanesljivost .................................................................................................................................... 35

8.1.3 Transakcije ..................................................................................................................................... 36

8.2 Implementracija WCF REST storitve .................................................................... 38

8.2.1 Zanesljivost .................................................................................................................................... 39

8.2.2 Varnost ........................................................................................................................................... 40

8.2.3 Transakcije ..................................................................................................................................... 41

9 PRIMERJAVA IMPLEMENTACIJE IN MERJENJE REZULTATOV............................ 43

viii

9.1 SOAP in REST merjenje rezultatov ...................................................................... 43

9.2 Primerjava izvedbe zanesljivosti in merjenje rezultatov ........................................ 44

9.3 Primerjava izvedbe transakcij in merjenje rezultatov ............................................ 45

9.4 Primerjava zagotavljanja varnosti in merjenje rezultatov ...................................... 46

10 SKLEP .................................................................................................................................... 48

11 VIRI IN LITERATURA ....................................................................................................... 50

KAZALO SLIK

SLIKA 1 OSNOVEN XML BESEDNJAK ........................................................................................................................... 8

SLIKA 2 RAZLIKA V SLOJU MED WSDL 1.1 IN 2.0 [29] ................................................................................................ 10

SLIKA 3 HTTP METODE IN NJIHOV OPIS [12] ............................................................................................................. 20

SLIKA 4 RAZŠIRJEN MODEL WCF OGRODJA [31] ......................................................................................................... 24

SLIKA 5 PRISTOP ABC V OGRODJU WCF [27] ............................................................................................................ 29

SLIKA 6 NASTAVITEV POVEZOVANJA CERTIFIKATA S STORITVIJO ...................................................................................... 34

SLIKA 7 NASTAVITEV SPOROČILNE VARNOSTI, AVTORIZIRANE S CERTIFIKATOM ................................................................... 35

SLIKA 8 NASTAVITEV ZANESLJIVE VEZAVE IN VARNOSTI ................................................................................................. 35

SLIKA 9 VMESNIK S TRANSAKCIJSKIMI OPERACIJAMI ..................................................................................................... 36

SLIKA 10 NASTAVITEV TRANSAKCIJE STORITVAM ......................................................................................................... 37

SLIKA 11 KONFIGURACIJA TRANSAKCIJSKE KONČNE TOČKE ............................................................................................ 37

SLIKA 12 KONFIGURACIJE TRANSAKCIJE WSHTTPBINDING VEZAVI ................................................................................... 37

SLIKA 13 PRIKAZ TRANSAKCIJSKEGA SKLOPA NA ODJEMALCU ......................................................................................... 38

SLIKA 14 NASTAVITEV REST SPLETNE STORITVE V WCF OGRODJU ................................................................................. 38

SLIKA 15 KONČNA TOČKA REST SPLETNE STORITVE ..................................................................................................... 39

SLIKA 16 NASTAVITEV OBNAŠANJA KONČNE TOČKE ZA REST SPLETNE STORITVE ................................................................ 39

SLIKA 17 ZANESLJIVA REST SPLETNA STORITEV .......................................................................................................... 40

SLIKA 18 PREVERJANJE PRISTNOSTI NA STRANI REST SPLETNE STORITVE .......................................................................... 41

SLIKA 19 VELIKO VHODNO IZHODNO SPOROČILO ......................................................................................................... 43

SLIKA 20 MAJHNO VHODNO IZHODNO SPOROČILO ...................................................................................................... 43

SLIKA 21 VELIKO VHODNO, MAJHNO IZHODNO SPOROČILO ........................................................................................... 44

SLIKA 22 MAJHNO VHODNO, VELIKO IZHODNO SPOROČILO ........................................................................................... 44

ix

SLIKA 23 GRAF PRIKAZUJE ČAS ODZIVA ZANESLJIVIH STORITEV PRI POŠILJANJU PODATKOV IN RAZLIČNEM ŠTEVILU ZAHTEV. ........ 45

SLIKA 24 GRAF PRIKAZUJE ČAS ODZIVA ZANESLJIVIH STORITEV PRI PRIDOBIVANJU PODATKOV IN RAZLIČNEM ŠTEVILU ZAHTEV. .... 45

SLIKA 25 GRAF PRIKAZUJE ČAS ZA IZVEDBO TRANSAKCIJE PRI RAZLIČNEM ŠTEVILU ZAHTEV ................................................... 46

SLIKA 26 PRIKAZUJE ČAS PRI ZAGOTAVLJANJU VARNEGA PRIDOBIVANJA PODATKOV GLEDE NA RAZLIČNO ŠTEVILO ZAHTEV .......... 47

SEZNAM TABEL

TABELA 1 WSDL 2.0 IN 1.0 PRIMERJAVA IN OPIS ELEMENTOV [29] ............................................................................... 10

TABELA 2 WCF VEZAVE IN NJIHOVE LASTNOSTI [32,24] .............................................................................................. 28

TABELA 3 LASTNOSTI ATRIBUTA TRANSACTIONISOLATIONLEVEL [18] .............................................................................. 36

UPORABLJENE KRATICE

SOAP – Simple Object Access Protocol

REST – Representational state transfer

XML – Extensible Markup Language

WCF – Windows Communication Foundation

HTTP – Hypertext Transfer Protocol

WS – Web Services

WSDL –Web Service Description Language

UDDI – Universal Description Discovery and Integration

ROA – Resource Oriented Architecture

RPC – Remote Procedure Call

RSS –Really Simple Syndication

ATOM – Atom Syndication Format

JSON – Javascript Object Notation

XHTML – Extensible HyperText Markup Language

WSE – Web Services Enhancements

Primerjava pristopov k razvoju spletnih storitev z ogrodjem WCF

1

1 UVOD

1.1 Opredelitev področja in problema

V diplomskem delu bomo raziskali pristope spletnih storitev. Gre za storitveno orientirano

arhitekturo, ki temelji na pridobivanju podatkov iz različnih virov. Različne spletne storitve

bomo podrobno predstavili in jih med seboj primerjali. Primerjave bomo skušali izvesti v

takem načinu, da bomo lahko merili in prikazali dane rezultate. Rezultate bomo pridobili

pri primerjavah spletnih storitev, kot so hitrosti pridobivanja podatkov, uporaba varnosti,

dolžina sporočil, zanesljivosti in transakcij ter tehnična izvedba storitve. Rezultate bomo

predstavili s pomočjo grafov in se na podlagi teh rezultatov lažje odločali pri sami

implementaciji spletne storitve.

1.2 Cilji in omejitve diplomskega dela

Zavedamo se, da obstaja veliko načinov implementacij spletnih storitev. V naši diplomski

nalogi se bomo osredotočili na spletne storitve, zgrajene z WCF ogrodjem, kot so

SOAP s WSE protokoli,

REST spletne storitve.

Za implementacijo bomo uporabili WCF ogrodje, ki je bil zgrajen z namenom za

poenostavljeno izdelavo porazdeljenih aplikacij. Tudi če se omejimo le na ti dve

implementaciji, imamo še vedno veliko načinov primerjave različnih lastnosti ene in druge.

To področje pa je v današnjem času še kako pomembno in trenutno verjetno najboljši

način vpeljave spletnih storitev.

1.3 Struktura diplomskega dela

V drugem poglavju bomo na kratko predstavili storitveno usmerjeno arhitekturo, ki

predstavlja vodilna načela za izgradnjo spletnih storitev.

V tretjem poglavju bomo opisali klasične spletne storitve. Predstavili bomo tri arhitekturne

stile, ki se uporabljajo za spletne storitve ter podrobno opisali gradnike klasičnih spletnih

storitev.

V četrtem poglavju bomo spoznali dodatne protokole SOAP spletnih storitev, ki

omogočajo izvedbo transakcij, zanesljivo sporočanje in zagotavljanje varnosti.


2

V petem poglavju bomo spoznali REST spletne storitve. Opisali bomo arhitekturni stil v

povezavi s svetovnim spletom in predstavili pomen virov, in sicer URL naslavljanja in

enotnega vmesnika za dostop do REST spletnih storitev.

V šestem poglavju bomo spoznali osnovne lastnosti WCF ogrodja ter podrobno predstavili

principe naslavljanja, vezav in pogodb.

V sedmem poglavju bomo predstavili primerjave SOAP in REST pristopa. Osredotočili se

bomo na tehnologijo, opis storitev, interoperabilnost, varnost, obliko sporočil, transakcije

ter vrste protokolov, ki jih podpirata oba pristopa.

V osmem poglavju bomo na WCF ogrodju implementirali in opisali pristope k izvedbi

transakcij, zanesljivosti in varnosti za oba pristopa spletnih storitev.

V devetem poglavju bomo izmerili implementirane pristope k spletnim storitvam.

Osredotočili se bomo na velikost sporočila, število zahtev ter tehnično zahtevnost izvedbe

implementacije. Rezultate bomo predstavili z grafikoni.


3

2 STORITVENO USMERJENA ARHITEKTURA

Storitveno usmerjena arhitektura je načrtovanje programske opreme in arhitekture, ki

temelji na načrtovalskem vzorcu strukturiranih zbirk, ločenih po modulih programske

opreme, poznano kot storitve, ki skupaj zagotavljajo popolno funkcionalnost večjega

sistema [1]. SOA je kratica za storitveno usmerjeno arhitekturo. Je arhitekturna zasnova

vzorca, s katerim so predstavljena vodilna načela določitve in ugotovitve modela. V osnovi

storitveno orientirana arhitektura navaja, da mora biti vsak sestavni del večjega sistema

predstavljen kot storitev in posledično s tem celoten sistem sestavljen iz ohlapno

sklopljenih storitev. Storitev je v tem primeru definirana kot zaključen poslovni proces.

Ohlapna sklopljenost v tem primeru pomeni, da so storitve neodvisne ena od druge tako,

da spreminjanje ene izmed njih ne sme vplivati na ostale storitve [34].

SOA ni posebna tehnologija, niti specifičen programski jezik. Je samo načrt ali pristop k

zasnovi sistema. Je arhitekturni model, ki strmi k izboljšanju učinkovitosti, odzivnosti in

produktivnosti poslovnega sistema. Ključni koncepti storitvene orientirane arhitekture so

storitve, visoka interoperabilnost in šibka sklopljenosti [34].


4

3 SPLETNE STORITVE

Uporaba tehnologije spletnih storitev spreminja internet. Povečuje se uporaba zmogljivosti

spleta za proizvajanja spletnega poslovanja. V svetovnem spletu čedalje bolj prevladuje

interakcija pri poslovanju podjetje-človek (B2C). V poslovnem spletu prevladuje

interakcija podjetje-podjetje (B2B). Pri interakciji povezovanja med podjetji pa imajo

glavno vlogo spletne storitve, ki omogočajo komunikacijo med podjetji. Temeljijo na

obstoječih standardih, kot so Hypertext Transfer Protocol (HTTP), razširjen označevalni

jezik (XML), Simple Object Access Protocol (SOAP), WebServices Description Language

(WSDL) in projektu Universal Description, Discovery, and Integration (UDDI) [1].

Spletne storitve predstavljajo tehnologijo, ki je neodvisna od programskega jezika in

okolja, v katerega se vključuje, kar pospeši povezljivost programskih aplikacij znotraj in

zunaj podjetja. Povezljivost programskih aplikacij preko spletne storitve prinaša

prilagodljivo šibko sklopljeno poslovanje sistemov. Ker se spletne storitve uporabljajo kot

ovojna tehnologija okoli obstoječih programskih aplikacij in sodobne informacijske

tehnologije, prinašajo vedno nove rešitve, kar pomeni, da se s pomočjo spletnih storitev

hitreje razvija in poenostavi preurejanje novih programskih rešitev [1].

Spletna storitev je vmesnik, ki opisuje zbirko operacij, ki so omrežno dostopne s pomočjo

standardiziranega XML-a sporočil. Spletna storitev lahko opravlja eno ali več opravil. Opis

spletne storitve je predstavljen z uporabo standardnega zapisa XML, s katerim opišemo

storitev in zagotavlja vse podrobnosti, ki so potrebne za povezovanje med storitvami. Ta

dokument, ki predstavlja opis spletne storitve, imenujemo WSDL [1].

3.1 Arhitekturni stili

Poznamo tri vrste glavnih in najpogostejših arhitekturnih stilov spletnih storitev:

Objektno-orientiran pristop

Sestavljajo ga razredi/vmesniki, podatki, operacije in temelji na abstraktnem razredu.

Opis storitev je sestavljena iz jezika WSDL (Web Service Description Language), ki

opisuje upravljanje delovanja storitve pri uporabi teh abstrakcij in pri tem zagotavlja

nevtralen mehanizem. WSDL jezik lahko uporabimo pri povezovanju z različnimi

programskimi jeziki. Operacije so definirane v vmesniku storitve, sporočila pa tvorijo

strukturo v obliki zahteva/odgovor. SOAP je standardni protokol, ki se uporablja za

izmenjavo strukturiranih podatkov [2].

Dokumentno orientiran pristop ( ROA )

REST (Representational State Tranfer) definira arhitekturni stil, ki temelji na XML, URI

(Uniform Resource Identifier) in HTTP protokolu. Ta arhitekturni stil je opisal Roy


5

Fielding v svoji doktorski disertaciji. Je opis svetovnega spleta, zaradi katerih je

svetovni splet uspel. V REST arhitekturi ne dostopamo neposredno do virov, ampak

dostopamo do njegove predstavitve vira. Vmesnik, preko katerega dostopamo do

virov, je enoten in ima sposobnost dodajanja, brisanja, prikazovanja in posodabljanja

vira [2].

Klicanje oddaljenih procedur ( RPC )

Je najbolj osnoven arhitekturni stil spletnih storitev, kjer kličemo oddaljene procedure

skozi omrežje. V kombinaciji RPC (Remote procedure call) z XML in HTTP tehnologijo

je mogoče enostavno prenašati vire med odjemalci preko omrežja. Uporablja se tam,

kjer povezujemo večje število različnih računalniških okolij, vendar ne potrebujemo

prenašati zahtevnih strukturiranih podatkov neposredno. V teh primerih je vpeljava

takšnega arhitektura stila hitra in enostavna. Komunikacija med oddajnikom in

sprejemnikom poteka na način zahteva/odgovor, saj prenos podatkov poteka sinhrono

[4].

3.2 Ključni gradniki

SOAP

Simple Object Access Protocol (SOAP) definira enostaven protokol za izmenjavo

strukturiranih podatkov preko interneta. To ogrodje je hitro razumljivo, enostavno,

popolnoma neodvisno od operacijskega sistema in programskega jezika. Njegov

namen je zagotoviti minimalno raven prenosa podatkov, nad katerim je mogoče izvesti

bolj zapletene interakcije in protokole. SOAP z vezavo na enega izmed transportnih

protokolov zagotavlja komunikacijski mehanizem za povezovanje spletnih storitev [5].

SOAP je v osnovi eden od načinov komunikacije, ki je skladen in zagotavlja, da je

sporočilo preneseno od pošiljatelja do prejemnika, pri čemer lahko vsebuje tudi

posrednike, ki to sporočilo obdelajo. Opcijsko definira pravila kodiranja podatkovnih

tipov, ampak končna točka povezovanja komuniciranja je odvisna od zasebnega

pogovora med odjemalci in ponudniki spletnih storitev. Komunikacija poteka preko

XML dokumentov, zaradi katerega je SOAP protokol popolnoma neodvisen [5].

Upoštevanje sintakse je ključnega pomena za definiranje SOAP sporočila:

o sporočila morajo biti napisana v xml obliki,

o vsebovati mora imenska prostora za SOAP ovojnico in kodiranje,

o ne sme vsebovati DTD sklicevanj.

XML dokument postane SOAP sporočilo, ko mu dodamo naslednje gradnike:


6

Envelope je korenski element SOAP sporočila. Ta element definira dokument XML

kot SOAP sporočilo. Vsebuje obvezen atribut imenskega prostora

»http://schemas.xmlsoap.org/soap/envelope/«, ki predstavlja ovojnico SOAP

sporočila. V kolikor je atribut napačno definiran, pride do napake in se sporočilo

zavrže. Ovojnico sestavljata še opcijski podelement header ter obvezni

podelement body [3].

Header je opcijski element SOAP sporočila, ki se uporablja za navedbo dodatnih

specifičnih aplikacijskih zahtev. Te zahteve so lahko preverjanje pristnosti, kot je

digitalni podpis za storitve, zaščitene z geslom. Header element pa je mogoče

uporabiti tudi za določitev številke računa za plačilo uporabljene spletne storitve.

Če definiramo ta opcijski element v sporočilu, se mora nahajati kot prvi

podelement v ovojnici sporočila. Header tako definira atribute [3]:

o Actor SOAP sporočila lahko potujejo od pošiljatelja do prejemnika, vmes pa

lahko opravljajo različne obdelave in tako nadaljujejo pot do prejemnika. Z

določitvijo atributa Actor je možno v glavi elementa nastaviti končno točko.

o MustUnderStand atribut označuje, ali je element Header obvezen ali ne.

Če je vrednost v atributu nastavljena na »1«, mora prejemnik razumeti in

obdelati element Header v skladu z določili ali vrniti napako.

o EncodingStyle atribut se uporablja za definiranje podatkovnega tipa v

dokumentu. Atribut se lahko pojavi na katerem koli elementu SOAP

sporočila in velja za vse podelemente. SOAP sporočilo nima privzeto

nastavljenega kodiranja.

Body je obvezen element SOAP sporočila. Zagotavlja mehanizem za prenos

informacij do končne točke prejemnika. Element Body torej vsebuje imenski

prostor »http://www.w3.org/2003/05/soap-envelope« ter nič ali več atributov in

podelementov tega elementa. Podelementi pa naj bi morali v atributu vsebovati

imenska področja [6].

Fault element pa se v sporočilu uporablja za prenos informacij o napakah v SOAP

sporočilu. Torej, če se napaka pojavi, se proži Fault element v telesu sporočila.

Spodaj je prikazano proženje enostavne SOAP zahteve, iz katere so razvidni nekateri

elementi, ki smo jih opisali zgoraj.

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

<s:Header>


7

<Action s:mustUnderstand="1"

xmlns="http://schemas.microsoft.com/ws/2005/05/addressing/none">http://tempu

ri.org/IStoritev/VrniNarocilo</Action>

</s:Header>

<s:Body>

<VrniNarocilo xmlns="http://tempuri.org/">

<id>123938</id>

</VrniNarocilo>

</s:Body>

</s:Envelope>

XML besednjak (ang. XML Schema)

Za poznavanje WSDL jezika je potrebno poznati XML besednjak, ki opisuje strukturo

XML dokumenta. Z besednjakom definiramo obliko XML dokumenta in jo na podlagi

strukture in vsebine izrazimo v obliki omejitev. Omejitve z uporabo besednjaka so bolj

natančne in podrobne kot tiste iz XML dokumenta. Z besednjaki je mogoče tako

definirati podatkovne tipe elementov in atributov, vsebino elementa (prazen ali vsebuje

besedilo), določiti, kateri elementi so otroki, določiti njihov vrstni red in število. Prav

tako je mogoče določati privzete in nespremenljive vrednosti. Zaradi podpore

podatkovnih tipov je lažje opisati dovoljeno vsebino, preverjati pravilnost podatkov in

omejitve nad njimi. V enem XML dokumentu lahko definiramo več besednjakov [28].

Spodaj prikazujemo osnoven besednjak, ki opisuje podatkovne tipe modela stranka in

uvoz besednjaka naročila.


8

Slika 1 Osnoven XML besednjak

WSDL 1.1 (Web service Description Language)

Je jezik, zapisan v obliki XML besednjaka in predstavlja razširljivo ogrodje za opis

vmesnikov spletnih storitev. Razvit je bil primarno s podjetja Microsoft in IBM-a,

potrjen pa s 25. podjetji za W3C standard. WSDL je srce ogrodja spletnih storitev in

zagotavlja skupek, v katerem predstavimo obliko podatkov, operacije in preslikavo

sporočil na omrežnem transportu.

WSDL jezik je zgrajen za dokumentno in postopkovno orientirano povezovanje. Je

zelo razširjen in ima veliko možnosti izvedbe interoperabilnosti in združevanja po

različni težavnosti implementacije. Torej, če si pošiljatelj in prejemnik med seboj delita

sporočila in pri tem razumeta WSDL dokument na enak način, je interoperabilnost

zagotovljena.

Operacije in sporočila so predstavljena na abstrakten način in nato povezana na

konkreten omrežni protokol in format sporočila ter s tem predstavljajo končno točko.

Med seboj podobne konkretne končne točke so združene v storitve. WSDL dokument

je mogoče razširiti, da se omogoči opis končnih točk in sporočil ne glede na format

sporočila in komunikacijski omrežni protokol [7].


9

WSDL dokument definira storitve kot zbirko končnih točk ali vrat. V WSDL dokumentu

so abstraktna definicija končnih točk in sporočil ločena od dejanskega omrežnega

prenosa ali podatkovnega povezovanja. To omogoča ponovno uporabo abstraktne

definicije sporočil, ki predstavljajo podatke, ki se prenašajo in vrste vrat, ki

predstavljajo zbirko operacij. Konkreten protokol in podatkovni format je specifičen za

določeno vrsto tipa vrat, ki predstavlja neodvisno povezavo. Vrata so definirana v

preslikavo omrežnega naslova s ponovno uporabljivo vezavo in skupino vrat, ki

predstavljajo storitev [7].

WSDL dokument 1.1 sestavljajo naslednji elementi [7]:

o Types – skupina podatkov istega podatkovnega tipa, ki pripadajo sistemu.

o Message – abstrakten pojem za definiranje podatkov, ki se prenašajo kot

sporočila.

o Operation – abstrakten pojem, ki opisuje akcije, ki jih podpira storitev.

o Port Type – abstrakten pojem za niz operacij, ki so podprte z nič ali več

končnimi točkami.

o Binding– konkreten protokol in podatkovni format za določeno vrsto vrat (port

type).

o Port – ena končna točka, definirana kot kombinacija povezave in omrežnega

naslova.

o Service – zbirka povezanih končnih točk.

WSDL 2.0

Deli spletno storitev na abstrakten in konkreten sloj. V vsaki fazi so elementi definirani

na način ponovne uporabe. Na abstraktnem sloju WSDL 2.0 opisujemo spletno

storitev v smislu sporočil: pošiljanja in sprejemanja. Sporočila so opisana neodvisno

od oblike XML besednjaka. Operacije združijo eno ali več sporočil z vzorcem

prenašanja sporočil. Vzorec za izmenjavo sporočil določi zaporedje in kardinalnost

prejetega ali poslanega sporočila. Vmesnik pa poveže operacije brez kakršne koli

odvisnosti od transportnega protokola ali podatkovnega formata [8].

Na konkretnem sloju se določeni transport in podatkovni format poveže v enega ali

več vmesnikov. Končna točka vezave je omrežni naslov s povezavo. Na koncu tako

storitev združuje končne točke, katere implementirajo skupni vmesnik [8]. Na sliki 1

sta prikazana dva sloja koncepta dokumenta WSDL 2.0 in WSDL 1.1.


10

Slika 2 Razlika v sloju med WSDL 1.1 in 2.0 [29]

Trenutna potrjena verzija WSDL dokumenta je 2.0. Verzija 1.1 ni bila potrjena s strani

W3C. WSDL 1.2 verzijo so tako spremenili v 2.0 zaradi velikih razlik med prejšnjim

WSDL 1.1 dokumentom. S sprejetjem vseh HTTP metod (ne samo GET in POST kot

v različici 1.1) trenutna verzija ponuja enostavnejšo in boljšo podporo za REST

spletne storitve [29].

V tabeli 1 so prikazane primerjave in podrobni opisi elementov dokumenta WSDL

med verzijama 2.0 in 1.1.

Tabela 1 WSDL 2.0 in 1.0 primerjava in opis elementov [29]

WSDL

1.1

WSDL

2.0

Opis

Service Service Vsebuje niz sistemskih funkcij, ki temeljijo na spletnem protokolu.

Port Endpoint Definira naslov ali povezovalno točko spletne storitve. Po navadi


11

poteka preko preproste HTTP zahteve.

Binding Binding Povezave določajo vmesnik in povezovalni stil povezovanja ter

definirajo transportni protokol. Povezave so v WSDL definirane

kot operacije.

PortType Interface Definirajo spletne storitve in operacije, ki se izvajajo ter sporočila,

ki se izvedejo v operaciji.

Operation Operation Operacije so definirane kot SOAP akcije v smislu kodiranih

sporočil. Operacije so klici metod ali funkcij, ki jih poznamo iz

tradicionalnih programskih jezikov.

Message n/a Sporočilo vsebuje informacije, ki so potrebne za izvedbo

operacije. Vsako sporočilo je sestavljeno iz enega ali več logičnih

enot. Sporočila so odstranili v dokumentu WSDL 2.0, v katerem

so v XML besednjaku definicije telesne zgradbe vhodov, izhodov

ali napak poimenovane preprosto in neposredno.

Types Types Opisuje podatke v obliki XML besednjaka.

UDDI

Standard za opisovanje, objavljanje in iskanje spletnih storitev temelji na XML. UDDI je

kratica za Universal Description, Discovery and Integration. Je odprto ogrodje in tako

neodvisen od operacijskega sistema, ki zna komunicirati s protokoli SOAP, COBRA in

Java RMI. Za opis vmesnikov spletnih storitev uporablja WSDL JEZIK. Skupaj s SOAP in

WSDL jezikom predstavljajo tri temeljne standarde spletnih storitev. Namen UDDI je

spodbuditi podjetja, da odkrijejo način in določijo smernice povezovanja preko interneta.

Sestavljata ga dva dela, in sicer prvi je register vseh spletnih storitev, ki vključuje tudi opis

storitve v WSDL jeziku, drugi pa vsebuje zbirko vrat WSDL definicij za obdelovanje in

iskanje po tem registru spletnih storitev. Kot alternativa javnega UDDI registra imajo

podjetja možnost, da si ustvarijo zasebne UDDI registre za namene povezovanja


12

določenih podjetjih med seboj. Podjetja lahko v register spletnih storitev objavijo tri tipe

različnih podatkov [9].

o Bele strani

Vsebujejo naslov, kontaktno številko in poslovno ime, se pravi osnovne kontaktne

informacije podjetja ter unikatne identifikatorje podjetja, ki omogočajo drugim

podjetjem, da najdejo spletne storitve, ki temeljijo na tej poslovni identifikaciji.

o Rumene strani

Vsebujejo več podrobnosti o podjetju, ki vključujejo opise zmogljivosti

elektronskega poslovanja, ki ga podjetje lahko ponudi pri poslovanju z drugimi

podjetji.

o Zelene strani

Ta kategorija pa vsebuje tehnične informacije o posamezni spletni storitvi. To je

tisto, kar omogoča nekomu, da se poveže s to spletno storitvijo. Vključuje vrste

različnih vmesnikov, url naslove in ostale informacije, ki so potrebne za iskanje in

zagon spletne storitve.


13

4 WS.* SPECIFIKACIJE

V tem poglavju se bomo osredotočili na SOAP in njegove specifikacije, ki delajo spletne

storitve uporabnejše. Dodatni protokoli pokrivajo obsežna področja, in sicer zagotavljanja

zaščite in varnosti do zanesljivosti. Znano je, da spletne storitve brez naštetih

funkcionalnosti skoraj ne morejo teči v poslovnem svetu, kadar gre za storitve, ki niso

namenjene širši javnosti. V nadaljevanju bomo opisali nekaj glavnih protokolov, ki

spletnim storitvam dajejo dodano vrednost uporabe.

4.1 Varnost

Ta družina specifikacij je ključnega pomena za prehod organizacije na spletne storitve.

Specifikacije podpirajo avtentifikacijo, integriteto sporočila, zaupnost in zasebnost.

Podpirajo pa tudi federativno varnost med različnimi organizacijami [13].

WS-Security

Je osnovni gradnik za zagotavljanje varnosti spletnih storitev. Večina porazdeljenih

spletnih storitev temelji na nivoju zaščite transportnega protokola, kot so HTTPS in Basic-

Auth. Takšen pristop prinaša minimalen nivo zaščite za varno komuniciranje. Potrebno je

izpostaviti pomanjkljivosti zgoraj omenjenih protokolov [13].

o Storitev A pošlje sporočilo B. Storitev B delno obdela sporočilo in ga posreduje

storitvi C. HTTPS omogoča preverjanje avtentifikacije, zaupnost in integriteto

med AB in BC storitvami. Vendar ne more preveriti avtentifikacije med storitvijo

A in C.

o Pri uporabi Basic Access Authentication je pri uporabi takšnih storitev za vsako

zahtevo potrebno vnesti uporabniško ime in geslo, kar pa je v mnogih

scenarijih nespremenljivo.

WS-Security rešuje problem z uporabo podpisanih, šifriranih varnostnih žetonov. Storitev

A lahko ustvari žeton, ki ga preverja končna storitev C, medtem ko vmesna storitev B ne

more ustvariti varnostnega žetona. Storitev A lahko šifrira oz. podpiše izbrane elemente

ali celotno sporočilo, ki se pošilja. To omogoča potrditev storitvi B in C, da se sporočilo, ki

je bilo poslano iz storitve A, ni spremenilo. Prav tako lahko storitev A celotno sporočilo ali

izbrane elemente sporočila zaklene. To pa zagotavlja, da lahko storitve uporabljajo le tiste

informacije sporočila, ki so jim namenjene. Takšen način preprečuje, da bi storitev B

videla podatke, namenjene za storitev C in obratno [13].

WS-Security za zaščito uporablja obstoječe varnostne modele (Kerberos, X509 itd.).

Specifikacije konkretno opredeljujejo, kako uporabiti obstoječe modele na interoperabilen

način [13].


14

WS-Trust

Varnost temelji na vnaprej določenih razmerjih zaupanja. WS-Trust definira razširjen

model za vzpostavitev in preverjanje zaupanja. Ključni koncept protokola je Security

Token Service (STS). STS je spletna storitev, ki izmenjuje in validira varnostne žetone.

WS-Trust spletnim storitvam omogoča vzpostavitev na varnih, zaupanja vrednih spletnih

strežnikih. STS ima široko uporabnost v izdaji varnostnih žetonov, ki ponujajo široko

paleto potrjevanj. V mnogih primerih se uporablja za izdajo enakih potrjevanj, vendar v

različnih formatih. Razloženo na primeru: STS izda Kerberos žeton in trdi, da je ključni

nosilec tega žetona »Jure Hrastnik« in ta trditev temelji na X.509 zaupanja vrednemu

certifikatu. To organizacijam omogoča uporabo različnih varnostnih tehnologij. STS lahko

izda tudi varnostni žeton in trdi, da je ključni nosilec član neke organizacijske skupine in ta

temelji na prejetem varnostnem žetonu ter s tem potrjuje njegovo identiteto [13].

WS-SecureConversation

Nekateri scenariji spletnih storitev vključujejo le izmenjavo nekaj kratkih sporočil. WS-

Security podpira te modele komunikacije. Nekateri scenariji pa zahtevajo izmenjavo dolgih

sporočil komuniciranja med spletnimi storitvami, ki jo WS-Security sicer podpira, ampak

rešitev ni optimalna. Obstajata dva načina uporabe v teh primerih. Prvi je ponavljajoča

uporaba računalniško zahtevnih kriptografskih operacij, kot je validacija javnih ključev.

Druga rešitev pa je pošiljanje in sprejemanje večjega števila sporočil z uporabo istih

šifrirnih ključev, kar pa omogoča brute force napade. Zaradi teh razlogov pri komunikaciji,

uporabimo HTTP/S protokol z uporabo javnih ključev, ki definira specifične ključe.

Izmenjava s ključi omogoča učinkovitejšo varnostno implementacijo, kot tudi zmanjša

količino prenosa podatkov, kriptirano s posebnim nizom ključev. Pogosto se za začetek

vzpostavitve komuniciranja ali seje uporablja protokol WS-Security z javnimi ključi in WS-

SecureConversation za uporabo potrjevanja ključev za podpisovanje in šifriranje podatkov

[13].

WS-Federation

Omogoča različnih varnostnim skupinam, da se združijo v federacijo. Takšna združitev

pomeni, da je pooblaščen dostop do sredstev, predstavljen v eni varnostni skupini, lahko

prenesen v druge varnostne skupine. Federacija je zbirka dveh ali več entitet, kjer so

sredstva ene entitete dostopna drugi entiteti [14].

4.1 Zanesljivo sporočanje

V internetnem svetu so skoraj vsi komunikacijski kanali nezanesljivi. Sporočila izginjajo,

povezave se prekinjajo. Ta protokol zagotavlja in rešuje te probleme komunikacijske

nezanesljivosti. Brez standarda za zanesljivost sporočil bi bilo potrebno razviti dodatne


15

funkcije v aplikacijah, ki bi nadomeščale ta protokol. Osnovni pristopi upravljanja

zanesljivosti v poslovnih sistemih zagotavljajo sporočila z unikatnim identifikatorjem,

zaporedno številko in uporabo nadomestila pri izgubi sporočila [13].

WS-ReliableMessaging

Definira mehanizme, ki spletnim storitvam omogočajo dostavo sporočil preko

nezanesljivih komunikacijskih omrežij. WS-ReliableMessaging zagotavlja izvajanje storitev

interoperabilno in s tem omogoča lažji razvoj aplikacij, ki uporabljajo te protokole. Zmanjša

se obseg poslovne logike in pogojev o napakah, ki jih je potrebno obvladovati. Protokol

tako vsebuje bogat nabor sporočilno usmerjene arhitekture za zanesljivo usmerjanje in

distribucijo sporočil. Vsaka implementacija uporablja lastne protokole. WS-

ReliableMessaging protokoli zagotavljajo izmenjavo sporočil na različnih operacijskih

sistemih tako, da podpirajo premostitev dveh različnih infrastruktur v enotno, logično

povezano končno celoto [13].

4.2 Transakcije

Zapleteni poslovni procesi lahko za izmenjavo zahtevajo več sklopov izmenjave sporočil.

Primer so finančne organizacije, ki vključujejo zavarovalne police, izposoje, preverjanje in

posredovanje računov. Večkratno izmenljivost sporočil med udeleženci pa predstavljata

logično opravilo ali proces [13]. Takšne procese podpirajo naslednji mehanizmi:

WS-Coordination

Je splošen mehanizem za zagon več opravilnih spletnih storitev. Vsebuje tri ključne

elemente [13]:

o Sporočilni element pokliče koordinacijski kontekst, ki vsa sporočila izvaja v

toku med izmenjavo. Koordinacijski kontekst vsebuje referenco končne točke

protokola »WS-Addressing« do točke koordinacijske storitve. Ta pa vsebuje

podatke za identifikacijo določenega opravila, ki se upravlja.

o Upravljalna storitev. Zagotavlja storitev, opisano z uporabo WSDL-ja, ki

zagotavlja možnost začetka ali konca upravljanega opravila, dovoljuje

udeležencem, da se vključijo v opravilo in sodelujejo v upravljanem kontekstu,

ki predstavlja sestavni del vseh sporočil v skupini.

o Upravljana storitev vsebuje vmesnik, ki je definiran z WSDL dokumentom,

preko katerega vse udeležence storitev obvešča o rezultatih upravljanega

opravila.

WS-Coordination je splošno zmogljivo ogrodje. Razširjata ga ogrodja WS-

AtomicTransaction in WS-BusinessActivity, ki udeležencem v porazdeljenih operacijah

omogočata robustno sporočanje rezultatov [13].


16

WS-AtomicTransaction

Je interoperabilen transakcijski protokol, kar omogoča izvajanje porazdeljenih transakcij z

uporabo sporočil spletnih storitev in usklajuje interoperabilni način med heterogeno

transakcijsko infrastrukturo. WS-AT uporablja dvofazni način potrjevanja za izvajanje

atomarnih rezultatov med porazdeljenimi aplikacijami, upravljavci virov in transakcij.

Atomarne transakcije dvofaznega potrjevanja koordinira registrirane storitve z namenom

odobritve ali zavrnitve odločitev, ki so enake za vse storitve v transakciji. Obstajata dve

fazi, in sicer: v fazi priprave sodelujejo vsi udeleženci , ki morajo potrditi ali zavrniti

sodelovanje, ki jo vodi koordinator skupine, v fazi potrjevanja pa morajo vsi udeleženci

odločitev potrditi, v nasprotnem primeru je proces zavrnjen. Čeprav koordinacijski protokol

definira interakcijo med dvema udeleženca, je 2PC protokol primer, kako poteka

interakcija med več udeleženci. Pri atomarnih transakcijah obstaja močna delitev med

aplikacijo in koordinatorjem. Aplikacija definira storitve, vključene v transakcijo, ki so

potrjene ali zavrnjene. Zatem pa koordinator prevzame odločitev o končnem rezultatu.

Protokoli s specifikacijo WS-AtomicTransaction omogočajo funkcionalnost ACID (Atomic,

consistent, isolated, durable), ki je najbolj razširjena med porazdeljenimi transakcijski

aplikacijami [13,11].

o Atomic: vse spremembe v transakciji so uspešne ali nobena. Ta lastnost izvaja

funkcijo rollback, ki je odgovorna za povrnitev sprememb nedokončane

transakcije v prvotno stanje.

o Consistent: nobena sprememba podatkov, ki je kot rezultat transakcije, ne

sme kršiti podatkovnih modelov, kajti vse takšne akcije so v transakciji

povrnjene z rollback operacijo.

o Isolated: če pride do več transakcij istočasno, se ne sme zgoditi, da bi

posegale ena v drugo. Vsaka transakcija se mora izvesti posamično.

o Durable: po uspešno končani transakciji bodo spremembe ostale tudi v

primeru izpada električne energije ali kakršnekoli napake.

WS-BusinessActivity

Ta storitev uporablja več atomarnih transakcij za prehajanje iz enega prvotnega stanja v

drugega. To dopolnjuje avtomatsko upravljanje sistemsko ustvarjenih izjem atomarnih

transakcij, tako da ta poslovna aktivnost samo upravlja z aplikacijskimi izjemami. Vsaka

poslovna aktivnost se mora izvajati z enotnim sporazumom. Če aplikacija vključuje več

različnih sporazumov, potem je potrebno uporabiti več poslovnih aktivnosti. Primer

aktivnosti, ki vključuje en par aktivnosti: kupec pošlje naročilo k prodajalcu storitev;


17

prodajalec nudi ponudbo, ki je dobra v nekem časovnem obdobju ali jo prekliče; kupec se

lahko odloči za nakup ali pa naročilo prekine [11].

WS-Coordination zagotavlja enotnost za ustvarjanje, širjenje in povezovanje porazdeljenih

aktivnosti. WS-AtomicTransaction in WS-BussinesActivity zagotavljata razširitev tega s

protokoli. Skupaj tvorijo usklajevalne mehanizme za upravljanje izjem iz različnih virov v

realnem svetu. V povezavi z drugimi standardi spletnih storitev se uporabnost kaže v

aplikacijah, pri katerih se obseg raztega med različnimi podjetji in v podjetju z različnimi

ponudniki programske opreme [11].


18

5 REST SPLETNE STORITVE

Representational State Tranfer (REST) je arhitekturni slog in ne protokol, ki je bil

predstavljen v doktorski disertaciji Roy-a Fieldinga na Kalifornijski univerzi. REST je

skupek pravil, ki temeljijo na zgradbi svetovnega spleta. Uspeh svetovnega spleta lahko

pripišemo njegovi arhitekturi. Arhitektura spleta temelji na nekaj temeljnih načelih, ki

obstajajo še danes [12]:

Naslovljivi viri,

Standardni podatkovni format,

Enoten vmesnik za povezovanje z viri,

Interakcija brez stanja med odjemalci in ponudniki storitev,

Hiperpovezava za navigacijo med viri.

Vse na spletu je naslovljivo. Uniform Resource Identifiers (URI) se uporablja za definiranje

lokacije posameznih virom. Viri so lahko v obliki HTML spletnih strani, dokumentov, slik ali

drugih medijskih formatov. Naslavljanje je eden najpomembnejših uspehov spleta. Ena

izmed moči spleta izhaja iz dejstva, da so na spletu standardni medijski tipi. To

proizvajalcem omogoča svobodo pri razvijanju spletnih brskalnikov, saj ne potrebujejo

dovoljenja. To pomeni, da lahko programi in uporabniki dostopajo do spletnih virov z

uporabo enega izmed operacijskih sistemov, ki ima naložen spletni brskalnik. Enotni

spletni vmesnik temelji na HTTP (Hypertext Transfer Protocol), odprtosti in

interoperabilnosti. HTTP protokol je odprt in dobro znan, opredeljuje enoten način za

interakcijo med uporabniki in viri, ki se izvajajo na spletnem strežniku. Te interakcije

temeljijo na glagolih (GET, POST, PUT, DELETE), ki spremljajo vsako HTTP zahtevo.

GET je eden izmed najbolj pogosto uporabljenih metod, saj že ime predstavlja njegov

učinek. Metoda GET za določen URI vrne kopijo vira, ki ga predstavlja. Pomembna

lastnost te metode je, da lahko rezultat shranimo v predpomnilnik. Predpomnjenje GET

zahteve prispeva tudi k razširljivosti spleta. Predstavlja varno zahtevo, saj po

specifikacijah HTTP protokola naj ne bi povzročal sprememb vira, do katerega dostopa.

Seveda se lahko spremeni vir med dvema različnima GET zahtevama, vendar bi morale

biti to neodvisne akcije storitev.

POST označuje zahtevo, s katero je mogoče ustvariti nov vir in je druga najbolj pogosta

uporabljena zahteva [12].

HTTP in splet sta bila zasnovana, da sta brez stanja. Storitev brez stanja pomeni, da

lahko obdela procese, ki temeljijo na eni zahtevi (ne obdrži podatkov skozi več povezav).


19

Hiperpovezave med posameznimi viri so tudi del uspeha svetovnega spleta. V bistvu

omogočajo navigacijo med povezanimi viri, kar pa prinaša široko povezljivost spleta kot

takšnega. Svetovni splet je največja, najbolj prilagodljiva, interoperabilna porazdeljena

aplikacija [12].

REST je arhitekturni slog za gradnjo spletnih storitev. Slog temelji na arhitekturi spleta in s

tem predstavlja precejšnjo razliko med REST in SOAP pristopom. Medtem ko je SOAP

neodvisen od protokola, kar pomeni, da ni vezan na specifičen protokol, je REST odvisen

od HTTP protokola. Čeprav je mogoče uporabiti druge protokole pri tem arhitekturnem

slogu, so največje prednosti uporabe tega pristopa s protokolom HTTP. Pomembna

razlika je tudi ta, da SOAP ni v celoti arhitekturni slog, ampak SOAP specifikacije določajo

tehnične podrobnosti, kako se dve končni točki povezujeta z vidika predstavitve sporočila

in da ne ponuja nobenih arhitekturnih smernic in omejitev. To je v nasprotju z REST

storitvami, ki so zgrajene s posebnimi omejitvami in arhitekturnim stilom. SOAP temelji na

storitvenem naboru akcij in enem URI naslovu, REST storitveni model za povezovanje z

uporabniki pa temelji na virih. Vsak vir je predstavljen z unikatnim URI naslovom in

uporablja enoten vmesnik HTTP protokola za povezovanje z viri preko URI naslova.

Lahko rečemo, da REST storitve operirajo bolj s samostalniki (viri) kot z glagoli, http

metode ali SOAP akcije pa obratno, saj se struktura REST storitev vrti okoli URI naslova

[12].

5.1 Viri

Prva stvar pri oblikovanju REST storitev je definiranje, kateri viri bodo izpostavljeni. Vir je

vsaka informacija, ki je na voljo preko določenega naslova [12]:

Seznam vseh najbližjih bencinskih črpalk glede na poštno številko.

Vse fotografije Janeza Novaka iz 13. 4. 2013.

Trenutno stanje delnice posameznih podjetij.

Kot lahko vidimo, so lahko viri statični (slike, posnete na določen datum) ali dinamični

(iskanje najbližjih bencinskih črpalk glede na poštno številko). Večina virov je po navadi

dinamične narave. Viri so konceptualna preslikava posamezne entitete, s katerimi

ustvarjene storitve upravljajo. Ko definiramo REST storitve, je potrebno identificirati vire, ki

bodo na voljo za uporabo. Po identificiranju virov pa sledi preslikava v URI naslove [12].

5.2 URI naslavljanje

Ena od glavnih in najpomembnejših uspehov svetovnega spleta je, da do vseh virov

dostopamo preko enolično določenega URI naslova. Se pravi, da zgradba REST storitev

temelji na izkušnjah uporabnosti obstoječega spleta [12]. Odličen primer spletne strani, ki


20

uporablja uri naslavljanje, je Flickr (www.flickr.com). To spletno mesto omogoča

shranjevanje, ogled in izmenjavanje fotografij na spletu. Tukaj so prikazani viri, ki jih

spletno mesto ponuja zame:

Vse fotografije,

Vse fotografije glede na izbran datum,

Vse fotografije iz določene galerije.

Spodaj so prikazani dejanski naslovi do virov:

http://www.flickr.com/photos/jurehrastnik,

http://www.flickr.com/photos/jurehrastnik/archives/date-posted/2013/07/09/,

http://www.flickr.com/photos/jurehrastnik/galleries/72157605450493091/.

5.3 Enotni vmesnik

V REST storitvah je dostop do virov določen z edinstvenim URL naslovom. To je ena

izmed omejitev tega arhitekturnega sloga. Druga omejitev je, kako se povezujemo z viri.

Komunikacija z viri poteka z uporabo HTTP metod. Metode predstavljajo enotni vmesnik,

ki se uporablja v zahtevi določenega URL-ja. Pri uporabi REST storitev tako uporabljamo

metode, ki jih predpisuje HTTP standard. Idempotent pomeni, da če neko akcijo izvedemo

večkrat, bo učinek enak, kot če bi jo izvedli samo enkrat. Metoda »post« je nevarna zato,

ker ni predpisanega pravila, kaj se bo zgodilo, ko jo uporabimo. Storitev, ki proži to

zahtevo, lahko nad viri, do katerih dostopa, počne karkoli [12].

Slika 3 HTTP metode in njihov opis [12]

• pridobivnje vira

• je varen

• omogoča medpomnjenje GET

• ustvari nov vir

• ni varen, učinek ni definiran z HTTP POST

• posodobi vir

• uporabljen za ustvarjanje virov pri znanem URI-ju

• idempotenten

PUT

• brisanje virov

• idempotenten DELETE


21

5.4 Predstavitev virov

Storitve REST pri obliki predstavitve vira nimajo arhitekturne omejitve. To daje svobodo,

če upoštevamo različne potrebe aplikacij in uporabnikov svetovnega spleta. Vir je

tehnično predstavljen kot tip medija, ki vedno vrača HTTP odgovor v obliki HTTP glave (

Content-type ) [12].

XML

Je okrajšava za angleški izraz Extensible Markup Language, kar pomeni razširljiv

označevalni jezik. XML je preprost računalniški jezik, podoben HTML-ju, ki omogoča

format za opisovanje strukturiranih podatkov ali arhitekturo za prenos podatkov in njihovo

izmenjavo med več omrežji [12].

RSS/ATOM

So priljubljeni viri na spletu. Običajno so povezani z objavljanjem novic in posebno vrsto

spletnih aplikacij, ki so znane kot spletni dnevnik oz. blogi. Obstajata dva načina XML

besednjakov za objavljanje novic. To sta RSS, ki je končnica za Really Simple

Syndication in Atom besedilni format. Atom pa poleg formata za objavljanje predstavlja,

da je zgrajen na omejitvah in načelih REST arhitekturnega sloga [12].

XHTML

Razširljiv označevalni jezik (Extensible Hypertext Markup Language) je prilagojen XML-ju.

Ker mora biti dokument XHTML tvorjen pravilno, ga lahko samodejno razčlenimo kar s

preprostimi razčlenjevalniki XML [12].

JSON

Javascript Object Notation (JSON) je vrsta podatkovnega medija z oznako

(application/json), ki je tekstovna oblika vira za predstavitev programskih podatkovnih

tipov. Je preprosta omrežna podatkovna predstavitev objektov, po navadi povezana z

JavaScriptom. JSON se uporablja kot podatkovni format v različnih programskih jezikih in

okoljih. Ena izmed uporabe tega podatkovnega formata je v povezavi z JavaScriptom in

Ajax spletnimi aplikacijami. Njegova prednost je optimalna poraba prenašanja podatkov

skozi omrežje v primerjavi z XML podatkovnim formatom [12].


22

6 WINDOWS COMMUNICATION FUNDATION

6.1 Ogrodje

WCF (Windows Communication Fundation) je ogrodje za izgradnjo storitvenousmerjenih

aplikacij. Z uporabo tega ogrodja lahko pošiljamo podatke iz ene storitve v drugo kot

sinhrona ali asinhrona sporočila. Končna točka kot storitev je na voljo preko gostovanja

strežnika IIS ali storitve v aplikaciji. Končna točka je lahko odjemalec storitve, ki pošlje

zahtevo končni točki storitve. Vsebina sporočil je lahko preprosta kot posamezen znak,

besedilo poslano v XML ali zapleten tok binarnih podatkov. Pokriva celotno

komunikacijsko .NET okolje [30]. V našem diplomskem delu se bomo osredotočili na

podporo WSE protokolov in REST arhitekturnega modela v ogrodju WCF.

Značilnosti WCF ogrodja

WCF ogrodja sestavljajo naslednje značilnosti [27, 30]:

Storitvena orientacija

WCF ogrodje nam omogoča, da zgradimo storitveno usmerjene aplikacije. Takšne

aplikacije uporabljajo storitve za pošiljanje in sprejemanje podatkov, pri čemer je prednost,

da so med seboj šibko sklopljene. V šibko sklopljeni storitveni arhitekturi se lahko vsak

odjemalec poveže z gostiteljem storitev, dokler izpolnjuje storitveno pogodbo.

Interoperabilnosti

WCF podpira interoperabilnost z več specifikacij spletnih storitev in s tem implementira

večje število storitvenih protokolov.

Sporočilni vzorci

WCF podpira več vzorcev za izmenjavo sporočil od ene do druge končne točke. Najbolj

pogost vzorec prenašanja sporočil je zahteva odgovor, kjer ena končna točka pošlje

zahtevo s podatki do druge točke in zahteva odgovor. V One-Way sporočilnem vzorcu

končna točka pošlje sporočilo drugi točki in od nje ne pričakuje odgovora. Duplex

sporočilni način pa omogoča vzpostavitev povezave na obeh končnih točkah in pošiljanje

sporočil v eno in drugo smer v obliki sporočilnega klepeta.

Opis storitev

Standardnimi industrijski formati, kot so WSDL, XML besednjak in WS-Policy opisujejo

storitve. Ti metapodatki so lahko objavljeni preko HTTP/S protokolov in odjemalske

aplikacije te metapodatke uporabljajo za generiranje ali nastavitev datotek na strani

odjemalca, ki komunicira s to spletno storitvijo.

Podatkovne pogodbe

V .NET okolju so podatkovne pogodbe razredi, ki predstavljajo model z lastnostmi, ki

pripadajo entiteti. Ti razredi se uporabljajo za izmenjavo podatkov med WCF storitvami in


23

odjemalci. Storitvena arhitektura samodejno generira metapodatke iz teh razredov, kar

odjemalcem omogoča pošiljanje in sprejemanje podatkov.

Varnost

WCF podpira šifriranje sporočil, da zaščiti zasebnost podatkov z uporabo znanih

standardov, kot so SSL ali WS-Security.

Prenos podatkov in kodiranje

Podpira več vrst vgrajenih protokolov za prenos in kodiranje sporočil. Preko HTTP

protokola lahko pošiljamo tekstovna sporočila v SOAP formatu. Druge podprte opcije so z

uporabo TCP, PIPE ali MSMQ protokolov. Sporočila so lahko zapisana v obliki teksta ali

binarnega zapisa z uporabo MTOM standarda. Ponuja pa tudi možnost ustvarjanja

svojega prenosa in kodiranja podatkov.

Transakcije

WCF podpira tri različne modele transakcij: WS-AtomicTransactions, aplikacijski

programski vmesnik v imenskem področju, System.Transactions in Microsoft Distributed

Transaction Coordinator.

Podpora AJAX in REST arhitekturnega modela

Za podporo tehnologijam modernega spleta 2.0, kot so REST, JSON, ATOM ipd. WCF

ogrodje omogoča obdelavo podatkov v preprostem XML formatu brez uporabe SOAP

ovojnice.


24

Slika 4 Razširjen model WCF ogrodja [31]

Prednosti [31]:

1. Je interoperabilno ogrodje z drugimi storitvami – v primerjavi z .NET Remoting,

kjer morata biti storitev in odjemalec napisana v .NET okolju.

2. Zagotavljajo večjo zanesljivost in varnost v primerjavi z ASMX spletnimi storitvami.

3. Implementracijo varnosti ali spreminjanje povezav (bindings) dosežemo z

minimalnim spreminjanjem konfiguracije.

4. WCF ogrodje ponuja nastavitvene datoteke, s katerimi dosežemo enak učinek, kot

bi z implementacijo programske kode dosegli v drugih ogrodjih.

Slabost:

1. Izdelava oziroma izbira pravega modela je lahko zapletena [31]. V nadaljevanju

bomo pri odločitvi pravilnega modela to nejasnost poskušali odpraviti.

6.1.1 Naslavljanje

V WCF je vsaka storitev predstavljena z unikatnim naslovom. Naslov zagotavljata dva

pomembna elementa [24]:


25

Lokacijo storitve in transportni protokol, ki je uporabljen pri komunikaciji storitve. Lokacija

označuje [24]:

Naslov ciljne naprave, strani ali omrežja.

Vrata komuniciranja, cevi (pipe) ali čakalna vrsta.

Neobvezen del poti ali URI (Universal Resource Identifier) naslov, ki mora biti unikaten

niz znakov (po navadi predstavlja naziv spletne storitve, lahko pa tudi globalni enolični

identifikator).

WCF ogrodje podpira transportne sloje [24]:

HTTP/HTTPS

TCP

IPC

Peer network

MSMQ

Storitveno vodilo

Vsi naslovi so predstavljeni kot [ osnovni naslov ] / [ opcijski URI ]

Prvi del naslovna je vedno v obliki [24]:

[ transport ] : // [ naprava ali domena] [ : opcijsko vrata ].

Primeri naslovov:

http://localhost:8001

http://localhost:8001/MojaStoritev

net.tcp://localhost:8002/MojaStoritev

net.pipe://localhost/MojaPipa

net.msmq://localhost/private/MojaCakalnaVrsta

net.msmq://localhost/MojaCakalnaVrsta

TCP naslavljanje

Tcp za naslavljanje uporablja net.tcp za transport in po navadi vključuje številko vrat

net.tcp://localhost:8002/MojaStoritev. V kolikor številka vrat ni definirana, se uporabi

privzeta vrednost 808 [24].

HTTP naslavljanje

Uporablja http za transportni protokol in tudi https za varne povezave. Nahaja se na

naslovu http://localhost:8001. V kolikor vrata niso definirana, se privzeto uporabijo vrata

80 ali 443 za HTTPS. Dva naslova z istim gostiteljem si lahko delita vrata, vendar samo

na enaki napravi [24].

IPC naslavljanje


26

IPC (Inter Process Communication) za naslavljanje uporablja net.pipe za transport, ki

uporablja Windows mehanizem cevi (pipe). WCF storitve, ki uporabljajo ta mehanizem

IPC, lahko sprejemajo klice le iz istega stroja. Zato je potrebno ekplicitno navesti ime

računalnika ali naslov v obliki net.pipe://localhost/MyPipe in je lahko samo ena odprta cev

na računalnik [24].

MSMQ naslavljanje

Microsoft Message Queue, kratica MSMQ, označuje Microsoftovo sporočilno čakalno

vrsto. Sporočilna čakalna vrsta se v WCF ogrodju obravnava kot ostale transportne

povezave [24].

Storitveno vodilo

Windows Azure AppFabric storitveno vodilo uporablja sb, http in https za transport in mora

vsebovati naslov storitvenega vodila skupaj z imenskim prostorom storitve. Primer:

sb://MyNamespace.servicebus.windows.net/ [24].

6.1.2 Pogodbe

V ogrodju WCF vse storitve predstavljajo pogodbe. Pogodba je neodvisna od platforme in

standarda za opisovanje storitev. WCF definira štiri vrste različnih pogodb [24]:

Storitvene pogodbe (ServiceContract)

Opisuje, do katerih operacij lahko odjemalec dostopa v storitvi.

Podatkovne pogodbe ( Data Contract )

Podatkovna pogodba definirajo formalni sporazum med storitvijo in odjemalci, ki na

abstrakten način opišejo podatke, ki se izmenjujejo. Podatkovne pogodbe so lahko

ekplicitne ali implicitne. Preprosti podatkovni tipi int, string so implicitni, medtem ko so

objektni tipi eksplicitni ali complektni tipi, ki jih označimo z DataContract in njihove atribute

z DataMember. Podatkovne pogodbe definirajo naslednje [26]:

o Opisujejo zunanjo obliko podatkov, ki se uporabljajo pri operacijah storitev.

o Definirajo strukturo in podatkovne tipe podatkov pri izmenjavi sporočil storitev.

o Definirajo predstavitev podatkov pri serializaciji in desiralizaciji. Pri serializaciji

pretvorijo objekte v zaporedje bajtov, ki se prenašajo skozi omrežje. Pri

desirializaciji pa zgradijo objekt iz zaporedja bajtov, ki se je prenesel preko

omrežja kot odgovor na zahtevo.

Pogodbe sporočanja (MessageContract)

Pogodbe sporočanja so paket podatkov, ki vsebuje pomembne podatke. WCF ogrodje ta

sporočila uporablja za prenos podatkov od začetne do končne točke.

Obstajajo trije načini komunikacije med dvema točkama [25]:

1. Simplex: je enosmerna komunikacija, kjer se sporočilo pošlje končni točki, pri

čemer se končna točka pri prejetem sporočilu ne odzove nazaj.


27

2. Request/Response: je dvosmerna komunikacija, kjer točka A pošlje sporočilo točki

B, pri čemer točka B odgovori nazaj s sporočilom, ampak samo v času enega

prejetega sporočila. Kar pomeni, da točka A pošlje sporočilo in ko dobi odgovor,

lahko pošlje naslednje sporočilo točki B

3. Duplex: je dvosmerna komunikacija, kjer poteka izmenjava sporočil ne glede na

prejeto poslano sporočilo.

WCF ogrodje podpira bodisi klic oddaljenih procedur ( RPC ) bodisi sporočilni stil modela

operacije [25].

Pogodbe o napakah (FaultContract)

Storitve, ki jih razvijemo, lahko v nekaterih primerih vsebujejo napake. To napako je na

nek način potrebno predstaviti odjemalcu. V mnogih primerih, ko razvijemo aplikacijo ali

storitev, uporabimo try-catch blokovni stavek. Te pogodbe nam omogočijo definirati

napake in jih nastaviti operacijam ter najti način, kako napake predstavimo odjemalcu

[24].

6.1.3 Vezave

Vezave opisujejo, na kakšen način odjemalec komunicira s storitvijo. Obstajajo različni

protokoli v WCF ogrodju za komunikacijo z odjemalci. Izbira protokola je odvisna od

potreb, ki jih želimo zagotoviti. Vsebujejo naslednje tri karakteristike [24]:

o Transport definirajo osnovni protokol HTTP/S, cevi (pipe), TCP, IPC in MSMQ.

o Kodiranje (opcijsko) je tekstovno, binarno in MTOM (Message Transmission

Optimization Mechanism), ki je interoperabilen sporočilni format. Podpira efektiven

prenos velike količine podatkov ali priponk.

o Protokol (opcijsko) določa podatke v povezavi, kot so zagotavljanje varnosti, transakcij

ali zanesljivosti prenosa sporočil.

WCF definira naslednje pogosto uporabljene vezave [24]:

o BasicHttpBinding

Primeren za komunikacijo z ASP.NET spletnimi storitvami (ASMX).

Za transport se uporablja http protokol ter za kodiranje sporočil tekst/XML zapis.

Varnost je privzeto izključena. Ne podpira WS specifikacij varnosti, zanesljivosti in

transakcij. Je delno interoperabilen.

o WS2007HttpBinding

Zagotavlja varno in interoperabilno vezavo, ki zagotavlja podporo za varnost

(Security), zanesljivost seje (ReliableSession) in transakcije (TransactionFlow).

o NetTcpBinding

Varna in optimizirana vezava, primerna za komunikacijo med WCF aplikacijami.

o NetNamePipeBinding

Varna in zanesljiva optimizirana vezava, primerna za komunikacijo med WCF

aplikacijami. Za sporočila je uporabno binarno kodiranje.


28

o WSHttpBinding

Definira varno, zanesljivo, interoperabilno vezavo in ne omogoča storitev dvosmerne

komunikacije sporočilne pogodbe. Podpira WS-specifikacije in porazdeljene

transakcije. Za zanesljivost in varnost seje uporablja SOAP zaščito. Uporablja http in

https transport za komunikacijo. Zanesljivost sej je privzeto onemogočena.

o WSDualHttpBinding

Je enaka zgoraj opisani vezavi, razen da ta podpira dvosmerno komunikacijo.

Dvosmerna komunikacija je storitev, ki uporablja sporočilni vzorec »duplex«, ki

omogoča komunikacijo odjemalca z »callback« funkcijo.

o WSFederationHttpBinding

Zagotavlja varno in interoperabilno vezavo s podporo WS-Federation protokola, ki

organizacijam omogoča učinkovito preverjanje pristnosti in avtorizacijo uporabnikov.

o WS2007FederationHttpBinding

Je nadgradnja WSFederationHttpBinding vezave, od katere podeduje vso podporo.

o NetMsmqbinding

Za prenos uporablja MSMQ protokol. Uporablja se za nepovezljive operacije.

Omogoča vezavo čakalne vrste in je primerna za komunikacijo med WCF aplikacijami.

Uporablja se za izključene operacije.

o NetPeerTcpBinding

Zagotavlja varnost in omogoča komunikacijo med več napravami.

o WebHttpBinding

Vezava se uporablja za konfiguracijo končne točke za WCF spletne storitve, ki so

izpostavljene preko HTTP zahteve namesto SOAP sporočila.

Spodnja tabela prikazuje zgoraj opisane vezave, njihove transportne protokole, kodiranje

in interoperabilnosti.

Tabela 2 WCF vezave in njihove lastnosti [32,24]

Vezava Transport Kodiranje Interoperabilnost

BasicHttpBinding HTTP/S Text, MTOM Basic Profile 1.1

NetTcpBinding TCP Binarno .NET

NetNamedPipeBinding IPC Binarno .NET

WSHttpBinding HTTP/S Text, MTOM WS

NetMsmqBinding MSMQ MTOM .NET

WsDualHttpBinding HTTP Tekst,MTOM WS

WsFederationHttpBinding HTTP Tekst,MTOM WS-Federation

WebHttpBinding HTTP/S Tekst HTTP

NetPerTcpBinding TCP MTOM Peer

WS2007FederationHttpBinding HTTP/S Tekst,MTOM WS-Federation

WsFederationHttpBinding HTTP/S Tekst,MTOM WS-Federation

Ws2007HttpBinding HTTP/S Tekst,MTOM WS


29

6.1.4 Končne točke

Vsaka storitev je povezana z naslovom, ki predstavlja, kje se storitev nahaja. Povezave

nam definirajo način komunikacije s storitvami, pogodbe pa nam povedo, kaj storitve

pravzaprav počnejo. Vse te tri točke lahko najlažje poimenujemo z ABC. Končna točka

tako poveže vse te tri elemente v zaključeno celoto. Vsaka končna točka mora vsebovati

vse tri elemente, ki so izpostavljeni v gostovanju. Za vsako storitev je potrebno izdelati

vsaj eno končno točko in vsaka končna točka pripada natanko eni pogodbi. Vse končne

točke imajo unikaten naslov. Končne točke lahko uporabljajo enake ali različne vezave in

pogodbe. Ni omejitve, na koliko različnih končnih točk lahko predstavimo storitev. Velika

prednost je, da so končne točke neodvisne od storitev. Konfiguracijo je možno opraviti na

administrativen način (z uporabo nastavitvenih datotek) ali programsko [24].

Slika 5 Pristop ABC v ogrodju WCF [27]

6.2 Gostovanje

Gostovanje v ogrodju WCF vključuje izvajanje končnih točk znotraj izvajalnega procesa.

Zaradi skupnega izvajalnega okolja (ang. Common Language Runtime,) na katerem

temelji tudi WCF ogrodje, lahko gostimo končne točke v notranjosti izvajalnega procesa, ki

jih naloži CLR ogrodje. Glavne možnosti gostovanja so »Windows Services«, »Windows

applications« ali IIS [12].

Samogostovanje

Je gostovanje, pri katerem sami ustvarimo nov objekt razreda »ServiceHost« in z njim

kličemo metodo »ServiceHost.Open«. Proces, ki vsebuje to programsko kodo, je lahko

katerikoli proces, ki ga naloži CLR okolje. Možnosti implementacije samogostovanja so


30

konzolne in namizne aplikacije ali storitev »Windows Service«. Seveda lahko takšna

aplikacija ustvarja in upravlja z več kot enim »ServiceHost« objektom tega razreda.

Fleksibilnost uporabe različnih procesov pri samogostovanju je eden od razlogov odločitve

za samogostovanje namesto upravljanega. Glavne prednosti samogostovanja so, da

lahko sami ustvarjamo, konfiguriramo in odpiramo nove objekte primerkov razreda

»ServiceHost«. V našem diplomskem delu smo izbrali takšen način gostovanja [12].

ISS

Drug način za gostovanje WCF spletnih storitev je, da konfiguracija poteka znotraj IIS

(ang. Internet Information Services). Takšen način imenujemo upravljano gostovanje, saj

ISS upravlja naslednje zadolžitve:

o Zagon in zaustavitev procesov

o Proces združevanja in recikliranja

o Ponovna vzpostavitev pri spremembi konfiguracije ali programske kode

o Varnost

Gostovanje v okolju IIS nam prinaša prednosti, saj nam ponuja že zgrajene vmesnike za

upravljanje storitev. Naslednja prednost je enostavna nastavitev predpomnjenja za REST

končne točke, katere uporabljajo ISS za gostovanje [12].


31

7 PRIMERJAVA SOAP IN REST PRISTOPA

7.1 Tehnologija

Pri REST spletnih storitvah gre vse prej za staro kot novo tehnologijo. Za razliko od SOAP

tehnologije, ki je obljubljala novo fazo spletnega razvoja interneta z mnogimi novimi

specifikacijami, se filozofija REST storitev zavzema, da so obstoječa načela in protokoli

dovolj za ustvarjanje zanesljivih spletnih storitev. To pa nam pove, da z razumevanjem

HTTP protokola in XML tehnologije pričnemo graditi spletne storitve, brez da bi

potrebovali orodja, ki se običajno uporabljajo za razvoj internetnih aplikacij [15]. SOAP

storitve temeljijo na operacijah, ki so predstavljene v poslovni logiki. SOAP je specifičen

protokol za izmenjavo podatkov med dvema končnima točkama. Odjemalci SOAP storitev

kličejo metode, ki so objavljene kot spletne storitve na oddaljenem strežniku. REST

storitve temeljijo na virih. REST je arhitekturni stil za izgradnjo odjemalec–strežnik

aplikacij. Nagiba se k semantiki HTTP protokola z zahtevami GET, POST, PUT in

DELETE. Odjemalci pošiljajo zahteve, ki jih večina sodobnih brskalnikov podpira in

sprejmejo odgovor v obliki vira, kot so podatki, slike ali video posnetki [16].

7.2 Pasovna širina

Prednost REST spletnih storitev je, da so zahteve in odgovori kratki. SOAP zahteva ovit

XML dokument za vsako zahtevo in odgovor. SOAP sporočila tako pri navadnem

odgovoru zahtevajo več kot 10-krat več bajtov, kot bi enak odziv ponovili v REST spletni

storitvi.

7.3 Oblika sporočila

REST spletne storitve podpirajo XML, JSON in RSS/ATOM oblike sporočila, v primerjavi z

SOAP storitvami, ki podpirajo zahteve in odgovore samo v XML obliki.

7.4 Protokol

SOAP storitve podpirajo širok nabor transportnih protokolov, kot so HTTP, TCP, PIPE,

SMTP, IPC in MSMQ, kar jih dela fleksibilne. Medtem ko REST storitve podpirajo samo

HTTP protokol [16].

7.5 Varnost

SOAP in REST podpirata SSL (Secure Socket Layer) kriptografski protokol, ki omogoča

varno komunikacijo na medmrežju in ščiti podatke le med pošiljanjem, ne pa tudi po tem,

ko prispejo na ciljni računalnik [23]. Hkrati pa SOAP podpira tudi WS-Security, ki definira

dodatne varnostne mehanizme. Omogoča varnost ne le od točke do točke kot SSL


32

protokol, ampak tudi na nivoju sporočil. Varnost REST spletnih storitev je mogoče

implementirati z uporabo OAuth protokola. OAuth je odprt protokol, ki omogoča varno

avtorizacijo na preprost način in je standardni način zaščite za spletne, mobilne in

namizne aplikacije [21].

7.6 Transakcije

SOAP in WS-* specifikacije imajo izrecno podporo za napredno uporabo transakcij,

medtem ko REST nima standardne podpore. WS-Atomic Transactions podpirajo dvofazne

transakcije potrjevanja, ki temeljijo na SOAP spletnih storitvah. REST nima podpore za

porazdeljene transakcije. Na splošno povedano, če želimo vpeljati transakcije v REST

spletne storitve, ustvarimo nov vir z imenom Transakcija. Kadar želimo početi kaj

transakcijskega (kot je na primer naročilo in plačilo izdelka), na odjemalcu ustvarimo

transakcijski vir, ki določa vse vire, ki se bodo izvajali v sklopu transakcije z uporabo

POST zahtevka. Odjemalec lahko nato izvaja upravljanje posodobitev z uporabo PUT

zahtevka in prekine transakcijo s pošiljanjem DELETE zahteve. Takšen način

zagotavljanja transakcije zahteva določeno količino ročnega kodiranja in izrecen nadzor

nad našim sistemom, medtem ko je WS-Atomic Transaction protokol mnogo bolj

avtomatski način transakcije v WCF ogrodju. Če sistem zagotovo potrebuje atomarne

transakcije preko različnih sistemov, je vpeljava SOAP in njegovih specifikacij za

transakcije bolj primerna [15].

7.7 Interoperabilnost

Če definiramo interoperabilnost kot tehnično sposobnost komuniciranja med dvema

različnima končnima točkama, je REST spletna storitev bolj interoperabilna. Eden glavnih

ciljev uvedbe SOAP specifikacij je ustvariti interoperabilen način komuniciranja med

različnimi platformami in jeziki. Vendar so WS.* speficikacije SOAP storitve naredile manj

interoperabilne namesto bolj. Problem SOAP in WS-* specifikacij je veliko število različnih

standardov (ter različnih verzij standardov), med katerimi je mogoče izbirati. V primerjavi z

REST spletnimi storitvami je potrebno pri SOAP storitvam implementirati odjemalca za

pridobitev podatkov preko spletne storitve. REST ima prednost, saj je vse, kar

potrebujemo, dostop do HTTP naslova, kar daje REST storitvam večjo interoperabilnost

[15].

7.8 Opis storitev

REST spletne storitve nimajo direktne podpore za ustvarjanje opisa storitev, kot ima to

rešeno SOAP z WSDL (Web Service Descriptio Language) opisnim jezikom. Za podporo


33

opisom storitvam v REST je namenjen WADL (Web Application Description Langugage).

Je strojno berljiv XML opis, temelječ na HTTP spletni aplikaciji. REST spletne storitve pa

tudi lahko opišemo z WSDL 2.0 opisnim jezikom, saj ponuja podporo za HTTP povezave.

Z uporabo WSDL opisnega jezika je lažje generiranje SOAP spletnih storitev, kot pisanje

kode za pridobivanje REST storitev. Ustvarjanje odjemalca za REST spletno storitev

pomeni, da moramo preučiti storitev, kako deluje in tako zgraditi odjemalca. Na koncu

implementacije odjemalca imamo popolno razumevanje storitev in interakcijo med viri

[15].


34

8 IMPLEMENTACIJA SOAP IN REST PRISTOPA

V nadaljevanju bomo predstavili in implementirali SOAP z WS.* specifikacijami ter REST

spletne storitve na ogrodju WCF. Pri implementaciji se bomo osredotočili na zanesljivost,

transakcije in varnost spletnih storitev z obema pristopoma z zgrajenim .NET odjemalcem.

8.1 Implementracija WCF SOAP storitve

8.1.1 Varnost

Za implementacijo varnosti v WCF ogrodju smo morali spoznati varnostne funkcije, ki se

navezujejo na avtentifikacijo, avtorizacijo, zaupnost in integriteto. Z uporabo »behaviors«

in »bindings« elementov smo nastavili varnost v naši WCF storitvi. »Bindings« in

»Behaviors« nam omogočajo konfiguriranje varnosti prenosa, avtentifikacijo, avtorizacijo

itd. Zaščito prenosa sporočil je mogoče izvesti na dva načina. Varnost prenosa zagotavlja

točkovno zaščito samo preko komunikacijskega kanala (npr. z uporabo SSL protokola),

kar pomeni od ene do druge končne točke, medtem ko sporočilna varnost omogoča

zaščito na nivoju sporočil. Za preverjanje avtentifikacije lahko uporabimo »Windows

authentication«, »Username and Password«, »X509 certificate« in »Issued token« [20].

Pri implementaciji smo se odločili za zaščito s certifikatom. Ustvariti je bilo potrebno dva

certifikata za strežnik in odjemalca ter zagotoviti vse potrebno v shrambi certifikatov. V

konfiguracijski datoteko smo morali nastaviti potrebne lastnosti, da smo povezali našo

WCF storitev s certifikati. Spodnja slika prikazuje, kako smo nastavili tip avtentifikacije in

določili certifikat.

Slika 6 Nastavitev povezovanja certifikata s storitvijo

Ko smo določili tip avtentifikacije in certifikat, smo morali definirati, da bodo vrednosti

avtentifikacije poslane preko sporočila z uporabo certifikata. Spodnja slika prikazuje

nastavitev uporabe certifikata za validiranje odjemalca.


35

Slika 7 Nastavitev sporočilne varnosti, avtorizirane s certifikatom

V nastavitveni datoteki smo povezavo z dodanimi atributi varnosti zvezali s končno točko.

Podoben postopek smo morali ponoviti še na strani odjemalca, kjer smo določili tip

avtentifikacije, certifikat in nadgradili povezavo ter jo povezali s končno točko naše

storitve.

8.1.2 Zanesljivost

WCF SOAP s protokolom »ReliableMessaging« zagotavlja »end-to-end« zanesljivo sejo

med končnima točkama, ne glede na število ali vrsto posrednikov, ki ločujejo sporočila

končnih točk. Vzpostavitev zanesljive seje rešuje dve vrsti napak. SOAP sporočila, ki

vključujejo izgubo, podvajanje in sporočila, ki prispejo v drugačnem vrstnem redu, kot so

bila poslana ter napake pri prenosu sporočila [22]. Zanesljivo sporočanje smo

implementirali z vzpostavitvijo zanesljive seje, kjer smo vključili sejo, omogočili pravilen

vrstni red sporočil ter nastavili samodejno prekinitev vzpostavljene seje. Za varnost smo

uporabili zaščito s certifikatom, ki smo jo opisali zgoraj v prejšnjem podpoglavju. Spodnja

slika prikazuje povezavo »wsHttpBinding«, kateri smo vzpostavili sejo in določili zaščito s

certifikatom.

Slika 8 Nastavitev zanesljive vezave in varnosti


36

8.1.3 Transakcije

V tem podpoglavju smo razložili uporabo transakcij in njegovih lastnosti. Nato pa smo na

primeru prikazali in pojasnili izvajanje transakcij s SOAP spletnimi storitvami na ogrodju

WCF. Implementacija transakcije je v primerjavi z REST spletnimi storitvami v WCF

ogrodju preprosta. Potrebno je nastaviti določene atribute na storitve in operacije in

dopolniti konfiguracijsko datoteko. V WCF ogrodju je za izvajanje transakcij potrebno

vključiti atribut »TransactionFlow«, ki z uporabo »TransactionFlowOption« enumeracij

opisujejo naslednje vrednosti atributa [20].

Allowed: Odjemalec lahko pokliče operacijo v sklopu transakcije.

Mandatory: Zahtevano je, da odjemalec pokliče operacijo v sklopu transakcije, v

nasprotnem primeru WCF ulovi izjemo izvajanja.

NotAllowed: Odjemalcu ni dovoljeno poklicati operacije iz transakcijskega sklopa.

Spodaj je prikazana storitvena pogodba z dvema preprostima operacijama, ki omogočata

transakcije.

Slika 9 Vmesnik s transakcijskimi operacijami

V transakcijskih operacijah je potrebno izvajati nadzor nad tem, kako operacije neke

transakcije vplivajo na druge transakcije [18]. To lahko zagotovimo z uporabo atributa

»TransactionIsolationLevel«, ki ga definiramo v atributu »ServiceBehavior«. Spodaj so

opisane vrednosti te lastnosti, ki jih je možno uporabiti.

Tabela 3 Lastnosti atributa TransactionIsolationLevel [18]

Read uncommited Transakcije niso izolirane ena od druge. Po navadi se

uporabljajo samo za branje.

Read commited Podatkov ni mogoče prebrati dokler, so v transakciji. Lahko pa

se spreminjajo.


37

Repeatable read Podatkov med trajanjem transakcije ni mogoče spreminjati,

lahko pa se dodajajo novi zapisi. Podatki se lahko preberejo.

Serializable Med trajanjem transakcije ni možno dodajati novih zapisov.

Branje podatkov je omogočeno, vendar se ne smejo spreminjati.

Operacijam smo nastavili »TransactionScopeRequired« v atributu »ServiceBehavior«, ki

določa, ali se mora izvesti operacija v transakcijskem sklopu ali ne. To vrednost

nastavimo s »true« ali »false«.

Slika 10 Nastavitev transakcije storitvam

V WCF ogrodju samo TCP, IPC in WS povezave podpirajo transakcije. Prvi dve povezavi

nista interoperabilni, saj omogočata komunikacijo znotraj .NET ogrodja. Za implementacijo

transakcije smo uporabili »wsHttpBinding«. Povezavi smo morali nastaviti atribut

»transactionflow« na vrednost »true« in to nastavitev povezati s končno točko z atributom

»bindingConfiguration«, kot je prikazano na spodnjih slikah.

Slika 11 Konfiguracija transakcijske končne točke

Slika 12 Konfiguracije transakcije wsHttpBinding vezavi


38

Zgoraj smo nastavili, da je za izvajanje operacij transakcijskega tipa potrebno zgraditi

področje, znotraj katerega se bodo izvedle te operacije. Na spodnji sliki je prikazana

zgradba transakcijskega sklopa na strani odjemalca.

Slika 13 Prikaz transakcijskega sklopa na odjemalcu

8.2 Implementracija WCF REST storitve

WCF ogrodje nam od verzije 3.5 nudi podporo za implementacijo REST storitev. Z

imenskim področjem using System.ServiceModel.Web; vključimo podporo za

oblikovanje REST storitev. Pri oblikovanju REST storitev nam WCF ne zagotavlja

standardov za zagotavljanje zanesljivosti, transakcij in varnosti. Z atributom

»WebInvoke«, kateremu nastavljajo lastnosti (format sporočila, metoda HTTP zahteve,

oblika uri naslova) omogočimo, da se operacije kličejo po WCF REST arhitekturnem

modelu. V nastavitveni datoteki REST storitve moramo uporabiti »webHttpBinding«

povezavo in nastaviti obnašanje končne točke, da omogoča HTTP zahteve.

Slika 14 Nastavitev REST spletne storitve v WCF ogrodju


39

Slika 15 Končna točka REST spletne storitve

Slika 16 Nastavitev obnašanja končne točke za

REST spletne storitve

8.2.1 Zanesljivost

REST spletne storitve nimajo protokola za zagotavljanje zanesljivosti prenosa sporočil.

Tako smo morali zanesljivost sporočil implementirati ročno. Za izgradnjo REST spletnih

storitev moramo poznati vire, saj nam sporočajo interakcije. Če dobimo odgovor statusne

http kode 500 ali 404, moramo izvesti različne akcije, kot če dobimo odgovor 200 ali 201.

Razumevanje HTTP protokola in koordiniranje storitev v določenih situacijah nam

zagotavlja predpogoj za izgradnjo zanesljivih spletnih storitev [17]. Implementacija je

potekala tako, da smo v primeru napake vračali ustrezne HTTP statuse in opise napak.

Na odjemalcu pa smo izvajali storitev v try-catch blokovnem stavku in v primeru napake,

ki se je zgodila na REST spletni storitvi, pridobili status kode in opis napake.


40

Slika 17 Zanesljiva REST spletna storitev

8.2.2 Varnost

Za zagotavljanje varnosti pri REST spletnih storitvah na ogrodju WCF smo se odločili za

uporabo OAuth odprtokodne rešitve. Protokol OAuth je standardizacija kombiniranih

pristopov že uveljavljenih industrijskih protokolov, kot so (Google AuthSub, AOL

OpenAuth, Yahoo BBAuth, Flick Api, Amazon Web Services itd.). Vsak izmed teh

protokolov zagotavlja metodo za izmenjavo uporabniških poverilnic z uporabo žetonov.

OAuth je odprti standard za avtorizacijo. OAuth zagotavlja postopek, da odjemalci

dostopajo do virov na strežniku v imenu lastnika vira [19].

Za vpeljavo OAuth avtorizacije smo uporabili obstoječi razred

(»https://oauth.googlecode.com/svn/code/csharp/OAuthBase.cs«) in ga uporabili pri

implementaciji REST spletne storitve. Avtorizacija storitve deluje na način, da odjemalec

zraven zahteve pošlje še dodatne parametre, ki preverjajo avtorizacijo uporabnika. Če se

poslani parametri od uporabnika na spletni storitvi ne ujemajo, nam ta vrne sporočilo, da

je avtorizacija neuspešna. Eden izmed parametrov sestavlja skrivni ključ, ki se pošlje

skupaj z zahtevo do storitve. Avtorizacijska metoda na strani spletne storitve preveri vse

parametre in jih pošlje v OAuthBase razred, ki smo ga pridobili na zgornjem naslovu ter


41

vrne vrednost »true«, v kolikor se prejeti parametri ujemajo, kar nam pove, da je bila

avtorizacija uspešna.

Slika 18 Preverjanje pristnosti na strani REST spletne storitve

8.2.3 Transakcije

V REST spletnih storitvah ni standardnega pristopa, po katerem bi implementirali uporabo

transakcij. Zato smo za izvedbo našega primera vzeli pristop Try-Confirm/Cancel, ki ga je

bilo potrebno implementirati v poslovno logiko [33]. Delovanje takšnega pristopa bomo

prikazali na spodnji sliki.

Ker smo pri REST storitvah omejeni z uporabo določenih metod za dostopanje,

ustvarjanje in posodabljanje virov, smo implementirali transakcije z uporabo POST, PUT

in DELETE zahtevo. Izvajanje transakcij z REST storitvami deluje po principu, da

poskušamo izvesti proces s pošiljanjem POST zahtev, pri čemer vsako zahtevo preverimo

z vračanjem ustreznega odgovora in upravljanjem uspešnega procesa s PUT zahtevami.

Začetno stanje Poskusi Vmesno stanje Potrdi Končno stanje

Napaka

Prekliči


42

V kolikor v tem procesu pride do prekinitve ali napake, se izvajanje nadaljuje v »catch«

stavku, v katerem pobrišemo vse vire, ki so se uspešno izvedli med procesom.

Poskusi ( Try )

POST /narocilo HTTP 1.1

Host: localhost

HTTP 1.1 201 Created

Location: /narocilo/{id}

Potrdi ( Confirm )

PUT /narocilo/ { id } HTTP 1.1

HTTP 1.1 200 OK

Ali

Prekliči ( Cancel )

DELETE /narocilo/ { id } HTTP 1.1

HTTP 1.1 200 OK


43

9 PRIMERJAVA IMPLEMENTACIJE IN MERJENJE REZULTATOV

V tem poglavju bomo opravili merjenje pristopov spletnih storitev, ki smo jih implementirali

v prejšnjem poglavju. Merjenje bomo prikazali tako, da bomo izvajali določene operacije z

REST in SOAP pristopoma ter komentirali rezultate. Moramo poudariti, da obe tehnologiji

vračata in sprejemata XML oblike sporočila. Osredotočili se bomo na velikost poslanih

sporočil, število zahtev ter tehnično zahtevnost in podporo izvedbe implementacije v WCF

ogrodju.

9.1 SOAP in REST merjenje rezultatov

Prvo smo se osredotočili na primerjavo klasičnih SOAP spletnih storitev z vezavo

»basicHttpBinding« in implementacijo REST arhitekturnega sloga z vezavo

»webHttpBinding« v ogrodju WCF. »BasicHttpBinding« vezava nam ne omogoča izvedbe

zanesljivih spletnih storitev in transakcij. Omogoča pa varnost, katere pa zaradi razloga

nismo uporabili, saj jo bomo predstavili v naslednjih meritvah. Spodnji graf nam prikazuje

primerjavo odzivnosti pri veliki in majhni dolžini sporočil na vhodu in izhodu iz operacije. Iz

levega grafa lahko sklepamo, da so za prenos večje količine podatkov nekoliko hitrejše

klasične SOAP storitve. Obe storitvi sta pri manjšem številu zahtev dokaj izenačeni,

vendar vidimo, da REST storitve z številom zahtev prehitijo klasične SOAP storitve. Desni

graf pa prikazuje prenos majhnega sporočila skozi vhod in izhod operacije, v katerem

jasno opazimo, da so REST storitve hitrejše že pri eni zahtevi, saj SOAP sporočila

prenašajo bistveno več podatkov, za razliko od REST spletnih storitev, ki prenašajo zgolj

XML.

Slika 19 Veliko vhodno izhodno sporočilo

Slika 20 Majhno vhodno izhodno sporočilo

Naslednja dva grafa pa prikazujeta odzivnosti spletnih storitev glede na kombinacijo

različne velikosti sporočila. Levi graf prikazuje izvajanje operacije, ki sprejme veliko

sporočilo in vrne manjšega, medtem ko desni graf prikazuje ravno obratno, pri čemer se

0

2000

4000

6000

8000

10000

12000

14000

1 10 30 50

Čas

(ms)

število zahtev

SOAP

REST

0

200

400

600

800

1000

1200

1400

1 10 30 50

Čas

(ms)

število zahtev

SOAP

REST


44

rezultati med grafi zelo razlikujejo. Obe storitvi sta pri desnem grafu zelo podobni. Najprej

so odzivnejše REST storitve, nato skoraj ni večjih razlik med njima, nato pa s povečanjem

števila zahtev obe narasteta, pri čemer je pri številu zahtev petsto razlika med REST in

SOAP storitvijo kar približnih deset sekund.

Slika 21 Veliko vhodno, majhno izhodno

sporočilo

Slika 22 Majhno vhodno, veliko izhodno

sporočilo

9.2 Primerjava izvedbe zanesljivosti in merjenje rezultatov

Pri SOAP spletnih storitvah smo uporabili protokol »WS-ReliableMessaging, ki omogoča

zanesljivost ter nastavili potrebne atribute za aktivacijo. Za REST spletne storitve smo

prikazali in opisali implementacijo zanesljivosti brez uporabe kakšnega protokola.

Zanesljivost smo upravljali z uporabo HTTP odgovorov. Uvedba zanesljivosti pri REST

arhitekturnem stilu je prepuščena nam razvijalcem, saj moramo zanesljivost

implementirati z našo programsko kodo poslovne logike. Naš namen je bil, da

implementiramo zanesljive SOAP in REST spletne storitve. Spodnji graf prikazuje

pošiljanje objekta skozi funkcijo, ki vrača vrednost »true« ali »false« pri spreminjanju

števila zahtevkov. Rezultat nas je presenetil, saj so zanesljive SOAP storitve pri večjem

številu zahtev zelo počasne, REST pa izjemno hitre. Vendar moramo poudariti, da je za

zanesljive REST spletne storitve potrebno uporabiti zgolj HTTP zahteve PUT, GET in

DELETE, saj omogočajo idempotentnost. Implementacija REST zanesljivosti je tako

prepletena s programsko kodo, tako na strani storitve kot tudi odjemalca, za razliko od

SOAP storitev, za katere velja, da zanesljivost samo vključimo.

0

2000

4000

6000

8000

1 10 30 50

Čas

(ms)

število zahtev

REST

SOAP

0

10000

20000

30000

40000

1 10 30 50 200

Čas

(ms)

število zahtev

REST

SOAP


45

Slika 23 Graf prikazuje čas odziva zanesljivih storitev pri pošiljanju podatkov in različnem številu

zahtev.

Spodnji graf prikazuje pridobivanje večjega števila objektov, pri čemer lahko zopet

razberemo, da SOAP storitve strmo naraščajo pri večjem številu zahtev, v primerjavi z

REST spletnimi storitvami.

Slika 24 Graf prikazuje čas odziva zanesljivih storitev pri pridobivanju podatkov in različnem številu

zahtev.

9.3 Primerjava izvedbe transakcij in merjenje rezultatov

Transakcije smo se z uporabo REST pristopa lotili po vzorcu Try-Confirm/Cancel, ki ga je

bilo potrebno implementirati v programsko kodo našega odjemalca. Način deluje po

principu transakcije, saj v prvem delu poskušamo s POST zahtevami pošiljati podatke k

naši storitvi. V kolikor med delovnim tokom nastane težava, sprožimo zahtevo DELETE, ki

0

500

1000

1500

2000

2500

3000

3500

4000

4500

1 10 20 30 40 50

Čas

(ms)

število zahtev

REST

SOAP

0

50000

100000

150000

200000

250000

300000

350000

400000

1 10 100

Čas

(ms)

število zahtev

SOAP

REST


46

pobriše vse ustvarjene zahteve znotraj transakcije in tako povrne celoten proces v

začetno stanje. SOAP spletne storitve pa v ogrodju WCF podpirajo protokol »WS-

Transactions«, ki omogoča uvedbo transakcij samo z vključitvijo določenih atributov v

primerjavi z REST storitvami, kjer moramo transakcije implementirati ročno. Spodnji graf

prikazuje izvedbo transakcije z obema spletnima pristopoma in izmerjen čas glede na

določeno število zahtev. Razvidno je, da so SOAP spletne storitve za izvedbo transakcije

potrebujejo dosti več časa, kot za to porabijo REST storitve. Saj vemo, da smo REST

transakcije implementirali ročno, pri SOAP pa uporabili temu namenjen protokol.

Slika 25 Graf prikazuje čas za izvedbo transakcije pri različnem številu zahtev

9.4 Primerjava zagotavljanja varnosti in merjenje rezultatov

Ogrodje WCF nam za SOAP storitve ponuja protokol »WS-Security«, s katerim enostavno

zagotovimo varnost. Odločili smo se, da za avtentifikacijo uporabimo certifikat, ki smo ga

izdelali ročno, ki je tudi najpogostejši način. Certifikat smo morali povezati z odjemalcem

kot tudi s spletno storitvijo. To smo nastavili v nastavitvenih datotekah. Moramo poudariti,

da nam ta zaščita nudi varnost na nivoju transporta, sporočil ali obojega hkrati. Zadnji dve

nam namreč omogočata, da so podatki zaščiteni tudi zatem, ko prispejo na cilj. Zopet nam

SOAP spletne storitve omogočajo, da varnost implementiramo stran od naše programske

kode, kar nam poveča preglednost in se lahko tako osredotočimo zgolj na poslovno

logiko. Pri REST spletnih storitvah pa smo izbrali OAuth protokol za zagotavljanje

varnosti. Implementacijo smo morali izvesti na spletni storitvi in odjemalcu. Na spletni

storitvi smo prožili metodo, ki preverja avtentifikacijo odjemalca. Parametre, ki se pošljejo

za preverjanje avtentifikacije pri vsaki zahtevi, je mogoče hraniti v glavi storitve ali zraven

podatkov, ki se pošljejo preko naslovne vrstice. Spodnji graf prikazuje pridobivanje večje

količine objektov z uporabo varnosti pri obeh spletnih storitvah. Iz grafa je razvidno, da

0

5000

10000

15000

20000

25000

1 10 100 1000

Čas

(ms)

število zahtev

SOAP

REST


47

oba pristopa pričneta strmo naraščati pri večjem številu zahtev. Seveda so SOAP storitve

z uporabo protokola nekoliko počasnejše, vendar moramo omeniti, da so REST storitve

zaščitene samo na nivoju transporta, saj zaščite sporočil ne zagotavlja z OAuth

protokolom.

Slika 26 Prikazuje čas pri zagotavljanju varnega pridobivanja podatkov glede na različno število

zahtev

0

50000

100000

150000

200000

250000

300000

350000

400000

450000

1 10 100 1000

Čas

(ms)

število zahtev

REST

SOAP


48

10 SKLEP

V diplomskem delu smo raziskali in preučili dva pristopa k razvoju spletnih storitev. Sprva

smo opisali storitveno usmerjeno arhitekturo, ki daje osnovna načela k izgradnji storitveno

porazdeljenih sistemov. Nato smo opisali klasične spletne storitve, ki temeljijo na SOAP

protokolu. Poleg klasičnih gradnikov spletnih storitev smo opisali WS.* protokole, ki

zagotavljajo zanesljivost, varnost in transakcije. Ugotovili smo, da je nabor teh dodatnih

specifikacij zelo obsežen.

Predstavili in raziskali smo REST arhitekturni stil, ki temelji na zgradbi svetovnega spleta.

Opisali smo dokumentno orientiran stil, ki temelji na pridobivanju virov, za dostop do virov

pa uporablja URL naslovno vrstico, kar predstavlja enotni vmesnik za REST spletne

storitve. Ugotovili smo, da REST arhitekturni stil nima dodatne podpore za zagotavljanje

varnosti, zanesljivosti in transakcij. Za zagotavljanje teh storitev pa smo podrobneje

spoznali HTTP protokol, dobro prakso razvoja in odprte standarde za zagotavljanje

varnosti.

Spletne storitve SOAP smo implementirali s podporo protokolov in REST spletne storitve

s poznavanjem svetovnega spleta, dobrih praks razvoja in odprtih standardov. Razvili smo

zanesljive, varne in transakcijske spletne storitve z obema spletnima pristopoma. Razen

implementacije porazdeljenih transakcij, ki jih je po mojem mnenju najtežje zagotoviti z

REST spletnimi storitvami, saj smo v našem primeru prikazali le en način, ki pa ne more

zagotoviti vseh vrst transakcij, kot jih lahko zagotovijo SOAP z dodatnimi protokoli.

Dokazali smo, da lahko z REST spletnimi storitvami do neke mere zagotovimo izvedbo

teh funkcionalnosti, ki jih ponujajo SOAP spletne storitve s podporo dodatnih protokolov in

različnih specifikacij.

Na koncu smo izvedli še primerjavo in merjenje rezultatov pošiljanja sporočil med .NET

odjemalcem in obema pristopoma spletnih storitev. SOAP storitve z dodatnimi protokoli so

se v primerjavi z REST spletnimi storitvami in ročno implementacijo dodatnih

funkcionalnosti izkazale za počasnejše. Izmerili smo klasične SOAP spletne storitve in

REST storitve pri izmenjavi različnih velikosti sporočil, števil zahtev, xml oblik sporočila in

ugotovili, da so REST storitve primernejše za pošiljanje manjših sporočil, saj prenašajo le

XML dokument v primerjavi z SOAP storitvami, ki XML ovijejo dokument z dodatnimi

atributi. Pri prenašanju velikih sporočil pa smo ugotovili, da sta si oba pristopa pri

manjšem številu zahtev skoraj izenačena, vendar se REST spletne storitve pri večjem

številu zahtev in prenašanju velike količine podatkov izkažejo za počasnejše. Izmerjeni

rezultati so pokazali, da SOAP spletne storitve z dodatnimi protokoli postanejo

počasnejše.


49

Pri primerjavi smo ugotovili, da imata oba pristopa v podpori svoje pomanjkljivosti in

prednosti. Odločitev o tem, katera je bolj primerna, je odvisna predvsem od našega

namena uporabe spletne storitve. Implementirali smo varnost, zanesljivost in transakcije.

S tem smo dokazali, da implementiranje teh lastnosti ni nemogoče, je le veliko težje kot v

SOAP storitvah. Na koncu lahko rečemo, da REST spletne predstavljajo enakovrednega

tekmeca SOAP storitvam, ki imajo dodatno podporo protokolov. Ker pa gre pri REST

spletnih storitvah za dokaj mlad pristop k spletnim storitvam, lahko pričakujemo, da bodo

nekatere lastnosti, ki jih zdaj implementiramo po najboljših praksah, dobile standard, kar

bi lahko pripeljalo REST spletne storitve še do širšega kroga uporabljivosti.


50

11 VIRI IN LITERATURA

1. K. Gottschalk, S.Graham, H.Kreger, J.Snell IBM System Journal: Introduction to Web

services arhitecture. 2001 Dostopno na:

http://www.deinf.ufma.br/~mario/pos/corba/artigos/gottschalk02ws-arch.pdf [1.7.2013]

2. Alteras J. O'Relly : Architectural Styles for Web Services. 2005 Dostopno

na:http://www.oreillynet.com/xml/blog/2005/03/architectural_styles_for_web_s.html

[2.7.2013]

3. W3Schools, SOAP Tutorial, Dostopno na: http://www.w3schools.com/soap/

[3.7.2013]

4. Simon St. Laurent, Joe Johnson, Edd Dumbbill O'Reilly: Programming Web Services

with XML-RPC.2001 Dostopno na:

http://books.google.si/books?id=l40nvlrjWL0C&printsec=frontcover&hl=sl&source=gbs

_atb#v=onepage&q&f=false [4.7.2013]

5. Eric Newcomer. Understanding Web Services. 2002 Dostopno na:

http://www.google.si/books?hl=sl&lr=&id=M1rADzqjo2cC&oi=fnd&pg=PR13&dq=soap

+rest+benefits&ots=uhTaLeMCUR&sig=sAw3xYYM7q6sT_wcXsDwXChX5Tg&redir_e

sc=y#v=onepage&q&f=false [5.7.2013]

6. W3C. Simple Object Access Protocol(SOAP) 1.2. 2007 Dostopno na:

http://www.w3.org/TR/soap12-part1/ [5.7.2013]

7. Erik Christensen, Francisco Curbera, Greg Meredith, Sanjiva Weerawarana W3C.

Web Services Description Language (WSDL) 1.1. 2001 Dostopno na:

http://www.w3.org/TR/wsdl [6.7.2013]

8. Roberto Chinnici, Jean-Jacques Moreau, Arthur Ryman, Sanjiva Weerawarana W3C.

Web Services Description Language (WSDL) 2.0. 26.Junij. 2007 Dostopno na:

http://www.w3.org/TR/wsdl20/#intro_ws [7.7.2013]

9. Tutorialspoint Uddi tutorial: Uddi element. Dostopno na: http://

www.tutorialspoint.com/uddi/uddi_elements.htm [7.7.2013]

10. Thomas Erl, WS.specifications: Cross-Service Transactions with WS-Atomic

Transaction. Dostopno na: http://www.servicetechspecs.com/ws-atomictransaction

[8.7.2013]

11. Luis Felipe Cabrera, George Copeland, Jim Johnson, David Langworthy MSDN:

Coordinating Web Services Activities with WS-Coordination, WS-AtomicTransaction,

and WS-BusinessActivity Dostopno na: http://msdn.microsoft.com/en-

us/library/ms996526.aspx#wsac_topic5 [9.7.2013]


51

12. Jon Flanders O'Relly: RESTful .NET United States of America 2009 Dostopno na:

http://it-ebooks.info/read/389/ [10.7.2013]

13. IBM Corporation Donald F. Ferguson, Tony Storey Secure, Reliable, Transacted Web

Services: Achitecture and Composition. September 2003 Dostopno na:

http://msdn.microsoft.com/en-us/library/ms996535.aspx [11.7.2013]

14. Microsoft Corporation, BEA Systems, BMC Software. Web Services Federation

Language ( WS-Federation ) Version 1.1. 2006 Dostopno na:

http://specs.xmlsoap.org/ws/2006/12/federation/ws-federation.pdf [6.7.2013]

15. Jon Flanders. MSDN Magazine: SOAP, REST and More. 2009 Dostopno na:

http://msdn.microsoft.com/enus/magazine/dd942839.aspx [25.7.2013]

16. Difference between REST and SOAP WCF Services. Dostopno na:

http://cheydotnetblog.com/2013/01/10/difference-between-rest-and-soap-wcf-services/

[26.7.2013]

17. Jim Webber, Savas Parastatidis, Ian Robinson O'Relly Media: Rest in Practice. 2010

Dostopno na: http://it-ebooks.info/book/393/ [5.9.2013]

18. MSDN. Transaction Isolation Levels. Dostopno na: http://msdn.microsoft.com/en-

us/library/windows/desktop/ms709374(v=vs.85).aspx [19.7.2013]

19. Eran Hammer-Lahav. OAuth: Explaining OAuth. 5.September 2007. Dostopno na:

http://oauth.net/about/] [20.7.2013]

20. Microsoft Corporation MSDN Improving Web Services Security: Chapter 4: WCF

Security Fundamentals. 2009 Dostopno na: http://msdn.microsoft.com/en-

us/library/ff650862.aspx [22.7.2013]

21. Abraham Williams. OAuth wiki. 2010. Dostopno na:

http://wiki.oauth.net/w/page/12238516/FrontPage [23.7.2013]

22. MSDN. WS Reliable Session: Reliable Sessions Overview. 2012 Dostopno na:


23. Wikipedia. Secure Sockets Layer. 2013. Dostopno na:

http://sl.wikipedia.org/wiki/Secure_Sockets_Layer [25.7.2013]

24. Juval Lowy O'Relly: Programming WCF Services 2010. Dostopno na: http://it-

ebooks.info/book/677/ [26.7.2013]

25. Saravana Kumar Wcftutorial: Message Contract. Dostopno na:

http://wcftutorial.net/Message-Contract.aspx [15.7.2013]

26. Saravana Kumar Wcftorial: Data Contract. Dostopno na:

http://wcftutorial.net/Message-Contract-Properties.aspx [15.7.2013]


52

27. Waqas Anwar Ezzy Learning: Introducing Windows Communication Foundation. 2012

Dostopno na: http://www.ezzylearning.com/tutorial.aspx?tid=3154426 [16.7.2013]

28. W3schools. XML Schema Tutorial. Dostopno na:

http://www.w3schools.com/schema/default.asp [7.7.2013]

29. Wikipedia. Web Services Description Language. 2013. Dostopno na:

http://en.wikipedia.org/wiki/Web_Services_Description_Language [8.7.2013]

30. MSDN. What is Windows Communication Foundation. 2012. Dostopno na:


31. Savarana Kumar Wcf tutorial. Introduction to WCF Dostopno na:

http://wcftutorial.net/Introduction-to-WCF.aspx [22.7.2013]

32. MSDN. Configuring Syste-Provided Bindings. 2012. Dostopno na:


33. Cesare Pautasso, Guy Pardon Transactions for the REST of us. 2012. Dostopno na:

http://www.inf.usi.ch/faculty/pautasso/talks/2012/soa-cloud-rest-tcc/rest-tcc.html#/title

[26.7.2013]

34. Mike Liu WCF 4.5 Multi-Layer Services Development with Entity Framework, 3rd

Edition. 2012. Dostopno na: http://it-ebooks.info/book/1511/ [2.7.2013]


53


54


55

Documents

Primerjava pristopov k razvoju spletnih storitev z ...WCF – Windows Communication Foundation HTTP – Hypertext Transfer Protocol WS – Web Services WSDL –Web Service Description