1 / 12

Web Services

Web Services. Kloskowski Dominik. Web Servises ?.

Download Presentation

Web Services

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Web Services Kloskowski Dominik

  2. Web Servises ? Terminem Web services określa się standaryzowaną architekturę, która ma integrować odległe aplikacje przy użyciu standardów, takich jak XML i HTTP. Organizacje mogą stosować taką architekturę wewnętrznie lub w podsystemach dynamicznych relacji biznesowych z partnerami zewnętrznymi. Usługi sieciowe diametralnie zmieniają sposób wykorzystania oprogramowania. Zamiast dużych aplikacji, mamy do czynienia ze zbiorem specjalistycznych, dowolnie rozproszonych usług, z których część może być pilnie strzeżona, reszta zaś udostępniona określonym użytkownikom zgodnie z ich uprawnieniami – wewnątrz lub na zewnątrz organizacji.

  3. Po co komu Web Servises ? • "Usługi webowe" zrodziły się z potrzeby bezpiecznej ekspozycji logiki biznesowej poza obszar wyznaczany przez zapory ogniowe. Ma ona integrować Web i tradycyjne aplikacje za pomocą całego szeregu komponentów oprogramowania, warstw pośredniczących i protokołów. • Dzięki wykorzystywaniu nowego protokołu SOAP usługa opracowana w technologii Web Services ma możliwość współpracy (wymiany komunikatów) z dowolną inną usługą. Powinny zniknąć problemy występujące przy konwersjach realizowanych pomiędzy protokołami architektur DCOM i CORBA. • Web Services komunikują się wykorzystując HTTP oraz XML. Dowolne urządzenie lub system obsługujący te popularne standardy może utrzymywać takie usługi oraz udostępniać je. Można się spodziewać, że już niedługo Web Services będą powszechnie implementowane także w samochodach, automatach ulicznych, czy choćby komórkach.

  4. Role biznesowe Architektura usług sieciowych przewiduje współpracę między podmiotami reprezentującymi następujące role biznesowe : • dostawca usługi(service provider) - udostępnia usługę sieciową • broker usług (service broker) - umożliwia korzystającemu znalezienie żądanej usługi • żądający usługi(service requestor) - wykorzystuje usługę udostępnianą przez dostawcę

  5. Możliwe operacje Podmioty te współpracują ze sobą za pomocą następujących operacji : • Publikacja (Publish) – umożliwia dodanie usługi do rejestru. Dostawca usług kontaktuje się z brokerem w celu zarejestrowania usługi • Wyszukiwanie (Find) – umożliwia odnalezienie interesujących usług w rejestrze brokera. Żądający musi określić kryteria poszukiwanych usług, wówczas broker dostarczy rezultaty wyszukiwania najbardziej odpowiadające zadanym kryteriom • Wiązanie (Bind) – nawiązanie komunikacji pomiędzy dostawcą a żądającym usług

  6. Cykl życia • dostarczyciele usług - rejestrują się u pośredników (UDDI). • klient - pyta pośrednika, kto mu da daną usługę. (SOAP). • pośrednik (broker) - lokalizuje mu tę usługę i podaje opis jej użycia (WSDL). • klient podłącza się do dostarczyciela i korzysta z usługi (SOAP)

  7. SOAP • SOAP (Simple Object Access Protocol) Jest opartym na XML protokołem, używanym do wymiany strukturalizowanych danych w zdecentralizowanym, rozproszonym środowisku. Zawiera on trzy części: kopertę (envelope), nagłówek (header) i zawartość (body). Koperta wyznacza początek i koniec wiadomości SOAP. Może ona także specyfikować zasady kodowania. Nagłówek SOAP może zawierać adres lub adresy pocztowe, kod płatności lub informację o interakcji w stylu RPC (Remote Procedure Call). W kopercie SOAP mogą być zawarte poszczególne nagłówki. Zawartość wiadomości SOAP przenosi dane formatowane samoopisującą się strukturą lub interfejs w stylu RPC. SOAP jako, że używa HTTP jako protokołu transportu, jest bezstanowy. Nie implementuje bezpieczeństwa, transport przez HTTP pozwala jednak na zastosowanie SSL-a na poziomie aplikacji. Protokół SOAP jest obecnie wspierany przez wszystkich podstawowych dostawców systemów oraz oprogramowania narzędziowego.

  8. SOAP - przykład • Prosty dokument SOAP z żądaniem ceny akcji: <env:Envelope xmlns:env="http://www.w3.org/2001/06/soap-envelope" env:encodingStyle="http://www.w3.org/2001/06/soap-encoding"> <env:Body> <m:GetPrice xmlns:m="Some-URI"> <Item> Stock </Item> </m:GetPrice> </env:Body> </env:Envelope> 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

  9. Warstwa opisu usług WSDL (Web Services Description Language) jest językiem opisującym interfejs i usługi aplikacji webowych, ustanawiającym gramatykę dla komunikacji pomiędzy punktami końcowymi czy klientami, usługami webowymi lub aplikacjami. Zapewnia: • Informacje o dostępnych funkcjach • Typy danych wszystkich komunikatów XML • Informacje o dostępnych protokołach • Informacje o lokalizacji danej usługi Z każdej uslugi sieciowej można wyciagnąć funkcje przez nią oferowane poprzez otworzenie jej pliku WSDL za pomocą przegladarki http://localhost/firstWebService.asmx?wsdl

  10. Warstwa lokalizacji usług • UDDI (Universal Description Discovery and Integration) Jest to konsorcjum powołane przez Microsoft, IBM i Ariba dla stworzenia standardu internetowego do opisu, rejestracji i wykrywania (identyfikacji) usług webowych. Struktura UDDI jest zestawem baz danych, gdzie można rejestrować własne usługi webowe, jak również wyszukiwać inne usługi webowe. Jest to globalny rejestr, przechowujący dane: • White Pages: ogólne dane każdej firmy • Yellow Pages: ogólna klasyfikacja • Green Pages: techniczne dane

  11. Za i przeciw Za : • Niezależność od platformy systemowej i języka programowania • Wykorzystanie komunikatów tekstowych (XML) • Integracja środowisk CORBA i COM+ • Łatwość projektowania interfejsów dla istniejących aplikacji • Wsparcie wszystkich najważniejszych dostawców technologii Przeciw : • problemy z wydajnością • niepełna standaryzacja mechanizmów bezpieczeństwa • niepełna standaryzacja rozwiązań wysokiej dostępności • wciąż niewiele poważnych wdrożeń

  12. Źródła • Building XML Applications With UML : Practical e-Business Applications, David Carlson • ComputerWorld polska • www.networld.pl

More Related