Zastosowanie informatyki w gospodarce Wykład 4

Transkrypt

1 Instytut Informatyki, Automatyki i Robotyki Zastosowanie informatyki w gospodarce Wykład 4 WebSerwisy i SOAP dr inż. Tomasz Walkowiak

2 Serwisy sieciowe, WWW Web Services dostępne poprzez sieć komponenty aplikacyjne przeznaczonym do wykorzystania przez inne aplikacje, zwane aplikacjami klienckimi hermetyzowane, luźno skojarzone kontraktowane funkcje, oferowane poprzez standardowe protokoły. Hermetyzowane : implementacja nigdy nie jest widoczna z zewnątrz. Luźno skojarzone : modyfikowanie danej implementacji nie generuje problemu propagacji zmiany. Kontraktowane opisy działania funkcji oraz specyfikacja ich interfejsów jest publicznie dostępna Business Process Software Services A B C D

3 Technologie serwisów sieciowych WS-Inspection (Web Services Inspection Language) RDF (Resource Description Framework) DAML (DARPA Agent Markup Language) ebxml UDDI WSDL SOAP XML Podstawowym zakładanym zastosowaniem Web Services było B2B. Praktyka wykazała, że obecnie lepiej rozwijają się jednak jako środek integracji informacyjnej przedsiębiorstwa J2EE (przeważa).net 3 3

4 WSDL Servlets/CGI vs Web Services Browser Browser GUI Client Web Server HTTP GET/POST JDBC Web Server WSDL SOAP HTTP Web Server WSDL WSDL HTTP SOAP JDBC DB DB 4

5 Style używania WebSerwsiów RPC (Remote procedure calls) operacje interfejs do wywoływania rozproszonych metod podbne (w funkcjonalności) do CORBA, DCOM, RMI SOA (Service-oriented architecture) komunikaty implementacja architektury zgodnie z koncepcją SOAP: standardized service contracts, loose coupling, abstraction, reusability, autonomy, statelessness, discoverability, composability REST (Representational state transfer) Zorientowanie na komunikacji z ze źródłami zasobów stanowych, a nie komunikatach i operacjach WSDL 2.0 z wszystkimi metodami zapytań HTTP 5

6 Zasada działania protokołu SOAP 1. aplikacja A koduje RPC w komunikacie SOAP 2. przesłanie komunikatu za pomocą HTTP zapora ogniowa sieć komputerowa SOAP 3. aplikacja B dekoduje komunikat i działa zgodnie z nim zapora ogniowa aplikacja A aplikacja B 3. aplikacja B koduje odpowiedź w innym komunikacie SOAP i przesyła wyniki wykonan 6

7 SOAP: realizacja modelu RPC wołanie odległej procedury wymaga podania: adres węzła docelowego nazwa procedury/metody wszystkie argumenty przekazywane do metody wyraźne wyodrębnienie danych służących identyfikacji od danych przeznaczonych do przetwarzania dodatkowe informacje w postaci pozycji nagłówkowych wszystkie przekazane argumenty opatrzone są informacją o typie, zgodną z systemem typów XML Schema URI pozwalające zlokalizować właściwą metodę jest przekazywane w sposób zależny od protokołu 7 7

8 Wołanie RPC ciało komunikatu POST /soap/servlet/rpcrouter HTTP/1.0 Host: localhost:8081 Content-Type: text/xml; charset=utf-8 Content-Length: 451 SOAPAction: "" <?xml version= 1.0 encoding= UTF-8?> <SOAP-ENV:Envelope xmlns:soap-env=" xmlns:xsi=" xmlns:xsd=" <SOAP-ENV:Body> <ns1:add xmlns:ns1="urn:calculator" SOAP-ENV:encodingStyle=" <a xsi:type="xsd:float">2.3</a> <b xsi:type="xsd:float">3.5</b> </ns1:add> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 8 8

9 Odpowiedź RPC HTTP/ OK Content-Type: text/xml; charset=utf-8 Content-Length: 446 Date: Sun, 15 Dec :15:58 GMT Server: Apache Tomcat/4.0.4 (HTTP/1.1 Connector) <?xml version= 1.0 encoding= UTF-8?> <SOAP-ENV:Envelope xmlns:soap- ENV=" xmlns:xsi=" xmlns:xsd=" <SOAP-ENV:Body> <ns1:addresponse xmlns:ns1="urn:calculator" SOAP-ENV:encodingStyle=" <return xsi:type="xsd:float">5.8</return> </ns1:addresponse> </SOAP-ENV:Body> 9 </SOAP-ENV:Envelope> 9

10 Podsumowanie - ogólne zasady MUSI być kodowany przy użyciu XML-a MUSI mieć element Envelope MOŻE mieć element Header MUSI mieć element Body MUSI używać odpowiednich przestrzeni nazw NIE MOŻE zawierać referencji do DTD NIE MOŻE zawierać instrukcji procesora XML-a 10 10

11 Zalety standardu SOAP opiera się na XML niezależny zarówno od języka i od platformy otwartość języka XML oraz ogólna dostępność analizatorów jego składni ułatwiają pisanie aplikacji dużo łatwiejszy w zastosowaniu przenika przez zapory ogniowe 11 11

12 Wady standardu SOAP kodowanie danych jest mało wydajne, komunikaty są kodowane w formie tekstu, wykorzystują więcej pasma niż równoważne komunikaty binarne, muszą być przekształcane do postaci binarnej, by aplikacja mogła na nich działać. rozwiązanie - analizatorów składni XML, rozbudowane aplikacje i zwiększenie obciążenia CPU 12 12

13 SOAP i spółka pośrednik - rejestr UDDI 1. publikacja usługi (WSDL) 3. opis usługi i jej dostawcy 2. wyszukiwanie usługi dostawca usługi 5. dostarczenie wyniku SOAP 4. wywołanie usługi potrzebujący usługi 13

14 14 14

15 Universal Description, Discovery and Integration Service - UDDI określa wspólny zbiór interfejsów programistycznych dla technologii SOAP, umożliwiając implementację brokerów usług Przedsiębiorstwa prowadzące operacje w Internecie realizują dostęp do usług sieciowych za pośrednictwem rejestru UDDI, który ma za zadanie nawiązać kontakt pomiędzy poszukującym usługi a oferującym ją Rejestry UDDI zawierają: informacje o Web Services na bazie nazwy usługodawcy, jego adresu, kategorii biznesowej, informacji technicznej i tym podobne informacje, operacje dotyczące usługi, to jest: rejestracji, wyszukiwania i korzystania z usługi, szczegóły udostępniane przez niskopoziomowy interfejs programistyczny. UDDI posiadają dwa rodzaje klientów: usługodawców publikujących swoje usługi oraz klientów wyszukujących usług, z których chcą skorzystać. UDDI jest bardzo rzadko używane IBM, Microsoft, i SAP zamkneły sowje publiczne UDDI w

16 WSDL przykład <?xml version= 1.0 encoding= UTF-8?> <SOAP-ENV:Envelope xmlns:soap- ENV=" xmlns:xsi=" xmlns:xsd=" <SOAP-ENV:Body> <ns1:add xmlns:ns1="urn:calculator" SOAP- ENV:encodingStyle=" <a xsi:type="xsd:float">2.5</a> <b xsi:type="xsd:float">3.5</b> </ns1:add> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 16

17 Web Services Description Language usługi Web Services są publikowane w rejestrze e-biznesowy UDDI.. Istnieją generatory plików WSDL na podstawie komponentów programowych Dokument WSDL opisuje, co oferuje usługa, gdzie jest umieszczona oraz jak z niej skorzystać WSDL opisuje technikę współdziałania z usługą. Zakłada, że semantyka usługi jest opisana na zewnątrz i może być jednoznacznie wskazana poprzez identyfikator. Tym samym kontrakt dotyczący znaczenia i celu jest oddzielony od kontraktu określającego mechanikę współdziałania. Specyfikacja zatem nie zajmuje się problemem definiowania semantyki usługi. 17

18 Narzędzia do tworzenia WebService ów w Javie Apache Axis 1.4 (2006) Client/Server; SOAP, WSDL Apache Axis2 (1.5.2) Client/Server/Asynch Support; SOAP, WSDL, WSDL 2, REST Apache CFX Client/Server/Asynch Support; SOAP, WSDL, WSDL 2, REST, MTOM Java WebServices Dev Pack (Glassfish) Client/Server; SOAP, WSDL Xfire Client/Server; SOAP, WSDL 18

19 AXIS 1.x klient (1) Pobrać WSDL dodać?wsdl do URL Zkonwertować WSDL na klasę Jawy poprzez java WSDL2Java Pamięctać należy o ustawieniu plików jar do class path Kawałek WSDL-a <xs:complextype name="mathinput"> <xs:sequence> <xs:element name="x" type="xs:double"/> <xs:element name="y" type="xs:double"/> </xs:sequence>... <xs:element name="add" type="mathinput"/> <xs:element name="addresponse" type="mathoutput"/> <message name="addmessage"> <part name="parameters" element="ns:add"/> </message> <porttype name="mathinterface"> <operation name="add"> <input message="y:addmessage"/> <output message="y:addresponsemessage"/> </operation> 19

20 AXIS 1.x klient (2) Dla przykładu gererowane są 4 klasy (w pakiecie) MathService.java MathServiceLocator.java MathSoapHttpBindingStub.java MathInterface.java package org.example.math; public interface MathInterface extends java.rmi.remote { public double add(double x, double y) throws java.rmi.remoteexception; } Zaimportowanie pakietu i użycie we własnej klasie MathServiceLocator loc= new MathServiceLocator(); MathInterface service = loc.getmathendpoint(); double res = service.add(2,3); 20

21 AXIS 1.x - WSDL2Java Bazujac na WSDL program WSDL2Java generuje klasy w pakciecie zdefiniowanym przez namespace dla porttype - interface dla binding - stub class dla service interfejs i implementacje (lokator) serwisu Dla każdego wpisu w sekcji type klasę Javy Klasa Jawy będzie nazywana tka jak typ w WSDL i najczęściej będzie ziarnem Javy <xsd:complextype name="phone"> <xsd:all> <xsd:element name="areacode" type="xsd:int"/> <xsd:element name="exchange" type="xsd:string"/> <xsd:element </xsd:all> </xsd:complextype> public class Phone implements java.io.serializable { public Phone() {...} public int getareacode() {...} public void setareacode(int areacode) {...} public java.lang.string getexchange() {...} public void setexchange(java.lang.string exchange) {...} 21

22 Axis 1.x Web Service Zainstalować Axis 1.x w Tomcat (po prostu skopiować) Utworzyć klasę w Javie - POJO public class AddFunction { } public int addint(int a, int b){ } return (a+b); Skopiować do webapps/axis/ zmieniając rozszerzenie na *.jws Gotowe 22

23 User Application Client API ( Interceptors ) Handlers Transport Sender Transport Listener ( Interceptors ) Handlers Message Receiver Web Service Business Logic Axis2 Architecture Service Consumer Service Provider SOAP 23

24 Axis 2 package samples.quickstart.service.pojo; import java.util.hashmap; public class StockQuoteService { private HashMap map = new HashMap(); public double getprice(string symbol) { Double price = (Double) map.get(symbol); if(price!= null) return price.doublevalue(); return 42.00; } public void update(string symbol, double price) { map.put(symbol, new Double(price)); }} %AXIS2_HOME%\bin\java2wsdl -cp. -cn samples.quickstart.service.pojo.stockquoteservice -of StockQuoteService.wsdl 24 24

25 Axis 2 - services.xml <service name="stockquoteservice" scope="application"> <description> Stock Quote Sample Service </description> <messagereceivers> <messagereceiver mep=" class="org.apache.axis2.rpc.receivers.rpcinonlymess agereceiver"/> <messagereceiver mep=" class="org.apache.axis2.rpc.receivers.rpcmessagerec eiver"/> </messagereceivers> <parameter name="serviceclass"> samples.quickstart.service.pojo.stockquoteservice</ parameter> </service> 25 25

26 AXIS 2 Utworzyć katalog META-INF i wgrać services.xml Utworzyć jar (aar): jar -cvf StockQuoteService.aar * skopiować StockQuoteService.aar do webapps/axis2/web-inf/services Dostęp: e?symbol=ibm Klient: WSDL2Java.bat -uri StockQuoteService?wsdl -o /path/to/my/client/code/ 26 26

27 WSDL.exe od MS Web Services Description Tool Tworzy klasę klienta Wejście: URL do pliku WSDL, protokół, język pliku wynikowego Username and password Wyjście: Pojedynczy plik zrodlowy klasy w danym języku, zawierający: Proxy class Kod do wykonania zapytania w sieci i marshalling wsdl /l:c# /protocol:protocol /out:filename /namespace:mathservicespace MathService.sdl 27

28 Przykład C# wygenerowany przez WSDL.exe [System.Web.Services.Protocols. SoapDocumentMethodAttribute( )] public int Add(int a, int b) { object[] results = this.invoke( Add, new object[] {a, b}); } return (int)(results[0]);... public System.IAsyncResult BeginAdd(... public int EndAdd(... 28

29 WebService podsumowanie Zalety Banalne wdrożenie Serwer i klient Brak problemu z firewallami (HTTP) bezpieczeństwo (HTTPS) Łatwość tworzenia komunikacji w heterogonicznym środwisku Wady np. Java <->.Net Duży rozmiar komunikatów (SOAP w XML) ciężkie serwery 29

30 Przykład Wyszukiwanie najtańszej książki 30