WEB SERVICES & APIS. Electronic Transactions. by Koussouris S., Lampathaki F., Askounis D.

WEB SERVICES & APIS Electronic Transactions by Koussouris S., Lampathaki F., Askounis D.

WEB SERVICES

Reality Today

Service-oriented Architecture Υποστηρίζει το σχεδιασµό των εφαρµογών µε επίκεντρο τις υπηρεσίες Τι είναι οι υπηρεσίες? Αναπαραστάσεις πραγµατικών προγραµµάτων, βάσεων δεδοµένων ή διαδικασιών, που: καθορίζονται σε σχέση µε το τι κάνουν, προσδιορίζονται στα πλαίσια µηνυµάτων που ανταλλάσσονται είναι προσπελάσιµες µέσω δικτύου

Example of Service-oriented Architecture To compact-disc (CD) και το µηχάνηµα αναπαραγωγής CD (CD player), το οποίο παρέχει την υπηρεσία της αναπαραγωγής του ήχου του CD Η SOA µας παρέχει τη δυνατότητα να αντικαταστήσουµε ένα µηχάνηµα αναπαραγωγής CD µε ένα άλλο, διαφορετικού κατασκευαστή και διαφορετικών προδιαγραφών, όπως ένα φορητό µηχάνηµα αναπαραγωγής CD, και η υπηρεσία που προσφέρεται σε κάθε περίπτωση να παραµένει η ίδια: η αναπαραγωγή του CD πραγµατοποιείται, το µόνο που αλλάζει είναι η ποιότητά της. Όµως εάν υποθέσουµε ότι το συγκεκριµένο σύστηµα ακολουθεί κάποια άλλη αρχιτεκτονική, για παράδειγµα την αντικειµενοστραφή, κάθε CD θα είχε δικό του µηχάνηµα αναπαραγωγής, από το οποίο δεν θα µπορούσε να αποσπαστεί.

Web Service «Διαδικτυακή Υπηρεσία ονοµάζεται µια εφαρµογή λογισµικού, που αναγνωρίζεται από ένα µοναδικό ενιαίο προσδιοριστικό πόρου URI (Uniform Resource Identifier). Το περιβάλλον διεπαφής (interfaces) και τα σηµεία πρόσδεσης (bindings) πρέπει να είναι καλά ορισµένα, να περιγραφούν και να ανακαλυφθούν ως δεδοµένα XML (artifacts). Μια διαδικτυακή υπηρεσία υποστηρίζει απ ευθείας δοσοληψίες µε άλλους πράκτορες µε ανταλλαγή µηνυµάτων βασισµένων σε XML µέσω πρωτοκόλλων του διαδικτύου.» World Wide Web Consortium

Πρακτικά πώς αντιλαµβανόµαστε µια Διαδικτυακή Υπηρεσία? Αποτελεί διαδικτυακή υπηρεσία κάθε υπηρεσία που παρέχεται µέσω διαδικτύου, όπως για παράδειγµα η on-line υπηρεσία κράτησης δωµατίων που παρέχεται από µια ξενοδοχειακή επιχείρηση µέσω του εξυπηρετητή της εταιρείας στην επίσηµη ιστοσελίδα της? ΟΧΙ (ΑΠΑΡΑΙΤΗΤΑ)... Ταξιδιωτικό Γραφείο Internet Ξενοδοχείο Web Site Η ύπαρξη µιας διαδικτυακής υπηρεσίας κράτησης δωµατίων θα έδινε το δικαίωµα σε όλα τα ενηµερωτικά τουριστικά sites, αλλά και συνεργαζόµενες επιχειρήσεις να κλείνουν αυτόµατα δωµάτιά της. Ταξιδιωτικό Γραφείο Ξενοδοχείο 7/6/2004 172, Internet 286 Web Service «διαθέσιμα δωμάτια»

Βασικά Χαρακτηριστικά Διαδικτυακών Υπηρεσιών Ανεξαρτησία από την πλατφόρµα υλοποίησης, χωρίς να απαιτείται καµία αλλαγή στον µηχανισµό του συστήµατος Χρησιµοποίηση ανοικτών προτύπων και ευρέως διαδεδοµένων πρωτοκόλλων, όπως XML (extensible Markup Language) και HTTP (HyperText Transfer Protocol) Γρήγορη ανάπτυξη και µειωµένο κόστος ολοκλήρωσης Συσσώρευση τελικών (back-end) υπηρεσιών Δηµοσίευση των πληροφοριών που τις αφορούν, οπότε η εύρεση και η χρήση τους γίνονται ταχύτατα Επαναχρησιµοποίηση

Αρχιτεκτονική Διαδικτυακών Υπηρεσιών

Πλεονεκτήµατα Web Services Ευκολότερος χειρισµός δεδοµένων Απλότητα πρωτοκόλλου επικοινωνίας Απλότητα υποδοµής Ευκολία στην επικοινωνία Διαλειτουργικότητα και ευκολία ανάπτυξης νέων εφαρµογών Αλληλεπίδραση µεταξύ υπηρεσιών σε οποιαδήποτε πλατφόρµα και οποιαδήποτε γλώσσα προγραµµατισµού Χαλαρή συνδεσιµότητα µεταξύ εφαρµογών Προσαρµογή ήδη υπαρχουσών εφαρµογών στις µεταβαλλόµενες επιχειρησιακές συνθήκες και ανάγκες των πελατών Μικρό κόστος δηµιουργίας και χρήσης

Web Services Standards stack Επιπλέον Πρότυπα

Πρωτόκολλο SOAP Το Simple Object Access Protocol (SOAP) ξεκίνησε µε πρωτοβουλία του W3C το 1999. Καθορίζει κυρίως τα ακόλουθα: Ένα message format για µονόδροµη επικοινωνία που περιγράφει πώς ένα µήνυµα δοµείται σε XML έγγραφο Μια περιγραφή πώς ένα SOAP µήνυµα µεταδίδεται στο διαδίκτυο (χρησιµοποιώντας το HTTP) ή µέσω e-mail (χρησιµοποιώντας το SMTP) Ένα σύνολο από κανόνες (SOAP Encoding Rules) για την επεξεργασία ενός SOAP µηνύµατος, όπως ποια τµήµατα των µηνυµάτων µπορούν να διαβαστούν από ποιούς και ποια πρέπει να είναι η αντίδραση εάν το περιεχόµενο δεν είναι κατανοητό

Δοµή του SOAP Μηνύµατος Το SOAP βασίζεται σε ανταλλαγές µηνυµάτων Τα µηνύµατα θεωρούνται ως φάκελοι στους οποίους η εφαρµογή εσωκλείει τα δεδοµένα που αποστέλλει Κάθε µήνυµα έχει 2 κύρια µέρη: επικεφαλίδα (header) και κυρίως τµήµα (body), που µπορούν να χωριστούν περαιτέρω σε τµήµατα Η επικεφαλίδα είναι προαιρετική και το κυρίως τµήµα υποχρεωτικό. Η χρήση και των 2 εξασφαλίζει ότι το κυρίως τµήµα αφορά δεδοµένα της εφαρµογής, ενώ η επικεφαλίδα δεδοµένα «υποδοµής» για την αυθεντικοποίηση, την ασφάλεια και την τήρηση αρχείου. Σε περίπτωση που συµβεί κάποιο λάθος κατά τη διάρκεια της επικοινωνίας το µήνυµα περιέχει το στοιχείο Fault µέσα στο κυρίως τµήµα

Παράδειγµα ενός SOAP Μηνύµατος <?xml version='1.0'?> <env:envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:header> <m:reservation xmlns:m="http://travelcompany.example.org/reservation" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustunderstand="true"> <m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference> <m:dateandtime>2001-11-29t13:20:00.000-05:00</m:dateandtime> </m:reservation> <n:passenger xmlns:n="http://mycompany.example.com/employees" env:role="http://www.w3.org/2003/05/soap-envelope/role/next" env:mustunderstand="true"> <n:name>åke Jógvan Øyvind</n:name> </n:passenger> </env:header> <env:body> <p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel"> <p:departure> <p:departing>new York</p:departing> <p:arriving>los Angeles</p:arriving> <p:departuredate>2014-12-14</p:departuredate> <p:departuretime>late afternoon</p:departuretime> <p:seatpreference>aisle</p:seatpreference> </p:departure> <p:return> <p:departing>los Angeles</p:departing> <p:arriving>new York</p:arriving> <p:departuredate>2014-12-20</p:departuredate> <p:departuretime>mid-morning</p:departuretime> <p:seatpreference/> </p:return> </p:itinerary> <q:lodging xmlns:q="http://travelcompany.example.org/ reservation/hotels"> <q:preference>none</q:preference> </q:lodging> </env:body> </env:envelope> Πηγή: SOAP Version 1.2 Part 0: Primer (Second Edition) - W3C Recommendation 27 April

Πως µεταφέρονται τα δεδοµένα στο SOAP:Body? Πηγή: G. Alonso, F. Casati, H. Kuno, V. Machiraju Web Services Concepts, Architectures and Applications, Springer-Verlag 2004

Πλεονεκτήµατα του Πρωτοκόλλου SOAP Ανοικτό Ασφαλές Έχει τη δυνατότητα να διαπερνά τα firewalls. Το Firewall αντιλαµβάνεται τα responses του SOAP σαν Web page requests Δεν απαιτεί να έχει πρόσβαση σε πρόσθετα ports στους Web servers

WSDL (Web Services Description Language) (1/2) Προδιαγράφει τον ορισµό Διαδικτυακών Υπηρεσιών σε σύνταξη XML, καταγράφει τις λειτουργίες που η Διαδικτυακή Υπηρεσία προσφέρει, τα πρωτόκολλα που µπορούν να χρησιµοποιηθούν για την κλήση της, την τοποθεσία της στο δίκτυο και το πώς δέχεται και επιστρέφει τα δεδοµένα. Πριν την WSDL: Κάθε πάροχος περιέγραφε τις υπηρεσίες µε δικό του τρόπο Τα αρχεία περιγραφών ήταν ασυνεπή και ασύµβατα µεταξύ τους Η Microsoft και η IBM συνδύασαν τις τεχνολογίες τους SCL και NASSL στην WSDL και µε τη βοήθεια της Ariba Η WSDL έκδοση 1.1 υποβλήθηκε στο W3C το 2001 Η έκδοση 2.0 αποτελεί σύσταση του W3C από τον Ιούνιο 2007

WSDL (Web Services Description Language) (2/2) Αποτελεί ένα «συµβόλαιο» ανάµεσα στον πάροχο και τον αιτούντα την υπηρεσία Ο πελάτης µπορεί να προσδιορίσει πού βρίσκεται µια διαδικτυακή υπηρεσία και να καλέσει µια διαθέσιµη διεπαφή της Με εργαλεία που υποστηρίζουν τη WSDL, η διαδικασία γίνεται αυτόµατα Η WSDL περέχει πληροφορίες για: Διεπαφές (Interfaces) που περιγράφουν όλες τις διαθέσιµες λειτουργίες Τύπους Δεδοµένων (Data Type) που αφορούν όλα τα µηνύµατα αιτήσεων και αποκρίσεων Πρόσδεση (Binding) όσον αφορά το πρωτόκολλο µεταφοράς Διεύθυνση (Address) που προσδιορίζει πού βρίσκεται η συγκεκριµένη διαδικτυακή υπηρεσία

Από τι αποτελείται ένα WSDL Αρχείο? «Αφηρηµένο» (abstract definition), που καθορίζει τη διεπαφή (interface) της υπηρεσίας και είναι ανεξάρτητο από πλατφόρµα και γλώσσα Περιγραφή των τύπων δεδοµένων που αποστέλλονται σε µια αίτηση προς την υπηρεσία Η δοµή των µηνυµάτων που αποστέλλονται προς την υπηρεσία Οι επιµέρους λειτουργίες που παρέχονται από την υπηρεσία Η οργάνωση σχετικών λειτουργιών σε επιµέρους διεπαφές που προσφέρονται από την υπηρεσία

Από τι αποτελείται ένα WSDL Αρχείο? «Σταθερό» (concrete definition), το οποίο παρέχει τις λεπτοµέρειες για την πρόσβαση στις υπηρεσίες: Περιγραφή µιας ή περισσότερων υπηρεσιών που προσφέρουν στιγµιότυπα των διαπροσωπειών που ορίζονται στο abstract κοµµάτι Η συσχέτιση των διεπαφών µε κάποια συγκεκριµένα πρωτόκολλα επικοινωνίας (SOAP, ) Τα στιγµιότυπα της κάθε διεπαφής, τα οποία προσφέρονται σε συγκεκριµένες διευθύνσεις (URΙs) Τα στιγµιότυπα υπηρεσιών, ορισµένα σαν συλλογές από στιγµιότυπα διαπροσωπειών

WSDL 2.0: Ποιές οι διαφορές? Πηγή Web Services Description Language (WSDL) Version 2.0 Part 0: Primer W3C Recommendation 26 June 2007

Παράδειγµα WSDL Αρχείου <?xml version="1.0"?> <definitions name="stockquote targetnamespace="http://example.com/stockquote.wsdl" xmlns:tns="http://example.com/stockquote.wsdl" xmlns:xsd1="http://example.com/stockquote.xsd" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/"> <types> <schema targetnamespace="http://example.com/stockquote.xsd" xmlns="http://www.w3.org/2000/10/xmlschema"> <element name="tradepricerequest"> <complextype> <all> <element name="tickersymbol" type="string"/> </all> </complextype> </element> <element name="tradeprice"> <complextype> <all> <element name="price" type="float"/> </all> </complextype> </element> </schema> </types> <message name="getlasttradepriceinput"> <part name="body" element="xsd1:tradepricerequest"/> </message> <message name="getlasttradepriceoutput"> <part name="body" element="xsd1:tradeprice"/> </message> <porttype name="stockquoteporttype"> <operation name="getlasttradeprice"> <input message="tns:getlasttradepriceinput"/> <output message="tns:getlasttradepriceoutput"/> </operation> </porttype> <binding name="stockquotesoapbinding" type="tns:stockquoteporttype"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/ soap/http"/> <operation name="getlasttradeprice"> <soap:operation soapaction="http://example.com/getlasttradeprice"/ > <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> <service name="stockquoteservice"> <documentation>my first service</documentation> <port name="stockquoteport" binding="tns:stockquotebinding"> <soap:address location="http://example.com/stockquote"/> </port> </service> </definitions> Πηγή: Web Services Description Language (WSDL) 1.1, W3C Note 15 March 2001

Πρωτόκολλο Universal (UDDI) Αποτελεί ένα πρωτόκολλο καταχώρησης για Διαδικτυακές υπηρεσίες Ικανοποιεί δύο στόχους αναφορικά µε την ανακάλυψη υπηρεσιών: Βοηθάει τους προγραµµατιστές να βρουν πληροφορίες σχετικές µε κάποιες υπηρεσίες, για να γνωρίζουν πώς να δηµιουργήσουν προγράµµατα πελάτες που να αλληλεπιδρούν µε αυτές. Δίνει τη δυνατότητα για δυναµική «πρόσδεση» (binding), δηλαδή επιτρέπει στα προγράµµατα πελάτες να ρωτάνε την υπηρεσία καταγραφής (registry) και να αποκτάνε εκείνη τη στιγµή αναφορές σε υπηρεσίες που τους ενδιαφέρουν Αποτελεί το ανάλογο του Χρυσού Οδηγού για τις Διαδικτυακές Υπηρεσίες... Στοχεύει στη δηµιουργία ενός µοναδικού µητρώου που περιλαµβάνει όλα τα web services, οπότε για παράδειγµα, I want a web service that provides a tax calculator. Who offers such services? Αποτελεί δηµιούργηµα τριών εταιρειών: Microsoft, IBM και Ariba Αποτελεί πρότυπο του OASIS από το 2003 (Version 2.0). Σήµερα, βρίσκεται στην έκδοση 3.0 (Φεβρουάριος 2005)

Δοµή και Συσχετίσεις στο UDDI Πληροφορίες για το σύνολο των Web Services που παρέχει ο Φορέας Πληροφορίες για τον Φορέα που παρέχει το Web Service businessentity businessentity businessentity businessservice bindingtemplate InstanceDetails categorybag keyedreference identifierbag keyedreference Rosetta-Net BASDA Simple.Buy Schemas, Interchange specification tmodels SIC CODE NAICS DUNS Numbers Thomas Registry ID Τεχνικές προδιαγραφές και περιγραφές για το Web Service Προσαρµοσµένο από www.llnl.gov/casc/workshops/components_2001/viewgraphs/franciscocurbera.ppt

Δοµή Καταλόγου στο UDDI: Πώς? Λευκές σελίδες (µε businessentities), στις οποίες οι ενδιαφερόµενοι µπορούν να βρουν τις διαδικτυακές υπηρεσίες που προσφέρονται από τους Δηµόσιους Φορείς. Κίτρινες σελίδες (µε businessentities, businessservices και bindingtemplates), όπου είναι δυνατή η αναζήτηση υπηρεσιών ανάλογα µε την κατηγορία στην οποία ανήκουν, σύµφωνα µε το σχήµα ταξινόµησης υπηρεσιών του ΠΠ-ΔΔΤ και του ΠΔ&ΥΗΣ. Πράσινες σελίδες (µε tmodels), που περιγράφουν πώς µπορεί ένας Φορέας να καλέσει µια συγκεκριµένη διαδικτυακή υπηρεσία.

Υπάρχουν σήµερα UDDI Registries? 4 live UDDI Business Registries (UBRs), όπου αποθηκεύονται λεπτοµέρειες για τις διαθέσιµες Διαδικτυακές υπηρεσίες 3 test Registries για τις υπηρεσίες που βρίσκονται στο στάδιο της ανάπτυξης ή τελικού ελέγχου Ενδεικτικά: http://uddi.microsoft.com (και http://test.uddi.microsoft.com) https://uddi.ibm.com/ubr/registry.html (και https://uddi.ibm.com/ testregistry/registry.html) http://uddi.sap.com (και http://udditest.sap.com) και http://www.ntt.com/ uddi

WS-Security Αποτελεί ένα πρωτόκολλο επικοινωνίας που προσδίδει ασφάλεια στις Διαδικτυακές Υπηρεσίες. Αρχικά αναπτύχθηκε από τις: IBM, Microsoft, VeriSign και Forum Systems και υποβλήθηκε στον OASIS για προτυποποίηση. Αποτελεί πρότυπο του OASIS από το 2004. Από τον Φεβρουάριο 2006 βρίσκεται στην έκδοση 1.1 Περλαµβάνει λεπτοµέρειες για τη χρήση των προτύπων SAML και Kerberos, καθώς και του X.509 Το WS-Security ανήκει στην ευρύτερη οικογένεια Global XML Web Services Architecture (GXA), η οποία στον τοµέα της ασφάλειας περιέχει επιπλέον τα πρότυπα WS-Policy, WS-Trust, WS-Privacy, WS-SecureConversation, WS- Federation και WS-Authorization.

Τι παρέχει το WS-Security? Αναγνώριση και αυθεντικοποίηση των εµπλεκόµενων Φορέων στη Διαδικτυακή Υπηρεσία. Για την περίπτωση αυτή, το WS-Security ορίζει πώς διαφορετικά σύµβολα ασφάλειας (security tokens) ενσωµατώνονται και µεταφέρονται στα SOAP µηνύµατα Διασφάλιση Ακεραιότητας των Μηνυµάτων, η οποία πραγµατοποιείται µε τη βοήθεια του προτύπου W3C XML Signature που έχει υιοθετήσει το WS-Security Προστασία από µη εξουσιοδοτηµένη πρόσβαση κατά τη µεταφορά του SOAP µηνύµατος, όπου το WS-Security χρησιµοποιεί το πρότυπο W3C XML Encryption για την κρυπτογράφηση των µεταφερόµενων δεδοµένων Το WS-Security περιγράφει πώς επισυνάπτονται επικεφαλίδες υπογραφής και κρυπτογράφησης στα SOAP µηνύµατα και εξασφαλίζει ασφάλεια από άκρη σε άκρη.

Μειονεκτήµατα παλαιότερων τεχνολογιών Κόστος υποδοµής (EDI, CORBA) Κόστος και πολυπλοκότητα υλοποίησης (EDI, CORBA) Χρήση µόνο σε «ιδιωτικά» δίκτυα (EDI, CORBA, DCOM, RMI) Χρήση µόνο σε εφαρµογές που εκτελούνται στην ίδια πλατφόρµα (DCOM) Χρήση µόνο σε εφαρµογές γραµµένες στην ίδια γλώσσα προγραµµατισµού (RMI) Μειωµένες λειτουργίες (XML-RPC) Έλλειψη ευελιξίας (EDI, CORBA, DCOM, RMI)

Βασικές Αρχές Υλοποίησης Διαδικτυακών Υπηρεσιών (1/2) Συµµόρφωση µε Ανοικτά Πρότυπα, όπως XML, SOAP, WSDL, UDDI Επαναχρησιµοποίηση κώδικα και συστατικών στοιχείων (components) Σχέση µε την Υπηρεσιοστραφή Αρχιτεκτονική (Service-oriented Architecture) Υποστήριξη της χαλαρής διασύνδεσης (loose coupling) µεταξύ των components Η µόνη αλληλεπίδραση ανάµεσα στην εφαρµογή και τις υπηρεσίες πραγµατοποιείται µέσω των δηµοσιευµένων διεπαφών Αδιαφάνεια τοποθεσίας

Βασικές Αρχές Υλοποίησης Διαδικτυακών Υπηρεσιών (2/2) Ασφάλεια Διαθεσιµότητα σε επίπεδο περιγραφής στο Ληξιαρχείο Διαδικτυακών Υπηρεσιών και σε επίπεδο υλοποίησης από τον αρµόδιο Φορέα που τις εξέδωσε Επίδοση και Αξιοπιστία Ευκολία ανεύρεσης Διατηρησιµότητα και ευκολία διαχείρισης εκδόσεων Ανεξαρτησία από πλατφόρµες υλοποίησης

Διεπαφές Διαλειτουργικότητας

Τι θα πρέπει να αποφευχθεί; Top-down approach: οι Διαδικτυακές Υπηρεσίες να καλύπτουν τις ανάγκες των αποδεκτών της υπηρεσίας, αλλά να µην υποστηρίζονται επαρκώς από τα Πληροφοριακά Συστήµατα του οργανισµού ή απαιτούν τη δηµιουργία νέων Πληροφοριακών Συστηµάτων από την αρχή. Bottom-up approach: οι Διαδικτυακές Υπηρεσίες απλώς να εξωτερικεύουν όψεις των back-office εφαρµογών του οργανισµού, χωρίς να τοποθετούνται στο συγκεκριµένο πλαίσιο µιας υπηρεσίας Αντίθετα... πρέπει συμβιβάζονται επιχειρηματικές ανάγκες παρεχόμενες υπηρεσίες δυνατότητες Πληροφοριακών Συστημάτων (meet-in-the-middle approach)

Τι χρειάζεται για την τεκµηρίωση µιας Διαδικτυακής Υπηρεσίας? KY.153 Ως καλά ορισµένη Διαδικτυακή Υπηρεσία θεωρείται η Διαδικτυακή Υπηρεσία που τεκµηριώνεται µε: Ø Το πλήρες WSDL αρχείο της, µε την περιγραφή διεπαφής και υλοποίησης, και τη διεύθυνση που λειτουργεί το web service στο Διαδίκτυο Ø Ø Ø Ø Mεταδεδοµένα που σχετίζονται µε τον ιδιοκτήτη της Μοντέλο και Μεταδεδοµένα της υπηρεσίας στην οποία εντάσσεται XML Σχήµατα για τα ανταλλασσόµενα έγγραφα Το UML Ακολουθιακό Διάγραµµα (Sequence Diagram) που αποτυπώνει αναλυτικά τη ροή της

Μεθοδολογία Υλοποίησης Διαδικτυακών Υπηρεσιών Αναγνώριση τελικών υπηρεσιών Αναγνώριση σηµείων διαλειτουργικότητας µεταξύ Φορέων Αναγνώριση Διαδικτυακών Υπηρεσιών Αναγνώριση εσωτερικών σηµείων διαλειτουργικότητας Βήµα 1 Σχεδίαση Διαδικτυακών Υπηρεσιών Υλοποίηση Διαδικτυακών Υπηρεσιών Βήµα 2 Αναζήτηση Διαδικτυακών Υπηρεσιών στο Ληξιαρχείο Διαλειτουργικότητας Δηµοσίευση των Διαδικτυακών Υπηρεσιών στο Ληξιαρχείο Διαλειτουργικότητας Βήµα 3 Αξιοποίηση της Διαδικτυακής Υπηρεσίας από τους εµπλεκόµενους Φορείς Βήµα 4 Συντήρηση Διαδικτυακών Υπηρεσιών Βήµα 5

Σηµείο Κλειδί στο Βήµα 1: Πώς αναγνωρίζονται τα σηµεία δηµιουργίας Διαδικτυακών Υπηρεσιών? Web Service 1 Web Service 2 Web Service 3

Σηµεία Κλειδιά στο Βήµα 2 Καταγραφή των µεθόδων και των δεδοµένων εισόδου εξόδου που απαιτούνται για να αυτοµατοποιήσουν την επικοινωνία Μοντελοποίηση των δεδοµένων που ανταλλάσσονται σε XML Schemas Πρόβλεψη για: Διαχείριση του web service ώστε να διατηρείται σε κάθε περίπτωση η ακεραιότητα των συναλλαγών και διασφαλίζεται η διαθεσιµότητα και η ποιότητά του Συντονισµό και επίβλεψη σύνθετων web services, δηλαδή web services που καλούν άλλα web services για να ολοκληρωθούν Παροχή δυνατότητας ενηµέρωσης της πορείας εκτέλεσης της Διαδικτυακής Υπηρεσίας µέσω web service και µε τη βοήθεια κατάλληλων υποδοµών, όπως Συστήµατα Διαχείρισης Ροής Εργασιών (Workflow Management System). Οι δυνατές καταστάσεις της πορείας εκτέλεσης ενός web service είναι: Σε εκκρεµότητα (pending) είτε εσωτερικά στον οργανισµό είτε από άλλο Φορέα Ολοκληρωµένο είτε επιτυχώς (completed) ή µε αποτυχία (failed)

Σηµεία Κλειδιά στο Βήµα 2 Κάθε Διαδικτυακή Υπηρεσία είναι τύπου Request / Response όπου ο ενδιαφερόµενος αποστέλλει ένα αίτηµα µε τη µορφή SOAP µηνύµατος και περιµένει ασύγχρονα την απάντηση Σε κάθε µήνυµα που αποστέλλεται πρέπει να επιστρέφεται βεβαίωση λήψης (acknowledgement) Οι απαραίτητες πληροφορίες για τη δροµολόγηση και την ορθή λήψη του µηνύµατος ενσωµατώνονται στο soap:header και ενδεικτικά αφορούν τα ακόλουθα: Έκδοση (Version) Ηµεροµηνία και Ώρα Αποστολής (DispatchDateTime) Ηµεροµηνία και Ώρα Εκπνοής (ExpiringDateTime) Αποστολέας (Sender) Αποδέκτης (Recipient) Κωδικός και Περιγραφή Κατάστασης (StateCode και StateDescription) Κωδικός Δοσοληψίας (TransactionID) Κωδικός Μηνύµατος (MessageID)

Σηµείο Κλειδί στο Βήµα 2: Πώς απεικονίζονται οι Διαδικτυακές Υπηρεσίες? Όλες οι µέθοδοι µιας Διαδικτυακής Υπηρεσίας πρέπει να απεικονίζονται σε UML Sequence Diagrams

Παράδειγµα WSDL Αρχείου µε βάση το Πλαίσιο <?xml version="1.0" encoding="utf-8"?> <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/ http/" xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:pc="http://www.e-gif.gov.gr/paymentcatalogue-v1-0.xsd" xmlns:tns="http://www.e-gif.gov.gr/dias_sendpaymentcatalogue-v1-0" targetnamespace="http://www.egif.gov.gr/dias_sendpaymentcatalogue-v1-0"> <wsdl:types> <xs:schema targetnamespace="http://www.e-gif.gov.gr/dias_sendpaymentcatalogue-v1-0" elementformdefault="qualified"> <xs:import schemalocation="paymentcatalogue-v1-0.xsd" namespace="http://www.e-gif.gov.gr/paymentcatalogue-v1-0.xsd"/> </xs:schema> </wsdl:types> <wsdl:message name="messagesendpaymentcatalogue"> <wsdl:part name="parameters" element="pc:paymentcatalogue"/> </wsdl:message> <wsdl:message name="messagereceivepaymentcatalogueacknowledgement"> <wsdl:part name="parameters" element="pc:paymentcatalogueacknowledgment"/> </wsdl:message> <wsdl:porttype name="sendpaymentcatalogueporttype"> <wsdl:operation name="requestresponseoperationsendpaymentcatalogue"> <wsdl:input message="tns:messagesendpaymentcatalogue"/> <wsdl:output message="tns:messagereceivepaymentcatalogueacknowledgement"/> </wsdl:operation> </wsdl:porttype> <wsdl:binding name="sendpaymentcataloguesoap" type="tns:sendpaymentcatalogueporttype"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="requestresponseoperationsendpaymentcatalogue"> <soap:operation soapaction="http://www.e-gif.gov.gr/sendpaymentcatalogue"/> <wsdl:input> <soap:body use="literal"/> </wsdl:input> <wsdl:output> <soap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="sendpaymentcatalogue"> <wsdl:port name="sendpaymentcatalogueporttype" binding="tns:sendpaymentcataloguesoap"> <soap:address location="http://www.dias.com.gr/servicestotaxisnet/dias_sendpaymentcatalogue-v1-0/sendpaymentcatalogue.asmx"/> </wsdl:port> </wsdl:service> </wsdl:definitions>

Σηµείο Κλειδί στο Βήµα 4: Σε ποιο σηµείο των ΠΣ τοποθετούνται οι Διαδικτυακές Υπηρεσίες? Για την εξασφάλιση της µέγιστης δυνατής ευελιξίας στις όποιες αλλαγές του περιβάλλοντος: αντικατάσταση back-office συστηµάτων, αντικατάσταση web services Οι Φορείς πρέπει να υιοθετούν τη λύση του µεσισµικού (middleware) και να µην ενσωµατώνουν τις Διαδικτυακές Υπηρεσίες στην υλοποίηση των back-office συστηµάτων τους

Σηµείο Κλειδί στο Βήµα 5: Εάν αλλάξει έκδοση µια Διαδικτυακή Υπηρεσία? Διασφαλίζεται η συµβατότητα προς τα πίσω (backward compatibility) Ο Φορέας προβαίνει σε άµεση ενηµέρωση των Δηµόσιων Φορέων που χρησιµοποιούν τη Διαδικτυακή Υπηρεσία Στην περίπτωση που εµπλέκονται για παράδειγµα πολίτες και επιχειρήσεις και είναι δύσκολη η άµεση ενηµέρωση των αιτούντων, υπάρχουν 2 εναλλακτικές: Ο Φορέας - πάροχος της υπηρεσίας και το Ληξιαρχείο Διαλειτουργικότητας να τηρεί όλες τις διαθέσιµες εκδόσεις της για ένα λογικό χρονικό διάστηµα, αν όχι για πάντα, και µόλις κάποιος καλέσει την υπηρεσία τον ενηµερώνει ότι είναι διαθέσιµη µια νέα έκδοσή της και πού µπορεί να αναζητήσει την περιγραφή της. Στην περίπτωση της τήρησης µόνο της νεότερης έκδοσης, είναι απαραίτητη η υλοποίηση της λεγόµενης Service Broker αρχιτεκτονικής από την πλευρά του παρόχου. Η αρχιτεκτονική αυτή προβλέπει έλεγχο στις εισερχόµενες κλήσεις και µετατροπή της αίτησης από την παλιά έκδοση στην νέα. Σε περίπτωση που αυτό δεν είναι εφικτό, ενηµερώνει τον αιτούντα υπηρεσίες (service requestor) για την ασυµβατότητα και τον τρόπο µε τον οποίο θα την εξαλείψει.

Ποιά η συµβολή ενός Πλαισίου Διαλειτουργικότητας? Μεθοδολογία Σχεδίασης Διαδικτυακών Υπηρεσιών Βήµα 1: Αναγνώριση Διαδικτυακής Υπηρεσίας Βήµα 2: Υλοποίηση Διαδικτυακής Υπηρεσίας Βήµα 3: Δηµοσίευση Διαδικτυακής Υπηρεσίας Βήµα 4: Αξιοποίηση Διαδικτυακής Υπηρεσίας Βήµα 5: Συντήρηση Διαδικτυακής Υπηρεσίας Συµβολή του GIF q Δηµιουργία µοντέλων και καταγραφή µεταδεδοµένων για τις υπηρεσίες, σύµφωνα µε τις οδηγίες του Μοντέλου Τεκµηρίωσης του egif. q Αναζήτηση στο Ληξιαρχείο Διαλειτουργικότητας για Διαδικτυακές Υπηρεσίες που αφορούν τα σηµεία διαλειτουργικότητας του Φορέα. q Αναζήτηση στο Ληξιαρχείο Διαλειτουργικότητας για πρότυπα XML Σχήµατα. q Δηµιουργία νέων XML Σχηµάτων µε βάση τα Core Components του Ληξιαρχείου και τις οδηγίες του Μοντέλου Τεκµηρίωσης του egif. q Καταγραφή µεταδεδοµένων που σχετίζονται µε τον ιδιοκτήτη της Διαδικτυακής Υπηρεσίας µε βάση το πρότυπο του egif. q Δηµοσίευση των µεταδεδοµένων του Φορέα και του WSDL αρχείου της υπηρεσίας στο Ληξιαρχείο Διαλειτουργικότητας. q Αναζήτηση στο Ληξιαρχείο Διαλειτουργικότητας για τα WSDL αρχεία των Διαδικτυακών Υπηρεσιών. q Τήρηση ιστορικότητας εκδόσεων Διαδικτυακών Υπηρεσιών στο Ληξιαρχείο.

APIs

A Surging App Economy Source: Gigaom Research. Sizing the EU app economy 2014 Source: VisionMobile European App Economy 2014

Why provide an API?

Developers Concerns Data Fragmentation APIs Market Proliferation Source: Musser, J. (2012) Open APIs: What's Hot, What's Not?. http:// www.slideshare.net/jmusser/j-musser-apishotnotgluecon2012 >70% Increase in customer/partner reach 50% Increase in number of apps built from API Source: Hurwitz & Associates 2011 API Constant Evolution

What is an API? An Application Programming Interface (API) is a particular set of rules and specifications that a software program can follow to access and make use of the services and resources provided by another particular software program that implements that API. It serves as an interface between different software programs and facilitates their interaction, similar to the way the user interface facilitates interaction between humans and computers. (Wikipedia) Or simpler an API is: an abstraction that is defined by the description of an interface and the behaviour of the interface.

End-to-end Capabilities in API initiatives

API Business Models Source: John Musser (2013) API Business Models. http://www.slideshare.net/jmusser/j-musser-apibizmodels2013?qid=5bff3d74-949a-4c2a-b26ac880b11fb143&v=qf1&b=&from_search=1

API Categories

Example Web APIs Source: OPENi Project (2013)

Facebook API in practice

RESTful APIs vs XML Web Services - 1

RESTful APIs vs XML Web Services -2 Source: PwC (2012) The business value of APIs. Technology Forecast 2012. Issue 2.

Web APIs Standards REST JSON OAuth

REST Architectural Style Uniform Interface, constraint defines the interface between clients and servers. It simplifies and decouples the architecture, which enables each part to evolve independently. Resource-Based. Manipulation of Resources Through Representations Self-descriptive Messages Hypermedia as the Engine of Application State (HATEOAS) Stateless: the necessary state to handle the request is contained within the request itself, whether as part of the URI, query-string parameters, body, or headers. The URI uniquely identifies the resource and the body contains the state (or state change) of that resource. Cacheable: Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients reusing stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client server interactions, further improving scalability and performance. Client-Server Layered System: A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load-balancing and by providing shared caches. Layers may also enforce security policies. Code on Demand (optional) Source: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm

What is good API design? Easy to learn Easy to use, even without documentation Hard to misuse Easy to read and maintain code that uses it Sufficiently powerful to satisfy requirements Easy to extend Appropriate to audience Joshua Bloch, Principal Software Engineer, Google.

APIs Stories ebay In 2000, ebay started providing a paid developer program In 2005, ebay provided it for free Mainly used for customer reach and marketing 25% of ebay listings come from their API!

APIs Stories Twilio API is the business! 100k developers in 2012

Desicion Support Systems Laboratory, NTUA Public APIs are just the top of the iceberg! Millions of services and APIs in the enterprise