ăde e learning șși curriculăe content pentru învățământul...

Platformă de e‐learning și curriculă e‐content g șpentru învățământul superior tehnic

Instrumente pentru Dezvoltarea Programelorp g

10 Instrumente pentru dezvoltarea aplicatiilor orientate spre servicii10. Instrumente pentru dezvoltarea aplicatiilor orientate spre servicii

Platformă de e‐learning și curriculă e‐content pentru învățământul superior tehnic

Dezvoltarea bazată pe servicii

“Driven by the convergence of key technologies and the universal adoption g pof Web services, the service-oriented

enterprise promises to significantly improve corporate agility, speed time-

to market for new products and to-market for new products and services, reduce IT costs, and improve

operational efficiency. “

Newcomer, 2005

2IDP – Instrumente pentru Dezvoltarea Programelor


l lDe la componente la servicii…

Abordarea orientată spre componenteAsamblare din diverse “servicii” – create prin configurare în detrimentul programăriidetrimentul programăriiIBMWebSphere, Sun One Application Server, Microsoft .NET, J2EEDezavantaj: configurarea unei aplicații devine aproape la fel de complicată ca programarea (e.g., deployment descriptor‐ul î l EJB)în cazul EJB)

În acest context devine important conceptul de arhitectură orientată spre servicii (SOA)


orientată spre servicii (SOA)

De la De la ObjectObject--Oriented Oriented lala ServiceService--OrientedOrientedOO Modeling

OO Languages

OO ModelingLanguages &

IDEOO Technology & Framework

Object-OrientedConcept

&

SimulaSmalltalk

Objective C C++

J

UMLCORBAMS .Net

JDK

OO system engineering (OOSE)OO testing

OO maintenanceOO application frameworks

OO databases (OODB)Architecture JavaJDKGCC

OO databases (OODB)OO lifecycle (XP? MDA?)

SO ModelingL & SO Technology & FrameworkLanguages &

IDESO Standards

XMLService BPEL

SO Technology & Framework

SO System Engineering (SOSE?)SO testing (WebStrar?)

UDDI ebXMLWSDLSOAPOWL

Service-OrientedConcept

& Architecture

BPELWSFLXLANGMS. Net

WebSphere

g ( )SO maintenance (re-composition?)

SO frameworks (FERA? SOI?)SO databases

(Ontology DB, SODB?)SO Lifecycle

4

OWL SO Lifecycle (MDA, [re-]composition)


Arhitecturi orientate pe servicii (SOA – Service Oriented Architectures) [WS05]

Tendinţe în ultimii ani în industria IT: colaborarea, partajarea datelor şi resurselorstructurarea aplicaţiilor mari în sub‐blocuri care să poata fireutilizate

Arhitectura orientată pe servicii – componente:Furnizorii de servicii (Service Providers)U ili ii d i ii (S i R )Utilizatorii de servicii (Service Requestors)Broker‐ii (Service Brokers)



A hi O i ă S i iiArhitectura Orientată pe Servicii

Modalitate de dezvoltare a sistemelor distribuite în care l i ii d lcomponentele sunt servicii stand‐alone

Serviciile se pot executa pe diverse staţii ale unor provideri de servicii diferiţiservicii diferiţi

Protocoale standardizate pentru suportul comunicaţiei între servicii şi schimbului de informaţiiş ţ



A hi i O i S i iiArhitecturi Orientate pe Servicii

(UDDI)

Serviceregistry

Find Publish

Servicerequestor

Serviceprovider

Servicerequestor providerBind (SOAP)

(WSDL)



SOA C i i iSOA – Caracteristici

Interoperabilitate între diferite platforme şi limbaje de p p ş jprogramare

Blocurile funcţionale sunt încapsulate în componente care funcţionează ca servicii

Separarea interfeţelor de implementare

În cazul aplicaţiilor complexe, controlul fluxului de execuţie(workflow) este separat de servicii

Serviciile pot fi adăugate dinamic

Corespondenţa dintre interfeţe şi implementări se


realizează prin fişiere de configurare şi poate fi adaptată


C i iil b?Ce sunt serviciile web?

Aplicaţii (componente) care oferă funcţionalităţi în Internet şicomunică prin mesaje standardizate XMLp j

Auto‐descriere (self‐describing): interfeţe publice descrise în limbajul WSDL

Sunt utilizate de către alte aplicaţii, nu de către persoane

Pot fi publicate în cataloage pentru a fi descoperite de cătreli iclienţi

Implementează o arhitectură orientată pe servicii



De ce servicii web?

Faţă de RPC/RMI/CORBA, au avantajul standardizării

I t bilit t Interoperabilitate

Standarde şi protocoale deschise

Sunt bazate pe HTTP: eliminarea problemelor legate de firewall‐uri

Oferă o soluţie în care componentele sunt slab cuplate –specifică programării distribuite



Unde găsim servicii web? http://www.xmethods.net – listă de servicii web disponibile public

http://aws.amazon.com – servicii web oferite de Amazon

…



A j SOAAvantaje SOA

Serviciile pot fi furnizate local sau pot fi furnizate de către provideri externi

Serviciile pot fi independente de limbaj

I tiţi î i t l l t fi tă Investiţia în sistemele legacy poate fi conservată

Interoperabilitatea este facilitată prin schimbul simplificat de i f ţiiinformaţii



Stiva de protocoale pentru servicii web

Descoperirea serviciilor (UDDI)

Catalog pentru servicii web

M j XML (XML RPC

Descrierea serviciilor(WSDL)

(UDDI)

Codificarea mesajelor in

Nivelul transport (HTTP, FTP JMS )

Mesaje XML (XML-RPC, SOAP)

esaje oformatul XMLDescrierea interfetei

publice a serviciilor

FTP, JMS, …)

Transportul mesajelor intre


aplicatii


Protocoale şi tehnologii de bază pentru serviciiProtocoale şi tehnologii de bază pentru serviciiweb (1) XML (Extensible Markup Language)

limbaj generic care poate fi utilizat pentru a reprezentaorice tip de conţinut într‐un mod structuratorice tip de conţinut într‐un mod structuratconţinutul este separat de modul de prezentare

SOAP (Simple Object Access Protocol) SOAP (Simple Object Access Protocol)

protocol prin care un client poate invoca operaţii ale unuiserviciu aflat la distanţăţindependent de platformă, de caracteristicile reţelei şi de limbajele de programare


mesajele transmise sunt în format XML


P t l i t h l ii d b ă t i iiProtocoale şi tehnologii de bază pentru serviciiweb (2)

WSDL (Web Services Description Language)

limbaj bazat pe XML, pentru descrierea interfeţei oferitelimbaj bazat pe XML, pentru descrierea interfeţei oferitede un anumit serviciudescrierea WSDL este publicată de furnizorul de serviciipentru a specifica operaţiile oferite şi parametrii acestorapentru a specifica operaţiile oferite şi parametrii acestoraWSDL este utilizat şi pentru a descrie modul de acces la serviciu

UDDI (Universal Description, Discovery and Integration)

protocol utilizat pentru a se obţine informatii despreservicii web şi furnizorii acestora


servicii web şi furnizorii acestora


Scenariu de utilizare

Web Services Registry WSDL2

WSDL 1

3ServiceProvider

ServiceRequestor SOAP

3

1 – Serviciul este publicat în catalog (registry)

2 – Clientul (requestor) obţine interfaţa publică a serviciului


( q ) ţ ţ p

3 – Clientul (requestor) invocă operaţia şi primeşte rezultatul


S i iScurt istoric

1998‐1999: Microsoft începe să dezvolte standardul SOAP

În acea perioadă XML Schema nu era definitivat

2000: IBM începe să susţină SOAP, extinde specificaţiile şi apareSOAP 1.1

2000 t l d i i b i i ă 2000: apare termenul de serviciu web şi o primă propunerepentru WSDL

După 2001: dezvoltarea standardelor SOAP şi WSDL esteDupă 2001: dezvoltarea standardelor SOAP şi WSDL estecoordonată de W3C



Produse software pentru dezvoltarea serviciilorProduse software pentru dezvoltarea serviciilorweb

Microsoft: suport pentru servicii web inclus în platforma .NET

IBM: a dezvoltat platforma IBM‐SOAP, care apoi a fostpreluată de către Apache devenind Apache SOAP

Apache SOAP a fost urmat de Apache Axis

IBM WebSphere conţine un engine pentru servicii webp ţ g p



Axis – Apache Extensible Integration System

Produs open source pentru programarea serviciilor Produs open‐source pentru programarea serviciilorweb, bazat pe API‐ul JAX‐RPC

I l d i l t d l t i ii Include un server simplu stand‐alone pentru serviciiweb şi un server care poate fi integrat într‐un server de aplicaţii, cum ar fi Apache Tomcatde aplicaţii, cum ar fi Apache Tomcat

Oferă utilitare pentru generarea descrierilor WSDL pebaza claselor Java si de generarea de cod Java pe bazabaza claselor Java si de generarea de cod Java pe bazadescrierii WSDL (java2wsdl, wsdl2java)



Completare standarde de servicii Web

Support (WS-Security, WS-Addressing, ...)

XML technologies (XML, XSD, XSLT, ....)

Process (WS-BPEL)

Service definition (UDDI, WSDL)

Transport (HTTP, HTTPS, SMTP, ...)

Messaging (SOAP)


Transport (HTTP, HTTPS, SMTP, ...)


S i i ă f l ibilăServiciu – componentă refolosibilă Un serviciu poate fi definit ca:O componentă software slab‐cuplată, refolosibilă ce încapsulează funcţionalitate discretă ce poate fi accesată distribuit şi programatic Un serviciu web este un serviciu cedistribuit şi programatic. Un serviciu web este un serviciu ce este accesat folosind protocoale standarde Internet bazate pe XML

O distincţie între un serviciu şi o componentă (definită ca în cazul dezvoltării bazate pe componente) este că

i iil t i d d tserviciile sunt independenteServiciile nu au o interfaţă “necesită”S i iil b ă i i b ă j


Serviciile se bazează pe comunicaţie bazată pe mesaje –mesajele sunt exprimate în XML


ăInteracţiune sincronă


Comunicatie folosind apeluri de metode – interactiune intre componente


U di b f i j XMLUn ordin sub forma unui mesaj XML<starter>

<dish name = “soup” type = “tomato” /> <dish name = soup type = tomato /> <dish name = “soup” type = “fish” /><dish name = “pigeon salad” />

</starter></starter><main course>

<dish name = “steak” type = “sirloin” cooking = “medium” /><dish name = “steak” type = “fillet” cooking = “rare” />dish name steak type fillet cooking rare /<dish name = “sea bass”>

</main><accompaniment>mp m

<dish name = “french fries” portions = “2” /><dish name = “salad” portions = “1” />

</accompaniment>


p

Comunicatie folosind transmitere de mesaje – interactiune intre servicii


bWeb Service Description Language

Interfaţa serviciului este definită conform unei descrieri a serviciului exprimată în WSDL.

Specificaţia WSDL defineşte:Ce operaţii sunt suportate de serviciu şi formatul mesajelor ce sunt trimise şi primite de serviciuCum este accesat serviciul – maparea între interfaţa abstractă şi setul concret de protocoale din spateabstractă şi setul concret de protocoale din spateLocaţia serviciului – exprimată uzual sub forma unui URI (Universal Resource Identifier)


( )


WSDL lăWSDL – prezentare generală

Prin limbajul WSDL un furnizor de servicii poatePrin limbajul WSDL un furnizor de servicii poatespecifica:Numele serviciului web şi informaţii referitoare la adresare

Protocolul şi modul de codificare a datelor folosit la accesareaoperaţiilor

U i f i i l iUn nume pentru interfaţa serviciului

Semnătura operaţiilor, tipurile de date pentru parametri

Un document WSDL poate conţine mai multe fişiere

Pentru a referi alte fişiere care fac parte din document


ş pse utilizează elementul import


fStructura unei specificaţii WSDL

D fi iti WSDL d i i Declaratii:

Intro

Definitie WSDL de serviciu

XML namespace

Declaratii:

Interfata abstractaTypeInterfaceMessage

Implementareconcreta

Message

BindingEndpointp



l dComponentele unei descrieri WSDL

Tipuri (elementul types)Definiţii pentru tipurile de date utilizate în document

Mesaje (elementul message)Definirea structurii diferitelor tipuri de mesaje care apar în comunicareUn mesaj are una sau mai multe părţi de tipuri definiteUn mesaj are una sau mai multe părţi de tipuri definite prin types

Port typeypUn set de definiţii ale unor operaţii abstracte(interfeţe)Operation elementul prin care se defineşte


Operation – elementul prin care se defineştesemnătura unei operaţii


Componentele unei descrieri WSDL (2)

BindingO specificare concretă a protocolului şi formatului datelorpentru un port typepentru un port type Conţine: numele protocolului, stilul invocaţiei, modul de codificare

PortSpecificat printr‐un binding şi o adresă fizică de reţeap p g ş ţ

ServiciuO colecţie de porturi “înrudite”


O colecţie de porturi înrudite


<?xml version="1.0" encoding="UTF-8"?><wsdl:definitions targetNamespace="http://address.jaxrpc.samples"xmlns:apachesoap="http://xml.apache.org/xml-soap"xmlns:impl="http://address.jaxrpc.samples"xmlns:intf="http://address.jaxrpc.samples"xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"xmlns:wsdlsoap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<wsdl:types><schema targetNamespace="http://address.jaxrpc.samples"xmlns="http://www.w3.org/2001/XMLSchema"><import namespace="http://schemas.xmlsoap.org/soap/encoding/"/><complexType name="AddressBean">

<sequence><element name="street" nillable="true" type="xsd:string"/><element name="zipcode" type="xsd:int"/>

</sequence></complexType><element name="AddressBean" nillable="true“type="impl:AddressBean"/>


</schema><import namespace="http://www.w3.org/2001/XMLSchema"/></wsdl:types>


Exemplu – document WSDL [WS05] (2)

<wsdl:message name="updateAddressRequest"><wsdl:message name updateAddressRequest ><wsdl:part name="in0" type="intf:AddressBean"/><wsdl:part name="in1" type="xsd:int"/>

</wsdl:message><wsdl:message name="updateAddressResponse"><wsdl:message name updateAddressResponse ><wsdl:part name="return" type="xsd:string"/>

</wsdl:message><wsdl:message name="updateAddressFaultInfo"><wsdl:part name="fault" type="xsd:string"/>"<wsdl:part name fault type xsd:string />

</wsdl:message>

definitiile de mesaje vor fi utilizate in definitiile de operatii

mesajele sunt definite separat de operatii pentru flexibilitate – mai multe operatii pot referi aceeasi definitie de mesaj



E l d t WSDL [WS05] (3)Exemplu – document WSDL [WS05] (3)<wsdl:portType name="AddressService"><wsdl:operation name="updateAddress" parameterOrder="in0 in1"><wsdl:operation name updateAddress parameterOrder in0 in1 >

<wsdl:input message="intf:updateAddressRequest"name="updateAddressRequest"/>

<wsdl:output message="intf:updateAddressResponse"name="updateAddressResponse"/>name updateAddressResponse />

<wsdl:fault message="intf:updateAddressFaultInfo"name="updateAddressFaultInfo"/>

</wsdl:operation></wsdl:portType></wsdl:portType>

Tipuri posibile de operatii:

• one wayone way

• request-response

• solicit-response


p

• notification


<wsdl:binding name="AddressSoapBinding" type="intf:AddressService"><wsdlsoap:binding style="rpc"

transport="http://schemas.xmlsoap.org/soap/http"/><wsdl:operation name="updateAddress">

<wsdlsoap:operation soapAction=""/><wsdl:input name="updateAddressRequest">

<wsdlsoap:bodyencodingStyle="http://schemas.xmlsoap.org/soap/encoding/"namespace="http://address.jaxrpc.samples" use="encoded"/>

</wsdl:input><wsdl:output name="updateAddressResponse">

<wsdlsoap:bodyencodingStyle="http://schemas.xmlsoap.org/soap/encoding/"namespace="http://address.jaxrpc.samples" use="encoded"/>

</wsdl:output><wsdl:fault name="updateAddressFaultInfo">

<wsdlsoap:bodyencodingStyle="http://schemas.xmlsoap.org/soap/encoding/"namespace="http://address.jaxrpc.samples" use="literal"/>

</wsdl:fault>


</wsdl:operation></wsdl:binding>


Exemplu – document WSDL [WS05] (5)

<wsdl:service name="AddressServiceService"><wsdl:port binding="intf:AddressSoapBinding" name="Address"><wsdlsoap:addresslocation="http://localhost:8080/axis/services/Address"/></wsdl:port></wsdl:service></wsdl:definitions>



I diInstrumente: editor

Cum scriem fişiere WSDL?

De mână: unele editoare au suport special pentru WSDL

Nu le scriem: generare automată (în câteva slide‐uri)g ( )

Editing WSDL files by hand is masochistic Avoid it as much as you Editing WSDL files by hand is masochistic. Avoid it as much as you can



I lidInstrumente: validare

Documentele WSDL pot fi chiar mari (documentul WSDL pentru Amazon E‐Commerce Service are 2432 linii de cod şi pesteAmazon E‐Commerce Service are 2432 linii de cod şi peste 100KB)

Instrumente pentru validarea/analiza documentelor WSDL :p /http://xmethods.net/ve2/Tools.pohttp://www.softwaresecretweapons.com/jspwiki/services/oy-lm-1 3/generator jsp 1.3/generator.jsp



I G WSDLInstrumente: Generare WSDL

Crearea manuală a unui fişier WSDL pentru un serviciu web Crearea manuală a unui fişier WSDL pentru un serviciu web poate fi dificilă şi poate duce uşor la erori

Plecând de la un fişier WSDL, generarea unui client care să ş , ginteracţioneze cu un serviciu reprezintă un task repetitiv

Există toolkituri pentru diverse limbaje de programare ce automatizează atât generarea fişierelor WSDL cât şi generareaautomatizează atât generarea fişierelor WSDL, cât şi generarea codului pe partea clientului



WSDL lki JWSDL toolkit: Java

Axis: http://ws.apache.org/axis/

Construieşte stub, skeleton şi tipuri de date pornind de la WSDL

java org.apache.axis.wsdl.WSDL2Java AWSECommerceService wsdlAWSECommerceService.wsdl

Construieşte WSDL pornind de la codul Javaj h i dl J 2WSDL dljava org.apache.axis.wsdl.Java2WSDL -o wp.wsdl -l "http://localhost:8080/axis/services/WidgetPrice -n"urn:Example6" -p"samples.userguide.example6" "urn:Example6" samples userguide


example6 urn:Example6 samples.userguide.example6.WidgetPrice


WSDL lki P hWSDL toolkit: Python

SOAPpy: http://pywebsvcs.sourceforge.net/py p //py g /

Parsarea unui fişier WSDL:>>> from SOAPpy import WSDLpy p>>> wsdlFile = 'http://webservices.amazon.com/AWSECommerceService/AWSECommerceService.wsdl'>>> server = WSDL.Proxy(wsdlFile)>>> server WSDL.Proxy(wsdlFile)>>> server.methods.keys()[u'SellerListingSearch', u'CartCreate', u'SellerLookup', u'Help', u'TransactionLookup', u'CartAdd' u'ItemLookup' u'MultiOperation'u CartAdd , u ItemLookup , u MultiOperation , u'SimilarityLookup', u'CartClear', u'ListLookup', u'CartModify', u'CustomerContentLookup', u'ListSearch', u'BrowseNodeLookup', u'CartGet', 'S ll Li ti L k ' 'C t C t tS h'


u'SellerListingLookup', u'CustomerContentSearch', u'ItemSearch']


>>> itemSearchM = server.methods['ItemSearch'][ ]>>> for inparams in itemSearchM.inparams:... print inparams.name, inparams.type... body (u'http://webservices.amazon.com/AWSECommerceService/2005-10-05', u'ItemSearch')>>>>>> for outparams in itemSearchM.outparams:... print outparams.name, outparams.type... body (u'http://webservices.amazon.com/AWSECommerceService/2005-10-05', u'ItemSearchResponse')u ItemSearchResponse )>>> result = server.ItemSearch({'body': {'SubscriptionId': 'xxxxxxxxxxxxxxxxxxxx', 'SearchIndex': 'Books', 'Request' : {'SearchIndex': 'Books', 'Title': 'restaurant end universe'}}})>>> result.Items.TotalPages2>>> result['Items'].TotalResults'18'

>>> result.Items.Item[0]<SOAPpy.Types.structType Item at -1214384084>: {'ItemAttributes': <SOAPpy.Types.structType ItemAttributes at -1214386100>: {'Title': 'The Restaurant at the End of the Universe', 'ProductGroup': 'Book', 'Author': 'Douglas Adams'}, 'ASIN': '0345391810', 'DetailPageURL': 'http://www.amazon.com/exec/obidos/redirect?tag=ws%26link_code=sp1%26camp=2025%26creative=165953%26path=http://www amazon com/gp/redirect html%253fASIN=0345391810%252


eative 165953%26path http://www.amazon.com/gp/redirect.html%253fASIN 0345391810%2526tag=ws%2526lcode=sp1%2526cID=2025%2526ccmID=165953%2526location=/o/ASIN/0345391810%25253FSubscriptionId=xxxxxxxxxxxxxxxxxxxx'}


lIngineria serviciilor

Procesul de dezvoltare de servicii pentru refolosire în aplicaţiile orientate spre servicii

Serviciul trebuie proiectat ca o entitate abstractă refolosibilă în diverse sisteme

PresupuneIdentificarea serviciului candidatProiectarea serviciuluiProiectarea serviciuluiImplementarea serviciului



Procesul de inginerie orientată pe procese



Construcţia prin compunere



Exemplu de orchestraţieExemplu de orchestraţie



Tendinţe de evoluţie a serviciilor web



Referinţe

[WS05] http://publib-b.boulder.ibm.com/abstracts/sg246461.html?OpenWebSphere Version 6 Web Services Handbook 2005WebSphere Version 6 – Web Services Handbook, 2005

• http://www-128.ibm.com/developerworks/webservices/library/ws-peer1.html?dwzone=ws – The Web Services (r)evolution

• http://www.w3.org/2002/ws/ - pagina oficială pentru servicii web a W3C

[JW03] http://www javaworld com/javaworld/jw 10 2003/jw 1003• [JW03] http://www.javaworld.com/javaworld/jw-10-2003/jw-1003-wsstyles.html?page=1 – Keep up with the Web Services Styles

• http://www.xml.com/pub/a/2001/04/04/soap.html - A Brief History of SOAP



Sumar

Servicii webArhitecturi orientate pe serviciiArhitecturi orientate pe servicii

Standarde, protocoale şi produse software pentruservicii webservicii web



Slide‐uri suplimentare



SOAP – Caracteristici generale

Reprezintă principalul mod de comunicaţie între componentelearhitecturii bazate pe servicii

Independent de protocolul de transport

Clienţii SOAP nu deţin referinţe la obiectele la distanţă ca în Clienţii SOAP nu deţin referinţe la obiectele la distanţă, ca în cazul RMI – deci nu există restricţii pentru limbajul de implementare



Componentele unui mesaj SOAP

Anvelopa mesajului:elementul de la nivelul cel mai înaltfuncţionează ca un container pentru mesaj

Zero sau mai multe antete (header‐e)conţin informaţii de controlspecifică cine şi cum va prelucra mesajul

( ) Corpul mesajului (body)specifică operaţiile care trebuiesc realizate



Exemplu – cerere HTTP ce conţine un mesaj SOAPExemplu – cerere HTTP ce conţine un mesaj SOAP [WS05]

POST /webapp/servlet/rpcrouter HTTP/1.1Host: www.messages.comContent-Type: text/xml; charset="utf-8"Content-Length: nnnnSOAPAction: "“

<soapenv:Envelopexmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Body>

<ns1:getMessage xmlns:ns1="urn:NextMessage"soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<UserID xsi:type="xsd:string">JDoe</UserID><Password xsi:type="xsd:string">0JDOE0</Password></ns1:getMessage>


</soapenv:Body></soapenv:Envelope>


Exemplu – răspuns la cererea HTTP [WS05]

HTTP/1 1 200 OKHTTP/1.1 200 OKContent-Type: text/xml; charset="utf-8"Content-Length: nnnn

< E l<soapenv:Envelopexmlns:soapenv="..." xmlns:xsd="..." xmnls.xsi="..."><soapenv:Body>

<ns1:getResponseMessage xmlns:ns1="urn:NextMessage"soapen encodingSt le "http://schemas xmlsoap org/soap/encoding/">soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

<return xsi:type="xsd:string">Call mom!</return></ns1:getResponseMessage>

</soapenv:Body></soapenv:Envelope></soapenv:Envelope>



URN – Unified Resource Name

Identificator unic al unui serviciu în cadrul unui server

Numele este reprezentat sub forma unui URI (Uniform Resource Identifier)

Restul informaţiilor de adresare sunt dependente de protocolul de transport



H d SOAPHeader‐e SOAP Reprezintă un mecanism de a extinde mesajele SOAP într‐un mod des‐centralizatmod des‐centralizat

Atributul mustUnderstand – specifică dacă furnizorul de servicii trebuie să implementeze semantica elementului:p

<thens:qos xmlns:thens="someURI" SOAP-ENV:mustUnderstand="1">3

• Atributul actor: specifică destinatarul mesajului

3</thens:qos>

Atributul actor: specifică destinatarul mesajului• Alte utilizări pentru header-e: informaţii de autentificare,

semnături digitale, diverse alte extensii ale standardului SOAP ( WS Add i )


SOAP (ex: WS-Addressing)


C l i j SOAPCorpul unui mesaj SOAP Conţine cel puţin:Numele mesajuluiO referinţă (URN) la instanţa serviciuluiParametri conţinând valori şi eventual tipuri

Elementele faultPentru raportarea erorilorConţin: un cod de eroare (faultcode), o descriere a erorii(faultstring), opţional alte detalii şi un câmp faultactorpentru a specifica sursa erorii



Ti i d d SOAPTipuri de date SOAP Tipuri simple (int, string, boolean, date, …) – definite în XML Schema

Tipuri compuse: structuri, tablouri

Exemplu – tablou de structuri [WS05]:Exemplu tablou de structuri [WS05]:

<ns1:getSubscribers xmlns:ns1="urn:SubscriberList“ SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"><SOAP ENC:Array SOAP ENC:arrayType="xxx:Subscribers[2]"><SOAP-ENC:Array SOAP-ENC:arrayType="xxx:Subscribers[2]"><Subscribers>

<UserID xsi:type="xsd:string">JDoe</UserID><Password xsi:type="xsd:string">0JDOE0</Password>

</Subscribers></Subscribers><Subscribers>

<UserID xsi:type="xsd:string">MDoe</UserID><Password xsi:type="xsd:string">0JMDOE0</Password>

</Subscribers>


</Subscribers></SOAP-ENC:Array></ns1:getSubscribers>


Stiluri de comunicaţie SOAP

Document (orientat pe mesaj)model de nivel mai jos, cu foarte puţine restricţiiflexibil, oferă nivelul maxim de interoperabilitateeste stilul recomandat de către standardele recente

RPCpentru invocări sincrone de operaţii care întorc rezultateadaugă elemente suplimentare pentru a simula un apel de funcţie



Exemple – stiluri de comunicatie

<out:getNoteResponse xmlns:out="urn:outline.demo"><out:note key="000000000B" >

Stilul document:

<out:note key 000000000B ><out:content>test</out:content>

</out:note></out:getNoteResponse>

Stilul RPC:

<tns:matchNoteAndNote xmlns:tns="urn:outline.demo"><in0 xsi:type="xsd:string">0000000000</in0><in1 xsi:type="xsd:string">000000000B</in1>

</tns:matchNoteAndNote>


</tns:matchNoteAndNote>


M d i d difi d l ( di )Moduri de codificare a datelor (encoding)

Literal – urmează exact o definiţie XML Schema

SOAP – urmează regulile de codificare descrise în specificaţiaSOAP urmează regulile de codificare descrise în specificaţiaSOAP; se pot produce referinţe la tipuri de date definite în mesaj

Teoretic este posibilă orice combinaţie între tip de comunicare şimod de codificare

Practic: se utilizează de obicei fie stilul RPC şi codificarea SOAP, fie stilul document şi codificarea literalfie stilul document şi codificarea literal



Servicii REST



REST

REpresentational State Transfer

Client‐server

Stateless

Cached

Uniform interface

Layered system

(Code on demand)



Motivation What is Web 2.0?

Commonly associated with web applications that facilitate interactive informationCommonly associated with web applications that facilitate interactive information sharing, interoperability, user‐centered design and collaboration on the WWW1.Usually connected with the notions of read‐write web, social web but also programmable web2.p g

Typical characteristics of Web 2.0 applicationsUsers can produce and consume data on a Web 2.0 siteWeb is used as a participation platformUsers can run software applications entirely through a Web browserData and services can be easily combined to create mashups

1


1 Taken from http://en.wikipedia.org/wiki/Web_2.0

2 http://www.programmableweb.com


MotivationMotivationExamples



Motivation

F b k I l f f i f i l k Facebook ‐ Internet platform for creation of social networksMore than 400 million active users 50% of our active users log on to Facebook in any given day More than 35 million users update their status each day More than 60 million status updates posted each day More than 3 billion photos uploaded to the site each month p pMore than 5 billion pieces of content (web links, news stories, blog posts, notes, photo albums, etc.) shared each week More than 3.5 million events created each month More than 3 million active Pages on FacebookMore than 1.5 million local businesses have active Pages on Facebook



Motivation

Wikipedia ‐ Free Online Encyclopedia3,315,577 Articles (English Wikipedia)1

12,485,100 registered users1

Cl h i bi d ith h i t lliClever mechanisms combined with human intelligenceHigh quality articlesSelf‐organized controlSemi‐openess



MotivationMotivationExample Mashup: Housingmaps.com



lConceptual Overview

Requirements supported by REST‐enabled systems stem from the requirements addressed by any system following Web architecture1: Simplicity

•Low barrier of entry, fast adoption of Web APIs.Extensibility

•Allowing growth and flexibility.Distributed hypermedia

•Relying on the established concepts of hyperlinked content.Scalability at the Web levelScalability at the Web level

•Should rely on technologies/protocols supporting scalable solutions.Independent deployment

C i t f ld d


•Coexistence of old and new


Conceptual OverviewConceptual OverviewRequirements ‐ Simplicity

Participation in the creation of information is voluntaryLow entry‐barrier is necessary

Hypermedia has simple and general user interfaceTh i t f i d f ll i f tiThe same interface is used for all information sourcesHypermedia relationships are flexible – unlimited structuring Users can be guided through reading by manipulating linksSimple queries are incorporated for searching purposesp q p g p p

Partial availability of the overall system doesn’t prevent the authoring of the contentHypermedia authoring language is simple and capable of using existing toolsUnavailability of referenced information allows further authoringReferences to the content are easily exchanged


Communication can be viewed and interactively tested by developers


Conceptual OverviewConceptual OverviewRequirements ‐ Extensibility

User requirements change over time just as society does

The system must avoid locking to the deployed solutionsThe limitations must be easily resolvable

A system with the goal to be long lived as the Web must be prepared for A system with the goal to be long‐lived as the Web must be prepared for change.



Conceptual OverviewConceptual OverviewRequirements – Distributed Hypermedia

Hypermedia includes application control information embedded within the presentation of information.

Distributed hypermedia allows the content and control information to be stored at remote locations.Transfer of large amounts of data is needed while a user interacts with contentTransfer of large amounts of data is needed while a user interacts with content.

Users are quite sensitive to perceived latencyTime between link selection and information renderingInformation is distributed across the global networkNetwork interactions must be minimized.


Network interactions must be minimized.


Conceptual OverviewConceptual OverviewRequirements – Internet Scale

The Web is Internet‐scale distributed hypermedia system

Th W b h bl f hi l bili The Web must answer to to the problem of anarchic scalabilityThe constituent systems are not centrally managed neither have a common goalParts must continue to operate even under unanticipated load, or when given malformed or maliciously constructed data.

Security becomes a significant concerny gMultiple trust boundaries may be present in any communicationAdditional authentication must be in place before trust can be givenAuthentication may degrade scalability


Authentication may degrade scalability


Conceptual OverviewConceptual OverviewRequirements – Independent Deployment

Systems must be prepared for gradual and fragmented changeOld and new implementations may co‐exist without preventing the new implementations to achieve their full potential.

Existing design decisions must acknowledge future extensions.

Old systems must be easily identifiableLegacy behavior can be encapsulated without impacting newly deployed subsystemsy

The architecture must allow deployment of new elements in a partial and iterative fashion


iterative fashionNot possible to enforce deployment order.


Conceptual OverviewConceptual OverviewRepresentational State Transfer (REST)

R t ti l St t T f (REST) Representational State Transfer (REST)A style of software architecture for distributed hypermedia systems such as the World Wide Web.

REST is basically client/server architectural styleRequests and responses are built around the transfer of "representations" of "resources".

Architectural style meansSet of architectural constraints.Not a concrete architecture.Not a concrete architecture.An architecture may adopt REST constraints.

HTTP is the main and the best example of a REST style implementation


But it should not be confused with REST


Conceptual OverviewConceptual OverviewMajor REST principles

Information is organized in the form of resourcesgSources of specific information,Referenced with a global identifier (e.g., a URI in HTTP).

Components of the network (user agents and origin servers) communicate via a p ( g g )standardized interface (e.g., HTTP)exchange representations of these resources (the actual documents conveying the information).

Any number of connectors (e.g., clients, servers, caches, tunnels, etc.) can mediate the request, but each does so without being concern about anything but its own requestan application can interact with a resource by knowing two things: the identifier of thean application can interact with a resource by knowing two things: the identifier of the resource and the action requiredno need to know whether there are caches, proxies, gateways, firewalls, tunnels, or anything else between it and resourceThe application needs to understand the format of the information (representation)


The application needs to understand the format of the information (representation) returned.


Conceptual OverviewConceptual OverviewREST Architectural Constrains (1)

Client‐serverSeparation of concerns

• Clients are separated from servers by a uniform interface. Networking

•Clients are not concerned with data storage, which remains internal to each g ,server, so that the portability of client code is improved. Servers are not concerned with the user interface or user state, so that servers can be simpler and more scalable.

Independent evolution•Servers and clients may also be replaced and developed independently, as long as the interface is not altered.




Stateless communicationScalability, reliability

•No client context being stored on the server between requests. Each request from any client contains all of the information necessary to service the request.

Resources are conversationally stateless•Any conversational state is held in the client.

Uniform InterfaceSimplicity (vs. efficiency)Large‐grained hypermedia data transferExample: Create, Retrieve, Update, Delete




CachingEfficiency, scalability

•Well‐managed caching partially or completely eliminates some client‐server interactions, further improving scalability and performance.

Consistency issues•As on the World Wide Web, clients are able to cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable or not, to prevent clients reusing stale or inappropriate data in response to further p g pp p prequests.

Code‐on‐demandExtending client functionality

•Servers are able to temporarily extend or customize the functionality of a client by transferring to it logic that it can execute. Examples of this may i l d il d t h J l t d li t id i t h


include compiled components such as Java applets and client‐side scripts such as JavaScript.


Conceptual OverviewConceptual OverviewRESTful Web Service definition

A RESTful Web service is:A set of Web resources.Interlinked.Data‐centric, not functionality‐centric.Machine‐oriented.

Like Web applications but for machines Like Web applications, but for machines.

Like WS‐*, but with more Web resources.


WS-* stands for a variety of specifications related to SOAP-based Web Services.


Conceptual Overview

listEntries()

Conceptual OverviewWS- vs REST: A quick comparison

WS‐collectionservice

listEntries()addEntry()getEntry()

d l t E t ()deleteEntry()updateEntry()

collectionlistEntries()addEntry()

RESTful

entryentry

y()

getEntry()deleteEntry()


yentryentrydeleteEntry()

updateEntry()


Conceptual OverviewConceptual OverviewWS- vs REST: A quick comparison

A SOAP service (WS‐) has a single endpoint that handles all the operations – therefore it has to have an application‐specific interfaceinterface.

A RESTf l i h b f (th ll ti h A RESTful service has a number of resources (the collection, each entry), so the operations can be distributed onto the resources and mapped to a small uniform set of operations.



Conceptual OverviewConceptual OverviewHigh-level example: hotel booking

Hotel booking service

searchhoteli f

service description

searchresults

info

description

payment

confirmationmy bookings

p y



Conceptual Overview

H l b ki kfl

Conceptual OverviewHigh-level example: hotel booking

Hotel booking workflow1. Retrieve service description2 S b i h i i di d i i2. Submit search criteria according to description3. Retrieve linked details of interesting hotels4 S b it t d t il di t l t d t4. Submit payment details according to selected rate

description5. Retrieve confirmation of booking5. Retrieve confirmation of booking

2b R i li f ' b ki


2b.Retrieve list of user's bookings


Conceptual Overview

search(date, city) li t f h t l & t

Conceptual OverviewHigh-level example: hotel booking

hypermedia -> operations


searchresults

hotelinfo


searchresults

hotelinfo

list of hotels & rates

getHotelDetails(hotel)

hotel detailsservice

description

results


payment

service description

results


payment

reserve(rate, creditCard) confirmationID

confirmationmy bookings confirmationmy bookingsgetConfirmationDetails(confID)

confirmation details

li M B ki ()listMyBookings() list of confirmationIDs

nouns vs. verbs



h lTechnologies

Todays’s set of technologies, protocols and languages used to apply RESTfulparadigm:HTTP as the basisXML and JSON for data exchangeAJAX for client‐side programming (e.g. browser)

There exists an attempt to develop WSDL‐like definition language for describing RESTful servicesdescribing RESTful servicesWeb Application Description Language (WADL)


ăde e learning șși curriculăe content pentru învățământul...

Documents

Transcript of ăde e learning șși curriculăe content pentru învățământul...