Referat z programowania systemowego. Przegląd protokołów do realizacji usług sieciowych SOAP, WSDL, UDDI

Wielkość: px
Rozpocząć pokaz od strony:

Download "Referat z programowania systemowego. Przegląd protokołów do realizacji usług sieciowych SOAP, WSDL, UDDI"

Transkrypt

1 Akademia Górniczo Hutnicza im. St. Staszica w Krakowie Wydział EAIiE Referat z programowania systemowego Przegląd protokołów do realizacji usług sieciowych SOAP, WSDL, UDDI Jacek Midura Marcin Klimek Studia dzienne Rok 5 Informatyki Rok akademicki 2002/2003

2 Spis treści 1. Wprowadzenie Ogólny opis - webservices Wstępne zarysowanie obszarów zastosowań SOAP, WSDL i UDDI Protokół SOAP Ogólna charakterystyka protokołu SOAP, relacja pomiędzy XML a SOAP Model komunikacji Struktura komunikatu SOAP Koperta SOAP Nagłówek SOAP Ciało SOAP Kodowanie danych w komunikatach SOAP Transmisja komunikatów SOAP protokołem HTTP Użycie protokołu SOAP w celu zdalnego wywoływania procedur (RPC) Wady i zalety SOAP Protokół WSDL Do czego służy WSDL Elementy protokołu WSDL (struktura dokumentu WSDL) Przykłady praktyczne zastosowania WSDL Wady i zalety stosowania WSDL Protokół UDDI Do czego służy UDDI Elementy protokołu UDDI Przykład zastosowania UDDI Wady i zalety stosowania UDDI Zakończenie Współpraca protokołów SOAP, WSDL i UDDI Bezpieczeństwo Web Services Przyszłość Web Services...24

3 1. Wprowadzenie 1.1. Ogólny opis - webservices Pod terminem Usługi Web należy rozumieć zbiór małych funkcjonalnych klocków pracujących w sieci i udostępniających określone usługi innym systemom czy też innym webservices. Takimi klockami mogą być np. usługi pogodowe, translatory językowe czy mechanizmy przeliczające waluty, a wykorzystywane mogą być przez inne usługi udostępniające usługi bardziej złożone. Należy pamiętać, że webservices zwykle nie będą stanowić samodzielnych aplikacji, a jedynie stanowić interfejs komunikacyjny pomiędzy klientami z sieci a systemami biznesowymi. Tim Bray, współtwórca XML, definiuje usługi sieciowe jako standardowy interfejs, który pozwala jednej aplikacji programowo odkryć, zinterpretować i wykorzystać usługi oferowane przez inne platformy aplikacyjne bądź systemy operacyjne, w sposób niezależny od wykorzystywanego przez nie języka programowania. Wyjątkową siłą webservices jest wykorzystanie istniejących i szeroko stosowanych technologii tj. protokołu HTTP i języka XML. HTTP jest jednym z najbardziej rozpowszechnionych protokołów w sieci WEB, co umożliwia natychmiastowe wykorzystanie tej platformy do przesyłania komunikatów. XML dostarcza metajęzyk za pomocą którego porozumiewają się klienci z usługami oraz poszczególne komponenty. Idąc dalej, przy budowie i wykorzystaniu webservices nie ma znaczenia w jakiej technologii jest napisana usługa, na jakim systemie operacyjnym pracuje. Pełną interoperatywność zapewnia protokół SOAP, który ma aspiracje stać się następcą technik typu CORBA, RMI czy DCOM. 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 mogą być pisane w dowolnych językach programowania, więc twórcy aplikacji będą mogli pisać usługi bez zmiany środowiska tworzenia aplikacji, w którym wcześniej pracowali. Protokół SOAP jest obecnie wspierany przez wszystkich podstawowych dostawców systemów oraz oprogramowania narzędziowego Wstępne zarysowanie obszarów zastosowań SOAP, WSDL i UDDI W celu umożliwienia komunikacji między aplikacjami rozproszonymi w sieci, należy opracować jakiś standard formatowania i przesyłania informacji. Wiele takich protokołów zostało już zaproponowanych w przeszłości, z czego niektóre uzyskały status standardu, a inne były rozwijane

4 przez pojedyncze firmy dla własnych produktów. Większość z nich ma jednak ograniczone zastosowanie w budowaniu wielkich, rozproszonych aplikacji w skali Internetu, ze względu na ich różne wymogi lub ograniczenia dotyczące platformy, producenta, czy też możliwości komunikacyjnych. Otwartość i rozszerzalność języków opartych na XML została szeroko uznana jako rozwiązanie dla nowoczesnych protokołów komunikacji sieciowej. Nie znaczy to bynajmniej, że XML powinien być stosowany w każdej sytuacji. W rzeczywistości stosowanie XML-a może być niekiedy wykluczone w systemach wymagających maksymalnej wydajności, ponieważ jego składnia jest bardzo 'rozrzutna', gdy porównać objętość właściwej informacji zawartej w dokumencie do jego całej objętości wraz ze znacznikami. Jednak dla wielu aplikacji e-biznesowych otwartość i rozszerzalność dialektów XML-a są ogromnymi zaletami zarówno przy zapisie treści, jak i struktury komunikatów. Wydaje się, że protokoły komunikacji wykorzystujące XML najlepiej sprawdzają się w integracji prowadzonej nie w czasie rzeczywistym, co ma często miejsce w systemach B2B. 2. Protokół SOAP 2.1. Ogólna charakterystyka protokołu SOAP, relacja pomiędzy XML a SOAP SOAP Simple Object Access Protocol (Prosty Protokół Dostępu do Obiektów). Czym jest SOAP: jest protokołem, a zatem mechanizmem transportu informacji; przenoszone informacje są uporządkowane (posiadają strukturę i typy); dane zapisane są w języku rozszerzalnych znaczników (XML); w tym protokole można przenosić wszelkiego rodzaju dane (w razie potrzeby są one kodowane do postaci wyrażalnej w XML); SOAP posiada bardzo szeroki zakres zastosowań: od prostych zastosowań komunikacyjnych po zdalne wywoływanie procedur (RPC). Czym nie jest SOAP: nie jest tym samym, co XML, chociaż jest na nim oparty; nie ma związku z protokołami SMTP czy HTTP, chociaż komunikaty SOAP często są przesyłane z wykorzystaniem mechanizmów typowych dla tych protokołów (np. transmitowane przez TCP/IP na portach 25 lub 80, często spotyka się również enkapsulowanie wewnątrz

5 komunikatów SMTP lub HTTP); nie jest związany z żadnym konkretnym modelem programowania czy jakąś specyfiką implementacji przeciwnie: jest uniwersalnym sposobem komunikacji w środowiskach rozproszonych oraz heterogenicznych. Organizacja XML Protocol Working Group działająca w ramach W3C opracowała dokument pod tytułem XML Protocol Abstract Model, który zawiera rozważania na temat cech dobrego protokołu komunikacyjnego opartego na XML i może stanowić podstawę oceny jakości konkretnych implementacji. Dokument ten powstał 9 lipca 2001 i ma status W3C Working Draft. Oto podstawowe zalecenia dotyczące budowy protokołu XML-owego zawarte w tej pracy: Należy dopuszczać możliwość wykorzystania różnych protokołów transportu (np. HTTP, SMTP i in.) Komunikacja może zachodzić wedle różnych schematów: wysłanie pojedynczego komunikatu, zapytanie/ odpowiedź, wymiana dłuższej sekwencji komunikatów Pośredniczące hosty mogą zmieniać komunikat API protokołu powinno zapewniać operacje wysłania, odebrania, przesłania dalej i sprawdzenia statusu komunikatu Należy zadbać o obsługę błędów połączenia Trzeba umożliwić transport dowolnych załączników do komunikatów w XML Obecnie trwają prace nad dostosowaniem specyfikacji protokołu SOAP 1.2 do tego modelu abstrakcyjnego (w tej chwili obowiązująca wersja nosi numer 1.1). Jako baza niniejszego opracowania wykorzystana została specyfikacja SOAP wersji 1.1 opracowana przez W3C, znajdująca się pod adresem Wśród wielu opracowywanych aktualnie protokołów bazujących na XML-u, SOAP wyróżnia się najszerszą akceptacją dużych producentów oprogramowania Model komunikacji Komunikacja za pomocą SOAP jest zasadniczo komunikacją jednokierunkową: od nadawcy do odbiorcy. Łatwo sobie jednak wyobrazić inne scenariusze bazujące na tym podstawowym: np. schemat wywołanie odpowiedź (request response) lub dialog dwóch stron. Wybrana do przenoszenia komunikatów warstwa transportowa może ułatwiać budowanie takich bardziej rozbudowanych scenariuszy, np. przy łączeniu za pomocą TCP/IP po przesłaniu komunikatu nadawca z odbiorcą zamieniają się rolami, a odpowiedź jest transmitowana tym samym połączeniem, którym poszło wywołanie.

6 2.3. Struktura komunikatu SOAP Komunikat SOAP jest dokumentem XML, który składa się z trzech elementów: 1.koperty SOAP (SOAP envelope) obowiązkowo 2.nagłówka SOAP (SOAP header) niekoniecznie 3.ciała SOAP (SOAP body) obowiązkowo Koperta SOAP Nagłówek SOAP wpis1 wpis2 Ciało SOAP element1 element2 Przykład: <env:envelope xmlns:env=" <env:header> <n:alertcontrol xmlns:n=" <n:priority>1</n:priority> <n:expires> t14:00:00-05:00</n:expires> </n:alertcontrol> </env:header> <env:body> <m:alert xmlns:m=" <m:msg>pójść na obiad o 14:00</m:msg> </m:alert> </env:body> </env:envelope> Koperta SOAP Koperta SOAP jest głównym, najbardziej zewnętrznym elementem dokumentu XML, który reprezentuje komunikat. Odnoszą się do niej następujące reguły: nazwa tego elementu musi brzmieć Envelope ;

7 ten element musi być obecny w komunikacie SOAP; ten element może zawierać deklaracje przestrzeni nazw oraz dodatkowe atrybuty. Specyfikacja SOAP nie zakłada przypisywania kopertom tradycyjnych dużych i małych numerów wersji. Komunikat SOAP musi mieć natomiast element Envelope połączony z przestrzenią nazw " Jeśli jakaś aplikacja otrzyma komunikat z inną przestrzenią nazw w kopercie, ma obowiązek zwrócić błąd Nagłówek SOAP Jest on elementem nieobowiązkowym. Służy do przekazywania informacji o tym kto i w jaki sposób powinien przetwarzać dane zawarte w ciele komunikatu. Zawartość nagłówka może nieść także informację dla ogniw pośredniczących w transporcie komunikatu (np. serwerów proxy), może być także przez nie zmieniana. Następujące reguły dotyczą nagłówka: nazwa tego elementu musi brzmieć Header ; jeśli ten element występuje w komunikacie SOAP, musi być pierwszym bezpośrednim potomkiem elementu Envelope ; może on zawierać wpisy nagłówka (header entries), każdy będący bezpośrednim potomkiem elementu Header. Każdy wpis musi mieć zdefiniowaną przestrzeń nazw Ciało SOAP W tym elemencie przenoszona jest właściwa informacja. Ciało SOAP musi stosować się do następujących reguł: nazwa elementu musi brzmieć Body ; element ten musi wystąpić w komunikacie i musi być bezpośrednim potomkiem elementu Envelope ; jeśli w komunikacie występuje nagłówek, to ciało musi następować bezpośrednio po nim, w przeciwnym wypadku musi być pierwszym potomkiem elementu Envelope ; ten element może zawierać serię wpisów, z których każdy jest jego bezpośrednim potomkiem. Szczególnym rodzajem elementu jest element Fault. Służy on do przenoszenia informacji o błędach. Jeśli występuje w komunikacie SOAP, musi być wpisem ciała komunikatu (body entry) i może wystąpić tylko raz w całym komunikacie. Element Fault posiada cztery podelementy: faultcode kod błędu (obowiązkowy). Schemat kodów jest podobny do użytego w protokole http (1xx, 2xx, 3xx itd.);

8 faultstring czytelne dla człowieka (nie przeznaczone do przetwarzania maszynowego) objaśnienie istoty błędu (obowiązkowe); faultactor URI obiektu, który spowodował błąd (obowiązkowe, jeśli błąd powstał na którymś z etapów pośrednich uczestniczących w przekazywaniu komunikatu, nieobowiązkowe jeśli błąd powstał u adresata komunikatu); detail specyficzne informacje dotyczące błędu (obowiązkowe, jeśli błąd powstał przy przetwarzaniu ciała komunikatu, zabronione, jeśli błąd nie powstał przy przetwarzaniu ciała komunikatu) Kodowanie danych w komunikatach SOAP Kodowanie danych w SOAP wykorzystuje hierarchię typów danych, która jest generalizacją podobnych hierarchii spotykanych we współczesnych językach programowania czy bazach danych. Najbardziej podstawowy podział typów to podział na typy proste (skalarne) oraz na typy złożone, które są połączeniem pewnej liczby części, z których każda posiada swój typ. XML dopuszcza bardzo elastyczne kodowanie danych, SOAP w tej dziedzinie jest bardziej ograniczony (ma ściślejsze reguły kodowania). SOAP przejmuje od XML wszystkie typy proste. Są to: string, boolean, decimal, float, double, duration, datetime, time, date, gyearmonth, gyear, gmonthday, gday, gmonth, hexbinary, base64binary, anyuri, QName, NOTATION. Przykład typowania danych: <element name="age" type="int"/> <element name="height" type="float"/> <element name="displacement" type="negativeinteger"/> <element name="color"> <simpletype base="xsd:string"> <enumeration value="green"/> <enumeration value="blue"/> </simpletype> </element> <age>45</age> <height>5.9</height> <displacement>-450</displacement> <color>blue</color> Ponadto w SOAP wspierane są następujące typy złożone: rekordy i tablice. Przykład:

9 <e:book> <author>henry Ford</author> <preface>prefatory text</preface> <intro>this is a book.</intro> </e:book> <element name="myfavoritenumbers" type="soap-enc:array"/> <myfavoritenumbers SOAP-ENC:arrayType="xsd:int[2]"> <number>3</number> <number>4</number> </myfavoritenumbers> 2.4. Transmisja komunikatów SOAP protokołem HTTP Bardzo często do transportu komunikatów SOAP używany jest protokół HTTP. Przyczyn jest kilka: jest to protokół bardzo elastyczny; jest zarazem pewny posiada mechanizmy raportowania błędów; jest niezwykle rozpowszechniony (co wiąże się z bogactwem narzędzi); umożliwia przekazywanie komunikatów SOAP nawet przez zapory (firewall) analizujące zawartość transmitowanego strumienia danych (ponieważ zazwyczaj zapory takie przepuszczają transmisję HTTP). Ze względu na charakter protokołu HTTP najbardziej naturalne jego wykorzystanie zachodzi podczas scenariusza transmisji wywołanie odpowiedź (request response). Podczas transmisji komunikatów SOAP wewnątrz wywołań/odpowiedzi HTTP należy używać typu text/xml. Pomimo iż SOAP można powiązać z różnymi typami wywołań HTTP, najczęściej jednak jest używane wywołanie POST. Odpowiedzi w protokole HTTP muszą posiadać odpowiedni status (np. 2xx oznaczają poprawne odebranie i przetworzenie wywołania). Jeśli podczas przetwarzania komunikatu wystąpi błąd, musi zostać zwrócona odpowiedź ze statusem 500 (Internal Server Error), a w ciele zwracanego komunikatu SOAP musi się znaleźć element Fault. Przykład dialogu SOAP w HTTP: POST /StockQuote HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI"

10 <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Body> <m:getlasttradeprice xmlns:m="some-uri"> <symbol>dis</symbol> </m:getlasttradeprice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> HTTP/ OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Body> <m:getlasttradepriceresponse xmlns:m="some-uri"> <Price>34.5</Price> </m:getlasttradepriceresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 2.5. Użycie protokołu SOAP w celu zdalnego wywoływania procedur (RPC) Jednym z celów projektowych SOAP było umożliwienie transportowania za jego pomocą wywołań i odpowiedzi RPC. Choć nie jest to jedyne rozwiązanie, jednak naturalne staje się zastosowanie jako protokołu transportującego HTTP, gdzie wywołanie HTTP staje się wywołaniem zdalnej procedury, natomiast odpowiedź HTTP reprezentuje odpowiedź RPC. Reprezentacja RPC opisana w specyfikacji protokołu SOAP zakłada, że dane niezbędne do wywołania procedury (URI obiektu docelowego, nazwa metody, opcjonalna sygnatura metody i parametry metody) przekazywane są jako struktura (złożony typ danych) wewnątrz ciała komunikatu SOAP. Oczywiście nie jest to jedyna możliwość Wady i zalety SOAP Do zalet można zaliczyć: niezwykłą elastyczność protokołu, który pozwala przenosić właściwie dowolne informacje;

11 możliwość definiowania struktury i semantyki przenoszonych informacji; możliwość łączenia z różnymi protokołami transportowymi (np. HTTP); możliwość realizacji różnych scenariuszy komunikacji; akceptowalność protokołu przez właściwie wszystkie systemy komputerowe i środowiska systemowe; niezawodność protokołu dzięki ścisłemu zdefiniowaniu sytuacji wystąpienia błędu oraz zachowania aplikacji w takich okolicznościach. Niewątpliwe zaś wady to: duży narzut samego języka XML (rozmiar komunikatu jest znacząco większy niż sumaryczny rozmiar danych w nim zawartych); jest jeszcze dość młodym protokołem, podlega rozwojowi i modyfikacjom (chociaż jest już dość dobrze i ściśle zdefiniowany). 3. Protokół WSDL 3.1. Do czego służy WSDL WSDL (Web Services Description Language) to wypromowany przez IBM i Aribę, oparty na XML prosty język pozwalający opisać usługę sieciową - jej sposób wywołania, parametry i formaty wyników, lecz bez żadnych informacji biznesowych czy parametrów dostępności. Dzięki WSDL mamy informacje jakie metody udostępnia Web Service. Do tej pory chcąc skorzystać z komponentów, musieliśmy otrzymać od dostawcy opis techniczny i pliki nagłówkowe, co nie zawsze było możliwe. Rozwiązanie tu zastosowane jest bardzo eleganckie. Usługę można odpytać, jakie funkcje udostępnia. Wystarczy, że w URL wpiszemy: W odpowiedzi otrzymamy dokument w formacie WSDL. WSDL jest nadzbiorem języka SDL (i innych), umożliwia twórcom usługi Web opisanie w zrozumiałym formacie co potrafi usługa, gdzie się znajduje i jak ją wywołać. W przeszłości różni producenci wykorzystywali różne schematy. Język WSDL jest standardowym formatem opisu sieciowych usług XML. Język WSDL bazuje na standardzie XML. Jego zadaniem jest tworzenie opisu funkcji usług Web Services oraz sposobu ich wywoływania. Język WSDL jest przydatny przy automatyzacji komunikacji pomiędzy usługami Web Services, umożliwiając współdziałanie usług. Opracowanie dotyczące WSDL oparte jest na informacjach umieszczonych na stronie

12 Elementy protokołu WSDL (struktura dokumentu WSDL) Dokument WSDL definiuje usługi (services) jako kolekcje punktów końcowych lub portów. Występuje tu abstrakcyjne (niezależne od stosowanej technologii) definiowanie punktów końcowych, przesyłanych wiadomości, formatu danych, operacji. W protokole WSDL można wyróżnić następujące elementy: Komunikat (znacznik <message>) o Abstrakcyjna definicja formatu danych pojedynczej transmisji Typ portu (znacznik <porttype>) o Grupuje komunikaty wg wykonywanych operacji Wiązanie (znacznik <binding>) o Określa konkretny protokół, łączy typ portu z implementacją (zwykle SOAP) Usługa (znacznik <service>) o Definiuje fizyczną lokalizację punktu końcowego Schemat danych (znacznik <types>) o Dostarcza definicji typów danych używanych do opisu wiadomości, opis (niskiego poziomu) parametrów komunikatu WSDL nie wprowadza nowego języka definicji typu. Rozpoznaje jedynie typy w opisywanym formacie wiadomości i wspiera specyfikację XML Schema. WSDL definiuje również wspólny binding mechanism. Jest on używany do dołączania właściwego protokołu lub formatu danych lub struktury do abstrakcyjnej wiadomości, operacji czy punktu końcowego. Struktura dokumentu WSDL jest następująca: Sekcja <definitions> - zawiera definicję usługi (zwykle plik WSDL opisuje jedną usługę). Po znaczniku <definitions> występują następujące deklaracje atrybutów: name: - opcjonalny atrybut informujący w sposób ogólny o przeznaczeniu usługi; targetnamespace: - definiuje logiczną przestrzeń nazw dla informacji o usłudze; xmlns:tns: - jeżeli występuje, to ustawiana jest na wartość targetnamespace; xmlns:soap i xmlns:xsd: - standardowe definicje przestrzeni nazw; xmlns: - domyślna przestrzeń nazw dokumentu WSDL ustawiana jest na Wewnątrz sekcji <definitions> występują trzy sekcje konceptualne (pojęciowe):

13 <message> i <porttype>: - określają, jakie operacje dostarcza usługa; <binding>: - określa, jak są wywoływane operacje; <service>: - określa, gdzie jest ulokowana usługa. Dodatkowo w opcjonalnej sekcji <types>, położonej bezpośrednio przed sekcją <message>, muszą być zdefiniowane wszystkie typy złożonych danych, wykorzystywanych przez usługę. Można powiedzieć, że usługi są definiowane przy użyciu sześciu sekcji: <types> - opcjonalna sekcja, położona bezpośrednio przed sekcją <message>, tu muszą być zdefiniowane wszystkie typy złożonych danych, wykorzystywanych przez usługę. Składnia: <definitions... > <types> <xsd:schema... />* </types> </definitions> <message> - odnosi się do pojedynczego fragmentu informacji przekazywanego pomiędzy programem wywołującym oraz usługą. Sekcja ta może mieć zero lub więcej części, a każda z nich może mieć nazwę i opcjonalny typ. Te części są wydzielone logicznie każda z nich jest powiązana z typem systemu. Gdy plik WSDL opisuje obiekt, każda z części jest odwzorowywana na argument wywołania metody. Gdy metoda zwraca wartość void - odpowiedzią jest pusty komunikat. Wiadomość może mieć różne atrybuty. Składnia: <definitions... > <message name="nmtoken"> * <part name="nmtoken" element="qname"? type="qname"?/> * </message> </definitions> <porttype> - grupuje komunikaty według wykonywanych operacji Składnia: <wsdl:definitions... > <wsdl:porttype name="nmtoken"> <wsdl:operation name="nmtoken"... /> * </wsdl:porttype> </wsdl:definitions>

14 <operation> - definiuje konkretną sekwencję komunikatu wejścia/wyjścia. Atrybut komunikatu każdego wejścia/wyjścia musi odpowiadać nazwie komunikatu <message>, która została zdefiniowana wcześniej. Gdy WSDL opisuje obiekt, każda <operation> jest odwzorowywana na metodę, a każdy <porttype> na interfejs lub klasę Javy. Składnia: <wsdl:definitions... > <wsdl:porttype... > * <wsdl:operation name="nmtoken"> <wsdl:input name="nmtoken"? message="qname"/> </wsdl:operation> </wsdl:porttype > </wsdl:definitions> <binding> - odpowiada zaimplementowanemu <porttype>, wykorzystując indywidualny protokół (np. SOAP lub CORBA). Atrybut typu łączenia musi odpowiadać nazwie wcześniej zdefiniowanego <porttype>. Ponieważ język WSDL jest niezależny od protokołu, można określić połączenia m.in. dla takich standardowych protokołów, jak DCOM, SOAP czy CORBA. Jeżeli usługa wspiera więcej niż jeden protokół, to plik WSDL powinien zawierać konceptualną sekcję <binding> dla każdego z nich. Składnia: <wsdl:definitions... > <wsdl:binding name="nmtoken" type="qname"> * <-- extensibility element (1) --> * <wsdl:operation name="nmtoken"> * <-- extensibility element (2) --> * <wsdl:input name="nmtoken"? >? <-- extensibility element (3) --> </wsdl:input> <wsdl:output name="nmtoken"? >? <-- extensibility element (4) --> * </wsdl:output> <wsdl:fault name="nmtoken"> * <-- extensibility element (5) --> * </wsdl:fault> </wsdl:operation> </wsdl:binding> </wsdl:definitions>

15 <service> - jest modelowana jako zbiór portów, gdzie <port> reprezentuje dostępność konkretnego połączenia (binding) w określonym punkcie końcowym (węźle). Atrybut połączenia portu musi się odnosić do nazwy wcześniej zdefiniowanego połączenia <binding>. Składnia: <wsdl:definitions... > <wsdl:service... > * <wsdl:port name="nmtoken" binding="qname"> * <-- extensibility element (1) --> </wsdl:port> </wsdl:service> </wsdl:definitions> Każdy element pliku WSDL może deklarować opcjonalny komponent <documentation>, który zawiera przeznaczoną dla użytkownika informację opisową Przykłady praktyczne zastosowania WSDL Komunikaty i typy portów: <message name= Add > <part name= n1 type= short > <part name= n2 type= short > </message> <message name= AddResponse > <part name= n1 type= short > <part name= n2 type= short > <part name= Result type= double > </message> <porttype name= CalcPortType > <operation name= Add parameterorder= AddInOut1 AddInOut2 > <input message= Add /> <output message= AddResponse /> </operation> </porttype> Wiązania i usługi <binding name= CalcBinding type= CalcPortType > <soap:binding style= document transport= /> <operation name= Add > <soap:operation soapaction=

16 <input> <soap:body.../> </input> <output> <soap:body.../> </output> </operation> </binding> <service name= Calc > <port name= CalcPortType binding= CalcBinding > <soap:address location= /> </port> </service> Metody GET I POST zwracające GIF lub JPG <definitions... > <message name="m1"> <part name="part1" type="xsd:string"/> <part name="part2" type="xsd:int"/> <part name="part3" type="xsd:string"/> </message> <message name="m2"> <part name="image" type="xsd:binary"/> </message> <porttype name="pt1"> <operation name="o1"> <input message="tns:m1"/> <output message="tns:m2"/> </operation> </porttype> <service name="service1"> <port name="port1" binding="tns:b1"> < location=" </port> <port name="port2" binding="tns:b2"> < location=" </port> <port name="port3" binding="tns:b3">

17 < location=" </port> </service> <binding name="b1" type="pt1"> < verb="get"/> <operation name="o1"> < location="o1/a(part1)b(part2)/(part3)"/> <input> < </input> <output> <mime:content type="image/gif"/> <mime:content type="image/jpeg"/> </output> </operation> </binding> <binding name="b2" type="pt1"> < verb="get"/> <operation name="o1"> < location="o1"/> <input> < </input> <output> <mime:content type="image/gif"/> <mime:content type="image/jpeg"/> </output> </operation> </binding> <binding name="b3" type="pt1"> < verb="post"/> <operation name="o1"> < location="o1"/> <input> <mime:content type="application/x-www-form-urlencoded"/> </input> <output> <mime:content type="image/gif"/> <mime:content type="image/jpeg"/> </output>

18 </operation> </binding> </definitions> Żądanie/Odpowiedź w HTML z wykorzystaniem SOAP (usługa wspiera pojedynczą operację GetLastTradePrice) <?xml version="1.0"?> <definitions name="stockquote" targetnamespace=" xmlns:tns=" xmlns:xsd1=" xmlns:soap=" xmlns=" <types> <schema targetnamespace=" xmlns=" <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"/>

19 </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=" <operation name="getlasttradeprice"> <soap:operation soapaction=" <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=" </port> </service> </definitions> 3.4. Wady i zalety stosowania WSDL Zalety stosowania WSDL: standardowy format opisu usług możliwość wykorzystania w wielu różnych technologiach i systemach komputerowych zrozumiały interfejs wykorzystywany przy definiowaniu usług

20 łatwy w użyciu automatyzacja komunikacji między usługami szybsze udostępnianie i aktualizacja oprogramowania W przyszłości narzędzia WSDL umożliwią generowanie kodu w Javie, C/C++, Corba, IDL, EJB, COM, COM, SOAP/HTTP i SOAP przez i zapewnią realizację dowolnego rodzaju przyłączy. Kod będzie generowany zarówno po stronie serwera, jak i klienta. Serwisy WWW już teraz dają możliwość uaktywnienia przyłącza. Do wad można zaliczyć: problemy z bezpieczeństwem (to dodatkowy protokół obsługi, który trzeba zabezpieczyć) problemy z autoryzacją niezbyt duża wydajność jest jeszcze dość młodym protokołem, podlega rozwojowi i zmianom Problemy związane z zapewnieniem bezpieczeństwa to największa przeszkoda w komercyjnym wykorzystaniu usług sieciowych. WSDL to kolejna warstwa pośrednia, która wymaga odpowiednich zabezpieczeń. Więcej warstw oznacza więcej możliwości dla hakerów. Język WSDL jest przydatny, jeśli wiadomo jaka usługa Web Service jest potrzebna. Nie umożliwia natomiast odnajdowania i przeszukiwania usług. Do tego służą inne protokoły. Nie jest to zbyt wygodne (konieczne zapewnienie współpracy między protokołami). 4. Protokół UDDI 4.1. Do czego służy UDDI Głównym zadaniem UDDI (The Universal Description, Discovery and Integration) jest stworzenie niezależnego od platformy, otwartego rozwiązania do odnajdywania usług sieciowych. UDDI to globalny rejestr usług udostępniający klientom mechanizmy dynamicznego wyszukiwania innych usług Web. UDDI stanowi interfejs umożliwiający dynamiczne połączenie się z usługą udostępnianą przez innego usługodawcę. Projekt UDDI często określany jako DNS dla biznesu. UDDI jest bowiem usługą katalogową przechowującą opisy i lokalizacje Web Services zarejestrowanych przez dostawców. Wyszukiwanie usług jest podobne do działania wyszukiwarek internetowych. UDDI posiadają dwa rodzaje klientów:

21 usługodawców publikujących swoje usługi klientów pragnących skorzystać z tych usług. Projekt UDDI wykorzystuje standardy W3C (WorldWide Web Consorcium) oraz IETF (Internet Engineering Task Force), takie jak: XML (Extensible Markup Language), protokoły HTTP oraz DNS (Domain Name System). Warstwa UDDI leży nad protokołem SOAP, przez co komunikaty UDDI stanowią obiekty w komunikatach SOAP. Usługi opisywane są przez WSDL. Projekt UDDI promują m.in. Ariba, IBM, Intel, Microsoft, SAP i Sun, lecz nie ma on jeszcze własnej grupy roboczej w W3C (World Wide Web Consorcium). UDDI nie jest związany z WSDL czy ebxml, ale w jego katalogach opisuje się najczęściej usługi oparte na WSDL. Publiczne katalogi UDDI udostępniły m.in. firmy Microsoft, IBM i XMethods. Opracowanie dotyczące UDDI oparte jest na informacjach umieszczonych na stronie Elementy protokołu UDDI W UDDI istotna jest kategoryzacja firm - musi ona umożliwiać wyszukanie firmy o ściśle określonym profilu działalności. Specyfikacja UDDI opisuje również sposób wymiany danych pomiędzy serwerami, które mogą tworzyć sieć węzłów. Rejestry UDDI zawierają: informacje o webservices na bazie nazwy usługodawcy, jego adresu, kategorii biznesowej czy informacji technicznej itp., operacje dotyczące usługi Web tj. rejestracji, wyszukiwania i korzystania z usługi szczegóły udostępniane przez niskopoziomowe API W UDDI informacje zawarte są w czterech różnych strukturach, zapewniających funkcjonalność: businessentity struktura umożliwiająca wyszukiwanie według biznesu businessservice struktura umożliwiająca wyszukiwanie według usługi biznesowej bindingtemplate struktura umożliwiająca wyszukiwanie według wiązania tmodel struktura umożliwiająca wyszukiwanie według usługi Web Services W UDDI wykorzystuje się model zapytania drążącego: Wykorzystanie zapytań find_x w celu uzyskania ogólnych informacji xlists Uzyskanie szczegółów przy pomocy zapytania get_xdetail

22 4.3. Przykład zastosowania UDDI W Polsce testowy katalog UDDI uruchomiła firma T-Systems na wortalu technologicznym który udostępnia też testowe usługi sieciowe i aplikacje pokazujące sposób działania tej technologii. Istnieje już kilka rozwiązań, również open source, pozwalających na uruchomienie własnego węzła UDDI. Z reguły implementacje katalogów UDDI oferują dostęp zarówno przez strony WWW, jak i przez protokół SOAP - dzięki temu przyszłe systemy będą mogły automatycznie wyszukiwać potrzebne im usługi. Pojedynczy wpis w repozytorium UDDI dostępnym w wortalu e-kompas.pl zawiera trzy poziomy informacji: nazwę firmy, jej podstawowe dane adresowe kategorię spis usług biznesowych udostępnianych przez jej systemy wraz z ich definicją Dzięki istniejącym już repozytoriom UDDI i Web Services już dziś można uzyskać rozkłady lotów, notowania giełdowe czy najnowsze wiadomości w sposób umożliwiający automatyczne wykorzystywanie przez własne oprogramowanie. Docelowym zastosowaniem UDDI ma być tworzenie otwartych lub zamkniętych e-marketplace, udostępnianie partnerom biznesowym informacji i procesów dla ich systemów czy integracja systemów wewnątrz przedsiębiorstwa Wady i zalety stosowania UDDI UDDI jest rozległą inicjatywą umożliwiającą systemom biznesowym odkrywanie siebie nawzajem oraz definiowanie sposobów interakcji poprzez Internet. Standard UDDI definiuje również sposoby replikacji pomiędzy repozytoriami. Obsługa UDDI powinna być integralną częścią systemów biznesowych, dzięki czemu będą one potrafiły łatwo, w sposób dynamiczny i przede wszystkim szybko, znaleźć inne systemy i współdziałać z nimi. 5. Zakończenie 5.1. Współpraca protokołów SOAP, WSDL i UDDI Protokół SOAP umożliwia wywoływanie i wykonywanie usług Web Services, publikowanych za pomocą WSDL i wyszukiwanych za pośrednictwem rejestru UDDI. Wykorzystywanie protokołu SOAP do wywoływania i wykonywania aplikacji poprzez Internet i korporacyjne zapory ogniowe umożliwia przedsiębiorstwom bezpieczną integrację własnych procesów biznesowych z procesami partnerów i dostawców.

23 Korzystanie z usług przebiega w następujący sposób: 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) PRZYKŁAD: Wymiana usług WWW pomiędzy dwiema aplikacjami może wyglądać następująco: 1. Przedsiębiorstwo A opisuje swoją usługę WWW poprzez WSDL; usługa jest rejestrowana w UDDI. 2. Przedsiębiorstwo B, chcące skorzystać z usługi, sięga do definicji WSDL, znajduje ją poprzez klienta SOAP w UDDI i pobiera w postaci pliku XML. Na koniec generuje komunikat SOAP. 3. Serwer SOAP przetwarza otrzymany plik XML i kieruje do "zainteresowanej" aplikacji Bezpieczeństwo Web Services Problemy z bezpieczeństwem jest to największa przeszkoda w komercyjnym wykorzystaniu usług sieciowych. Usługi sieciowe wprowadzają bowiem trzy lub cztery dodatkowe warstwy pośrednie, które wymagają odpowiednich zabezpieczeń. Więcej warstw oznacza więcej możliwości dla hakerów. Jako rozwiązanie tego problemu proponuje się stworzenie pojedynczego standardu. Taką próbą jest Microsoft.NET Passport. Najbardziej istotnym elementem bezpieczeństwa jest identyfikacja użytkownika, bowiem

24 udostępniając usługi w Internecie, zezwalamy na korzystanie z nich w dowolny sposób. Aby ograniczyć dostęp do konkretnych usług, wystarczy zastosować kod (np. w postaci parametru wywołania usługi) umożliwiający dostęp tylko autoryzowanemu użytkownikowi. Bezpieczeństwo transmisji zapewnia SSL użyty w niższych warstwach protokołu. W przypadku powszechnie dostępnych usług, gdy nie ma możliwości przekazania kodu dostępu, konieczne jest zastosowanie innych metod uwierzytelniających. Microsoft stara się narzucić usługę autoryzacyjną MS Passport, która jest kluczowym elementem platformy.net My Services. Zasadność powierzenia bazy informacji o użytkownikach jednej, komercyjnej firmie podważa Sun - firma ta powołała do życia konkurencyjny projekt The Liberty Alliance, zrzeszający: Apache Software Group, NTT DoCoMo, Bank of America, ebay, Real Networks, Nokia i RSA Security. Obie koncepcje dążą do zbudowania bazy informacji o użytkownikach Sieci, ich danych osobowych i preferencjach. Projekty te są jeszcze mało zaawansowane, trudno więc w tej chwili ocenić ich przydatność dla usług sieciowych. Przy nawiązywaniu kontaktów biznesowych ważną rolę spełnią inicjatywy w rodzaju Identrus - organizacji zrzeszającej grupę dużych banków, m.in. Bank of America, Barclays, Chase Manhattan, Citigroup, Deutsche Bank i mającej poparcie wielu producentów oprogramowania. Identyfikator Identrus Global ID umożliwia globalną identyfikację firmy za pomocą klucza publicznego (PKI) i uwiarygodnianie jej jako kontrahenta. Dzięki temu można elektronicznie tworzyć bezpieczne, otwarte rynki i poważnie angażować się w integrację B2B o zasięgu globalnym. Standard ebxml jako podstawa integracji B2B zwiększa bezpieczeństwo takiego rozwiązania, ponieważ wymaga na przykład podpisania przez przedstawicieli firm umowy o integracji systemów Przyszłość Web Services Jeżeli chodzi o przyszłość usług sieciowych, to jest to jedna z metod pozwalająca na szybsze udostępnianie i aktualizację oprogramowania. 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. Przy wystąpieniu określonego zdarzenia, np. wyczerpaniu zapasu puszek w automacie z napojami, ulokowana w nim usługa skontaktuje się z usługą czuwającą w firmie odpowiedzialnej za dostarczanie napojów do automatów. Architektura Web Services nie jest jeszcze kompletna. Jednym z istotnych problemów jest potrzeba zwiększenia wydajności tej technologii.

25 Firmy IBM, Microsoft i Ariba implementują dla usług Web Services publiczny globalny rejestr UBR (Universal Business Registry). Ma on służyć jako centralne repozytorium i obejmować wszystkie (niezależnie od wielkości) firmy, które chcą zarejestrować swoją działalność oraz poszukują produktów lub usług oferowanych przez inne podmioty. UBR umożliwi publikację usług Web Services poprzez proste wypełnienie dostępnego on-line formularza. Po rozpowszechnieniu usług Web Services rejestr UBR ma pomagać przedsiębiorstwom we wzajemnej lokalizacji oraz przekazywaniu informacji o ofertach. W planach firmy IBM jest zbudowanie kompletnego środowiska Application Framework for Web Services. Trwają dalsze prace rozwojowe nad standardem, dotyczące przede wszystkim dynamicznego wyszukiwania usług podczas pracy aplikacji. Inne prace koncentrują się na umożliwieniu wykorzystania w technologii Web Services także języków skryptowych, takich jak JavaScript czy REXX. W tym celu musi być, między innymi, zmodyfikowana specyfikacja SOAP. Na świecie koncepcja usług Web Services jest w ostatnim czasie szeroko promowana i spotyka się z coraz większym zainteresowaniem. Czołowe firmy oferują za darmo zestawy narzędzi, które pozwalają programistom szybko budować oraz implementować Web Services. Możliwe jest też przekształcanie istniejących komponentów (np. COM czy JavaBeans) w usługi Web Services. Na nowej technologii usług internetowych bazuje platforma Microsoft.NET, natomiast IBM rozwija nieodpłatne narzędzia w kategorii Alphaworks. Już teraz komponenty napisane w Visual Basicu mogą być łatwo wdrożone jako Web Services, a następnie bez przeszkód wywoływane przez usługi zbudowane np. z wykorzystaniem technologii VisualAge firmy IBM. W przyszłości usługi Web Services będą zapewne powszechnie stosowane do przekazywania informacji biznesowych (np. wyników notowań giełdowych) partnerom i klientom, integracji z zapewnieniem pracy transakcyjnej w takich zastosowaniach, jak obsługa giełd i systemy rezerwacji, czy nawet do decentralizacji i przenoszenia procesów biznesowych na zewnątrz przedsiębiorstwa. W tym ostatnim wypadku usługi Web Services będą wykorzystywane do swobodnej, dynamicznej integracji między procesami należącymi do różnych podmiotów gospodarczych. Można sobie też wyobrazić, że w przyszłości aplikacje biznesowe klasy B2B, pracujące w Internecie, będą budowane z usług Web Services wybieranych dynamicznie podczas realizacji procedur biznesowych, z uwzględnieniem dostępności, kosztów czy funkcjonalności (jakości). Literatura John Paul Mueller "Poznaj SOAP" Wydawnictwo Mikom

Simple Object Access Protocol

Simple Object Access Protocol Simple Object Access Protocol Bartłomiej Świercz Katedra Mikroelektroniki i Technik Informatycznych Łódź, 11 grudnia 2005 roku Czym jest SOAP? Akronim SOAP oznacza Simple Object Access Protocol. SOAP jest

Bardziej szczegółowo

Komunikacja i wymiana danych

Komunikacja i wymiana danych Budowa i oprogramowanie komputerowych systemów sterowania Wykład 10 Komunikacja i wymiana danych Metody wymiany danych Lokalne Pliki txt, csv, xls, xml Biblioteki LIB / DLL DDE, FastDDE OLE, COM, ActiveX

Bardziej szczegółowo

Kurs OPC S7. Spis treści. Dzień 1. I OPC motywacja, zakres zastosowań, podstawowe pojęcia dostępne specyfikacje (wersja 1501)

Kurs OPC S7. Spis treści. Dzień 1. I OPC motywacja, zakres zastosowań, podstawowe pojęcia dostępne specyfikacje (wersja 1501) Spis treści Dzień 1 I OPC motywacja, zakres zastosowań, podstawowe pojęcia dostępne specyfikacje (wersja 1501) I-3 O czym będziemy mówić? I-4 Typowe sytuacje I-5 Klasyczne podejście do komunikacji z urządzeniami

Bardziej szczegółowo

Rozproszone systemy Internetowe

Rozproszone systemy Internetowe Rozproszone systemy Internetowe Transport komunikatów WS: protokół SOAP RSI Oskar Świda 1 Simple Object Access Protocol Bezstanowy protokół komunikacyjny, oparty na standardzie XML Prosty i elastyczny,

Bardziej szczegółowo

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ EMAIL DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP WERSJA 1 z 15 Spis treści 1. Kanał email dla podmiotów zewnętrznych...

Bardziej szczegółowo

Spis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7

Spis treści. Dzień 1. I Wprowadzenie (wersja 0906) II Dostęp do danych bieżących specyfikacja OPC Data Access (wersja 0906) Kurs OPC S7 I Wprowadzenie (wersja 0906) Kurs OPC S7 Spis treści Dzień 1 I-3 O czym będziemy mówić? I-4 Typowe sytuacje I-5 Klasyczne podejście do komunikacji z urządzeniami automatyki I-6 Cechy podejścia dedykowanego

Bardziej szczegółowo

Programowanie Komponentowe WebAPI

Programowanie Komponentowe WebAPI Programowanie Komponentowe WebAPI dr inż. Ireneusz Szcześniak jesień 2016 roku WebAPI - interfejs webowy WebAPI to interfejs aplikacji (usługi, komponentu, serwisu) dostępnej najczęściej przez Internet,

Bardziej szczegółowo

Wybrane działy Informatyki Stosowanej

Wybrane działy Informatyki Stosowanej Wybrane działy Informatyki Stosowanej Java Enterprise Edition. WebServices. Język XML. Serwer aplikacji GlassFish. Dr inż. Andrzej Czerepicki a.czerepicki@wt.pw.edu.pl http://www2.wt.pw.edu.pl/~a.czerepicki

Bardziej szczegółowo

Wybrane działy Informatyki Stosowanej

Wybrane działy Informatyki Stosowanej Wybrane działy Informatyki Stosowanej Java Enterprise Edition WebServices Serwer aplikacji GlassFish Dr hab. inż. Andrzej Czerepicki a.czerepicki@wt.pw.edu.pl http://www2.wt.pw.edu.pl/~a.czerepicki Aplikacje

Bardziej szczegółowo

Część I -ebxml. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz

Część I -ebxml. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz Część I -ebxml Po zrealizowaniu materiału student będzie w stanie omówić potrzeby rynku B2B w zakresie przeprowadzania transakcji przez Internet zaprezentować architekturę ebxml wskazać na wady i zalety

Bardziej szczegółowo

Serwery. Autorzy: Karol Czosnowski Mateusz Kaźmierczak

Serwery. Autorzy: Karol Czosnowski Mateusz Kaźmierczak Serwery Autorzy: Karol Czosnowski Mateusz Kaźmierczak Czym jest XMPP? XMPP (Extensible Messaging and Presence Protocol), zbiór otwartych technologii do komunikacji, czatu wieloosobowego, rozmów wideo i

Bardziej szczegółowo

Programowanie współbieżne i rozproszone

Programowanie współbieżne i rozproszone Programowanie współbieżne i rozproszone WYKŁAD 11 dr inż. CORBA CORBA (Common Object Request Broker Architecture) standard programowania rozproszonego zaproponowany przez OMG (Object Management Group)

Bardziej szczegółowo

Programowanie komponentowe

Programowanie komponentowe Piotr Błaszyński Wydział Informatyki Zachodniopomorskiego Uniwersytetu Technologicznego 25 października 2014 WebService, (usługi sieciowe) - komponenty aplikacji webowych, zawierające logike biznesową.

Bardziej szczegółowo

Web Services. Wojciech Mazur. 17 marca 2009. Politechnika Wrocławska Wydział Informatyki i Zarządzania

Web Services. Wojciech Mazur. 17 marca 2009. Politechnika Wrocławska Wydział Informatyki i Zarządzania Standardy w Rodzaje Przykłady Politechnika Wrocławska Wydział Informatyki i Zarządzania 17 marca 2009 Standardy w Rodzaje Przykłady Plan prezentacji 1 Wstęp 2 Standardy w 3 4 Rodzaje 5 Przykłady 6 Standardy

Bardziej szczegółowo

Ministerstwo Finansów

Ministerstwo Finansów Ministerstwo Finansów Departament Informatyzacji Specyfikacja Wejścia-Wyjścia Wersja 1.0 Warszawa, 16.02.2017 r. Copyright (c) 2017 Ministerstwo Finansów MINISTERSTWO FINANSÓW, DEPARTAMENT INFORMATYZACJI

Bardziej szczegółowo

Systemy obiegu informacji i Protokół SWAP "CC"

Systemy obiegu informacji i Protokół SWAP CC Systemy obiegu informacji i Protokół SWAP Grzegorz Blinowski "CC" Grzegorz.Blinowski@cc.com.pl http://www.cc.com.pl/ tel (22) 646-68-73; faks (22) 606-37-80 Problemy Integracja procesów zachodzących w

Bardziej szczegółowo

Programowanie obiektowe

Programowanie obiektowe Programowanie obiektowe Wykład 13 Marcin Młotkowski 27 maja 2015 Plan wykładu Trwałość obiektów 1 Trwałość obiektów 2 Marcin Młotkowski Programowanie obiektowe 2 / 29 Trwałość (persistence) Definicja Cecha

Bardziej szczegółowo

TWÓJ BIZNES. Nasz Obieg Dokumentów

TWÓJ BIZNES. Nasz Obieg Dokumentów 1 Innowacyjny System Elektronicznego Obiegu Dokumentów i Spraw opracowany przez firmę WASKO S.A., na podstawie wieloletnich doświadczeń zdobytych na rynku systemów teleinformatycznych. TWÓJ BIZNES Nasz

Bardziej szczegółowo

Dostęp do komponentów EJB przez usługi Web Services

Dostęp do komponentów EJB przez usługi Web Services 243 Dostęp do komponentów EJB przez usługi Web Services Mikołaj Morzy Mikolaj.Morzy@cs.put.poznan.pl http://www.cs.put.poznan.pl/mmorzy/ Plan rozdziału 244 Wprowadzenie do usług sieciowych Architektura

Bardziej szczegółowo

CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI

CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI CENTRUM PROJEKTÓW INFORMATYCZNYCH MINISTERSTWA SPRAW WEWNĘTRZNYCH I ADMINISTRACJI Instrukcja użytkownika Narzędzie do modelowania procesów BPEL Warszawa, lipiec 2009 r. UNIA EUROPEJSKA EUROPEJSKI FUNDUSZ

Bardziej szczegółowo

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV Piotr Jarosik, Kamil Jaworski, Dominik Olędzki, Anna Stępień Dokumentacja wstępna TIN Rozproszone repozytorium oparte o WebDAV 1. Wstęp Celem projektu jest zaimplementowanie rozproszonego repozytorium

Bardziej szczegółowo

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus

Automatyzacja procesów biznesowych Andrzej Sobecki. ESB Enterprise service bus Automatyzacja procesów biznesowych Andrzej Sobecki ESB Enterprise service bus Plan prezentacji Zdefiniowanie problemu Możliwe rozwiązania Cechy ESB JBI Normalizacja wiadomości w JBI Agile ESB Apache ServiceMix

Bardziej szczegółowo

Stan zaawansowania prac dotyczących zamówienia na opracowanie i wdrożenie rdzenia systemu e Urząd.

Stan zaawansowania prac dotyczących zamówienia na opracowanie i wdrożenie rdzenia systemu e Urząd. Stan zaawansowania prac dotyczących zamówienia na opracowanie i wdrożenie rdzenia systemu e Urząd. Andrzej Natuniewicz, Andrzej Perkowski Departament Geodezji i Kartografii Urząd Marszałkowski Województwa

Bardziej szczegółowo

Web Services. Bartłomiej Świercz. Łódź, 2 grudnia 2005 roku. Katedra Mikroelektroniki i Technik Informatycznych. Bartłomiej Świercz Web Services

Web Services. Bartłomiej Świercz. Łódź, 2 grudnia 2005 roku. Katedra Mikroelektroniki i Technik Informatycznych. Bartłomiej Świercz Web Services Web Services Bartłomiej Świercz Katedra Mikroelektroniki i Technik Informatycznych Łódź, 2 grudnia 2005 roku Wstęp Oprogramowanie napisane w różnych językach i uruchomione na różnych platformach może wykorzystać

Bardziej szczegółowo

4 Web Forms i ASP.NET...149 Web Forms...150 Programowanie Web Forms...150 Możliwości Web Forms...151 Przetwarzanie Web Forms...152

4 Web Forms i ASP.NET...149 Web Forms...150 Programowanie Web Forms...150 Możliwości Web Forms...151 Przetwarzanie Web Forms...152 Wstęp...xv 1 Rozpoczynamy...1 Co to jest ASP.NET?...3 W jaki sposób ASP.NET pasuje do.net Framework...4 Co to jest.net Framework?...4 Czym są Active Server Pages (ASP)?...5 Ustawienia dla ASP.NET...7 Systemy

Bardziej szczegółowo

Typy przetwarzania. Przetwarzanie zcentralizowane. Przetwarzanie rozproszone

Typy przetwarzania. Przetwarzanie zcentralizowane. Przetwarzanie rozproszone Typy przetwarzania Przetwarzanie zcentralizowane Systemy typu mainfame Przetwarzanie rozproszone Architektura klient serwer Architektura jednowarstwowa Architektura dwuwarstwowa Architektura trójwarstwowa

Bardziej szczegółowo

Wprowadzenie do technologii Web Services: SOAP, WSDL i UDDI

Wprowadzenie do technologii Web Services: SOAP, WSDL i UDDI Wprowadzenie do technologii Web Services: SOAP, WSDL i UDDI Maciej Zakrzewicz PLOUG mzakrz@cs.put.poznan.pl Plan prezentacji Wprowadzenie do architektury zorientowanej na usługi Charakterystyka technologii

Bardziej szczegółowo

1 Wprowadzenie do J2EE

1 Wprowadzenie do J2EE Wprowadzenie do J2EE 1 Plan prezentacji 2 Wprowadzenie do Java 2 Enterprise Edition Aplikacje J2EE Serwer aplikacji J2EE Główne cele V Szkoły PLOUG - nowe podejścia do konstrukcji aplikacji J2EE Java 2

Bardziej szczegółowo

SOA Web Services in Java

SOA Web Services in Java Wydział Informatyki i Zarządzania Wrocław,16 marca 2009 Plan prezentacji SOA 1 SOA 2 Usługi Przykłady Jak zacząć SOA Wycinek rzeczywistości Problemy zintegrowanych serwisów : Wycinek Rzeczywistości Zacznijmy

Bardziej szczegółowo

76.Struktura oprogramowania rozproszonego.

76.Struktura oprogramowania rozproszonego. 76.Struktura oprogramowania rozproszonego. NajwaŜniejsze aspekty obiektowego programowania rozproszonego to: Współdziałanie (interoperability) modułów programowych na róŝnych maszynach. Wielokrotne wykorzystanie

Bardziej szczegółowo

Wybrane działy Informatyki Stosowanej

Wybrane działy Informatyki Stosowanej Wybrane działy Informatyki Stosowanej Dr inż. Andrzej Czerepicki a.czerepicki@wt.pw.edu.pl http://www2.wt.pw.edu.pl/~a.czerepicki 2017 Globalna sieć Internet Koncepcja sieci globalnej Usługi w sieci Internet

Bardziej szczegółowo

Tworzenie i wykorzystanie usług sieciowych

Tworzenie i wykorzystanie usług sieciowych Ćwiczenie 14 Temat: Tworzenie i wykorzystanie usług sieciowych Cel ćwiczenia: W trakcie ćwiczenia student zapozna się z procedurą tworzenia usługi sieciowej w technologii ASP.NET oraz nauczy się tworzyć

Bardziej szczegółowo

Wykład 3 / Wykład 4. Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak

Wykład 3 / Wykład 4. Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak Wykład 3 / Wykład 4 Na podstawie CCNA Exploration Moduł 3 streszczenie Dr inż. Robert Banasiak 1 Wprowadzenie do Modułu 3 CCNA-E Funkcje trzech wyższych warstw modelu OSI W jaki sposób ludzie wykorzystują

Bardziej szczegółowo

DOTACJE NA INNOWACJE

DOTACJE NA INNOWACJE Strzyżów, 29-05-2013 Ogłoszenie o zamówieniu kompleksowego wdrożenia systemu B2B do współpracy handlowej pomiędzy firmą Triton a Partnerami Zamawiający: TRITON S.C. Marcin Bosek, Janusz Rokita ul. Słowackiego

Bardziej szczegółowo

Wywoływanie metod zdalnych

Wywoływanie metod zdalnych Wywoływanie metod zdalnych model systemu Wywoływanie metod zdalnych aplikacja kliencka interfejs obiekt serwer Podejście obiektowe do budowy systemów rozproszonych proxy szkielet sieć Istota podejścia

Bardziej szczegółowo

Propozycja standaryzacji usługi lokalizacji adresu

Propozycja standaryzacji usługi lokalizacji adresu dr inż. Waldemar Izdebski 1,2 mgr inż. Andrzej Bielasty 2 Propozycja standaryzacji usługi lokalizacji adresu Numery adresowe są jednym z najprostszych elementów danych przestrzennych. Niemniej jednak są

Bardziej szczegółowo

Komunikacja międzysystemowa

Komunikacja międzysystemowa Komunikacja międzysystemowa REST API 06.12.2017 Karol Buler O czym będzie? O komunikacji ogólnie Application programming interface (API) Wybrane metody komunikacji REST API JavaScript Object Notation (JSON)

Bardziej szczegółowo

Narzędzia i aplikacje Java EE. Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl

Narzędzia i aplikacje Java EE. Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl Narzędzia i aplikacje Java EE Usługi sieciowe Paweł Czarnul pczarnul@eti.pg.gda.pl Niniejsze opracowanie wprowadza w technologię usług sieciowych i implementację usługi na platformie Java EE (JAX-WS) z

Bardziej szczegółowo

SOAP. Autor: Piotr Sobczak

SOAP. Autor: Piotr Sobczak SOAP Autor: Piotr Sobczak AGENDA: Trochę o Web Services Wprowadzenie do SOAP Anatomia komunikatu SOAP Wysyłanie i otrzymywanie komunikatu SOAP oraz API Javy w przykładach SOAP z załącznikami SOAP-RPC Obsługa

Bardziej szczegółowo

Zaawansowane narzędzia programowania rozproszonego

Zaawansowane narzędzia programowania rozproszonego Zaawansowane narzędzia programowania rozproszonego Karol Gołąb karol.golab@tls-technologies.com 28 listopada 2001 1 Streszczenie Omówienie i porównanie popularnych standardów mechanizmów komunikacyjnych:

Bardziej szczegółowo

Spis treci. Dzie 1. I Wprowadzenie (wersja 0911) II Dostp do danych biecych specyfikacja OPC Data Access (wersja 0911)

Spis treci. Dzie 1. I Wprowadzenie (wersja 0911) II Dostp do danych biecych specyfikacja OPC Data Access (wersja 0911) I Wprowadzenie (wersja 0911) Kurs OPC Integracja i Diagnostyka Spis treci Dzie 1 I-3 O czym bdziemy mówi? I-4 Typowe sytuacje I-5 Klasyczne podejcie do komunikacji z urzdzeniami automatyki I-6 Cechy podejcia

Bardziej szczegółowo

Rozproszone systemy internetowe. Wprowadzenie. Koncepcja zdalnego wywołania procedury

Rozproszone systemy internetowe. Wprowadzenie. Koncepcja zdalnego wywołania procedury Rozproszone systemy internetowe Wprowadzenie. Koncepcja zdalnego wywołania procedury Zakres tematyczny przedmiotu Aplikacje rozproszone Technologie /standardy internetowe Programowanie obiektowe 2 Co będzie

Bardziej szczegółowo

Przykładowy dokument XML

Przykładowy dokument XML Przykładowy dokument XML DTD - wady Ograniczona kontrola nad strukturą dokumentów. Zbyt wysokopoziomowe typy danych: liczby, daty są zawsze reprezentowane jako tekst! Bardzo ogólne metody definiowania

Bardziej szczegółowo

Specyfikacja techniczna. mprofi Interfejs API

Specyfikacja techniczna. mprofi Interfejs API Warszawa 09.04.2015. Specyfikacja techniczna mprofi Interfejs API wersja 1.0.2 1 Specyfikacja techniczna mprofi Interfejs API wersja 1.0.2 WERSJA DATA STATUTS AUTOR 1.0.0 10.03.2015 UTWORZENIE DOKUMENTU

Bardziej szczegółowo

Protokoły sieciowe - TCP/IP

Protokoły sieciowe - TCP/IP Protokoły sieciowe Protokoły sieciowe - TCP/IP TCP/IP TCP/IP (Transmission Control Protocol / Internet Protocol) działa na sprzęcie rożnych producentów może współpracować z rożnymi protokołami warstwy

Bardziej szczegółowo

Serwery LDAP w środowisku produktów w Oracle

Serwery LDAP w środowisku produktów w Oracle Serwery LDAP w środowisku produktów w Oracle 1 Mariusz Przybyszewski Uwierzytelnianie i autoryzacja Uwierzytelnienie to proces potwierdzania tożsamości, np. przez: Użytkownik/hasło certyfikat SSL inne

Bardziej szczegółowo

World Wide Web? rkijanka

World Wide Web? rkijanka World Wide Web? rkijanka World Wide Web? globalny, interaktywny, dynamiczny, wieloplatformowy, rozproszony, graficzny, hipertekstowy - system informacyjny, działający na bazie Internetu. 1.Sieć WWW jest

Bardziej szczegółowo

Wstęp Budowa Serwlety JSP Podsumowanie. Tomcat. Kotwasiński. 1 grudnia 2008

Wstęp Budowa Serwlety JSP Podsumowanie. Tomcat. Kotwasiński. 1 grudnia 2008 Adam 1 grudnia 2008 Wstęp Opis Historia Apache kontener serwletów rozwijany w ramach projektu Apache jeden z bardziej popularnych kontenerów Web open source, Apache Software License rozwijany przez ASF

Bardziej szczegółowo

Systemy internetowe. Wykład 5 Architektura WWW. West Pomeranian University of Technology, Szczecin; Faculty of Computer Science

Systemy internetowe. Wykład 5 Architektura WWW. West Pomeranian University of Technology, Szczecin; Faculty of Computer Science Systemy internetowe Wykład 5 Architektura WWW Architektura WWW Serwer to program, który: Obsługuje repozytorium dokumentów Udostępnia dokumenty klientom Komunikacja: protokół HTTP Warstwa klienta HTTP

Bardziej szczegółowo

ActiveXperts SMS Messaging Server

ActiveXperts SMS Messaging Server ActiveXperts SMS Messaging Server ActiveXperts SMS Messaging Server to oprogramowanie typu framework dedykowane wysyłaniu, odbieraniu oraz przetwarzaniu wiadomości SMS i e-mail, a także tworzeniu własnych

Bardziej szczegółowo

Wywoływanie metod zdalnych

Wywoływanie metod zdalnych Wywoływanie metod zdalnych Podejście obiektowe do budowy systemów rozproszonych Wywoływanie metod zdalnych model systemu obiekt aplikacja kliencka interfejs serwer proxy szkielet sieć Istota podejścia

Bardziej szczegółowo

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Jerzy Brzeziński, Anna Kobusińska, Dariusz Wawrzyniak Instytut Informatyki Politechnika Poznańska Plan prezentacji 1 Architektura

Bardziej szczegółowo

serwisy W*S ERDAS APOLLO 2009

serwisy W*S ERDAS APOLLO 2009 serwisy W*S ERDAS APOLLO 2009 1 OGC (Open Geospatial Consortium, Inc) OGC jest międzynarodowym konsorcjum 382 firm prywatnych, agencji rządowych oraz uniwersytetów, które nawiązały współpracę w celu rozwijania

Bardziej szczegółowo

Instalacja SQL Server Express. Logowanie na stronie Microsoftu

Instalacja SQL Server Express. Logowanie na stronie Microsoftu Instalacja SQL Server Express Logowanie na stronie Microsoftu Wybór wersji do pobrania Pobieranie startuje, przechodzimy do strony z poradami. Wypakowujemy pobrany plik. Otwiera się okno instalacji. Wybieramy

Bardziej szczegółowo

Rozproszone systemy internetowe

Rozproszone systemy internetowe Projekt współfinansowany ze środków Unii Europejskiej w ramach Europejskiego Funduszu Społecznego Rozproszone systemy internetowe Wprowadzenie do usług WWW (Web Services) Podniesienie potencjału uczelni

Bardziej szczegółowo

MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI

MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI MINISTERSTWO SPRAW WEWNĘTRZNYCH I ADMINISTRACJI DEPARTAMENT INFORMATYZACJI ul. Wspólna 1/3 00-529 Warszawa ZASADY NAZEWNICTWA DOKUMENTÓW XML Projekt współfinansowany Przez Unię Europejską Europejski Fundusz

Bardziej szczegółowo

Deduplikacja danych. Zarządzanie jakością danych podstawowych

Deduplikacja danych. Zarządzanie jakością danych podstawowych Deduplikacja danych Zarządzanie jakością danych podstawowych normalizacja i standaryzacja adresów standaryzacja i walidacja identyfikatorów podstawowa standaryzacja nazw firm deduplikacja danych Deduplication

Bardziej szczegółowo

REFERAT PRACY DYPLOMOWEJ

REFERAT PRACY DYPLOMOWEJ REFERAT PRACY DYPLOMOWEJ Temat pracy: Projekt i implementacja środowiska do automatyzacji przeprowadzania testów aplikacji internetowych w oparciu o metodykę Behavior Driven Development. Autor: Stepowany

Bardziej szczegółowo

RPC Remote Procedural Call. Materiały do prezentacji można znaleźć na stronie: http://www.houp.info/rpc

RPC Remote Procedural Call. Materiały do prezentacji można znaleźć na stronie: http://www.houp.info/rpc RPC Remote Procedural Call Materiały do prezentacji można znaleźć na stronie: http://www.houp.info/rpc 1 Wprowadzenie Podstawowe założenia RPC: Program uruchamiany na maszynie A może wywołać procedurę

Bardziej szczegółowo

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych

Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław

Bardziej szczegółowo

epuap Opis standardowych elementów epuap

epuap Opis standardowych elementów epuap epuap Opis standardowych elementów epuap Projekt współfinansowany ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu Operacyjnego Innowacyjna Gospodarka SPIS TREŚCI SPIS TREŚCI...

Bardziej szczegółowo

Programowanie współbieżne i rozproszone

Programowanie współbieżne i rozproszone Programowanie współbieżne i rozproszone WYKŁAD 7 Jan Kazimirski 1 Programowanie serwisów WEB SOAP 2 Literatura Programming Web Services with SOAP, D. Tidwell, J. Snell, P. Kulchenko, O'Reilly, 2001 Understanding

Bardziej szczegółowo

extensible Markup Language, cz. 1 Marcin Gryszkalis, mg@fork.pl

extensible Markup Language, cz. 1 Marcin Gryszkalis, mg@fork.pl extensible Markup Language, cz. 1 Marcin Gryszkalis, mg@fork.pl Plan wykładu Wprowadzenie: historia rozwoju technik znakowania tekstu Motywacje dla prac nad XML-em Podstawowe koncepcje XML-a XML jako metajęzyk

Bardziej szczegółowo

Biorąc udział w projekcie, możesz wybrać jedną z 8 bezpłatnych ścieżek egzaminacyjnych:

Biorąc udział w projekcie, możesz wybrać jedną z 8 bezpłatnych ścieżek egzaminacyjnych: Egzaminy na plus Stres na minus! Zdawaj bezpłatne egzaminy Microsoft, Linux, C++ z nami i zadbaj o swoją karierę. Oferujemy Ci pierwsze certyfikaty zawodowe w Twojej przyszłej karierze, które idealnie

Bardziej szczegółowo

Usługi WWW. dr Zbigniew Lipiński Instytut Matematyki i Informatyki ul. Oleska 48 50-204 Opole zlipinski@math.uni.opole.pl

Usługi WWW. dr Zbigniew Lipiński Instytut Matematyki i Informatyki ul. Oleska 48 50-204 Opole zlipinski@math.uni.opole.pl Budowa aplikacji sieciowych. Usługi WWW dr Zbigniew Lipiński Instytut Matematyki i Informatyki ul. Oleska 48 50-204 Opole zlipinski@math.uni.opole.pl Usługi WWW W3C Working Group, Web Services Architecture,

Bardziej szczegółowo

Wypożyczalnia VIDEO. Technologie obiektowe

Wypożyczalnia VIDEO. Technologie obiektowe Wypożyczalnia VIDEO Jest to program do obsługi wypożyczalni i wypożyczeń klientów. Głównym zadaniem programu jest zarządzanie wypożyczeniami i drukowanie potwierdzenia wypożyczenia oraz naliczenie punktów

Bardziej szczegółowo

Web Services wykład 9

Web Services wykład 9 Uniwersytet Łódzki Wydział Matematyki i Informatyki, Katedra Analizy Nieliniowej Web Services wykład 9 Programowanie w Javie 2 mgr inż. Michał Misiak Agenda Ewolucja sieci komputerowych Co to jest Web

Bardziej szczegółowo

OfficeObjects e-forms

OfficeObjects e-forms OfficeObjects e-forms Rodan Development Sp. z o.o. 02-820 Warszawa, ul. Wyczółki 89, tel.: (+48-22) 643 92 08, fax: (+48-22) 643 92 10, http://www.rodan.pl Spis treści Wstęp... 3 Łatwość tworzenia i publikacji

Bardziej szczegółowo

RFP. Wymagania dla projektu. sklepu internetowego B2C dla firmy Oplot

RFP. Wymagania dla projektu. sklepu internetowego B2C dla firmy Oplot RFP Wymagania dla projektu sklepu internetowego B2C dla firmy Oplot CEL DOKUMENTU Celem niniejszego dokumentu jest przedstawienie wymagań technicznych i funkcjonalnych wobec realizacji projektu budowy

Bardziej szczegółowo

Mechanizmy pracy równoległej. Jarosław Kuchta

Mechanizmy pracy równoległej. Jarosław Kuchta Mechanizmy pracy równoległej Jarosław Kuchta Zagadnienia Algorytmy wzajemnego wykluczania algorytm Dekkera Mechanizmy niskopoziomowe przerwania mechanizmy ochrony pamięci instrukcje specjalne Mechanizmy

Bardziej szczegółowo

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki

Dariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki Dariusz Brzeziński Politechnika Poznańska, Instytut Informatyki Język programowania prosty bezpieczny zorientowany obiektowo wielowątkowy rozproszony przenaszalny interpretowany dynamiczny wydajny Platforma

Bardziej szczegółowo

Technologie dla aplikacji klasy enterprise. Wprowadzenie. Marek Wojciechowski

Technologie dla aplikacji klasy enterprise. Wprowadzenie. Marek Wojciechowski Technologie dla aplikacji klasy enterprise Wprowadzenie Marek Wojciechowski Co oznacza enterprise-ready? Bezpieczeństwo Skalowalność Stabilność Kompatybilność wstecz Wsparcie Dokumentacja Łatwość integracji

Bardziej szczegółowo

Zasady Nazewnictwa. Dokumentów XML 2007-11-08. Strona 1 z 9

Zasady Nazewnictwa. Dokumentów XML 2007-11-08. Strona 1 z 9 Zasady Nazewnictwa Dokumentów 2007-11-08 Strona 1 z 9 Spis treści I. Wstęp... 3 II. Znaczenie spójnych zasady nazewnictwa... 3 III. Zasady nazewnictwa wybrane zagadnienia... 3 1. Język oraz forma nazewnictwa...

Bardziej szczegółowo

Specyfikacja API Runtime BAS 3.0

Specyfikacja API Runtime BAS 3.0 Specyfikacja API Runtime BAS 3.0 Spis treści Wstęp... 4 Informacja o dokumencie... 4 Opis usługi... 4 Typowy sposób wywołania usługi... 5 Udostępniane funkcje... 6 Funkcje liczące... 6 Execute... 6 SafeExecute...

Bardziej szczegółowo

Wprowadzenie. Dariusz Wawrzyniak 1

Wprowadzenie. Dariusz Wawrzyniak 1 Dariusz Wawrzyniak Politechnika Poznańska Instytut Informatyki ul. Piotrowo 2 (CW, pok. 5) 60-965 Poznań Dariusz.Wawrzyniak@cs.put.poznan.pl Dariusz.Wawrzyniak@put.edu.pl www.cs.put.poznan.pl/dwawrzyniak

Bardziej szczegółowo

The Binder Consulting

The Binder Consulting The Binder Consulting Contents Indywidualne szkolenia specjalistyczne...3 Konsultacje dla tworzenia rozwiazan mobilnych... 3 Dedykowane rozwiazania informatyczne... 3 Konsultacje i wdrożenie mechanizmów

Bardziej szczegółowo

Mydło i spółka. Aplikacje rozproszone. Serwisy sieciowe Broker usług. Serwisy sieciowe. Serwisy sieciowe, WWW (Web Services) Internet

Mydło i spółka. Aplikacje rozproszone. Serwisy sieciowe Broker usług. Serwisy sieciowe. Serwisy sieciowe, WWW (Web Services) Internet Mydło i spółka Serwisy sieciowe Wybrane zagadnienia Systemów protokół Rozproszonych (Simple Object Access Protokol) Aplikacje rozproszone Po co (Aplikacje o): Po co (źródło): rozproszenie przetwarzania

Bardziej szczegółowo

Spis wzorców. Działania użytkownika Strona 147 Obsługa większości Działań użytkownika za pomocą kodu JavaScript przy użyciu metod obsługi zdarzeń.

Spis wzorców. Działania użytkownika Strona 147 Obsługa większości Działań użytkownika za pomocą kodu JavaScript przy użyciu metod obsługi zdarzeń. Spis wzorców Aplikacja Ajax Strona 73 Tworzenie Aplikacji Ajax złożonych aplikacji, które można uruchomić w dowolnej współczesnej przeglądarce internetowej. Bezpośrednie logowanie Strona 509 Uwierzytelnianie

Bardziej szczegółowo

Wykład 2: Budowanie sieci lokalnych. A. Kisiel, Budowanie sieci lokalnych

Wykład 2: Budowanie sieci lokalnych. A. Kisiel, Budowanie sieci lokalnych Wykład 2: Budowanie sieci lokalnych 1 Budowanie sieci lokalnych Technologie istotne z punktu widzenia konfiguracji i testowania poprawnego działania sieci lokalnej: Protokół ICMP i narzędzia go wykorzystujące

Bardziej szczegółowo

Architektury usług internetowych. Tomasz Boiński Mariusz Matuszek

Architektury usług internetowych. Tomasz Boiński Mariusz Matuszek Architektury usług internetowych 2016 Tomasz Boiński Mariusz Matuszek Organizacja przedmiotu 1. Wykład 2 kolokwia po 25 punktów (23 listopada i 27 stycznia) 2. 6 zadań laboratoryjnych, zadania 1-5 po 8

Bardziej szczegółowo

EXSO-CORE - specyfikacja

EXSO-CORE - specyfikacja EXSO-CORE - specyfikacja System bazowy dla aplikacji EXSO. Elementy tego systemu występują we wszystkich programach EXSO. Może on ponadto stanowić podstawę do opracowania nowych, dedykowanych systemów.

Bardziej szczegółowo

MODEL WARSTWOWY PROTOKOŁY TCP/IP

MODEL WARSTWOWY PROTOKOŁY TCP/IP MODEL WARSTWOWY PROTOKOŁY TCP/IP TCP/IP (ang. Transmission Control Protocol/Internet Protocol) protokół kontroli transmisji. Pakiet najbardziej rozpowszechnionych protokołów komunikacyjnych współczesnych

Bardziej szczegółowo

Web Services / Gridy

Web Services / Gridy Web Services / Gridy Autor: Dariusz Dwornikowski tdi@vercom.pl tdi@kill-9.pl Web Services - wstęp SOA/Web Services odpowiedź na potrzeby komercyjnego internetu pryzmat biznesowy Dariusz Dwornikowski 3

Bardziej szczegółowo

Forum Client - Spring in Swing

Forum Client - Spring in Swing Forum Client - Spring in Swing Paweł Charkowski. 0. Cel projektu Celem projektu jest próba integracji Spring Framework z różnymi technologiami realizacji interfejsu użytkownika, oraz jej ocena. Niniejszy

Bardziej szczegółowo

Wybrane działy Informatyki Stosowanej

Wybrane działy Informatyki Stosowanej Wybrane działy Informatyki Stosowanej Dr inż. Andrzej Czerepicki a.czerepicki@wt.pw.edu.pl http://www2.wt.pw.edu.pl/~a.czerepicki 2017 APLIKACJE SIECIOWE Definicja Architektura aplikacji sieciowych Programowanie

Bardziej szczegółowo

Web Services. Technologie Biznesu Elektronicznego. Konrad Kunicki. Politechnika Wrocławska, Wydział Informatyki i Zarządzania

Web Services. Technologie Biznesu Elektronicznego. Konrad Kunicki. Politechnika Wrocławska, Wydział Informatyki i Zarządzania Standardy Technologie Biznesu Elektronicznego Politechnika Wrocławska, Wydział Informatyki i Zarządzania Wrocław, 26 kwiecień 2005 Standardy Plan prezentacji 1 Wprowadzenie 2 Standardy 3 4 5 Standardy

Bardziej szczegółowo

Sieci komputerowe i bazy danych

Sieci komputerowe i bazy danych Akademia Górniczo-Hutnicza im. Stanisława Staszica w Krakowie Sieci komputerowe i bazy danych Sprawozdanie 5 Badanie protokołów pocztowych Szymon Dziewic Inżynieria Mechatroniczna Rok: III Grupa: L1 Zajęcia

Bardziej szczegółowo

Zaawansowane aplikacje internetowe. Wykład 6. Wprowadzenie do Web Services. wykład prowadzi: Maciej Zakrzewicz. Web Services

Zaawansowane aplikacje internetowe. Wykład 6. Wprowadzenie do Web Services. wykład prowadzi: Maciej Zakrzewicz. Web Services Wykład 6 Wprowadzenie do Web Services wykład prowadzi: Maciej Zakrzewicz Web Services 1 Plan wykładu Wprowadzenie do technologii Web Services Architektura Web Services Protokół komunikacyjny SOAP Język

Bardziej szczegółowo

DOKUMENTACJA INTERFEJSU API - HTTPS

DOKUMENTACJA INTERFEJSU API - HTTPS DOKUMENTACJA INTERFEJSU API - HTTPS WERSJA 0.1 DATA PUBLIKACJI : 01.03.2014 SPIS TREŚCI Spis treści Wprowadzenie 1 Dostęp do usługi notowania online 2 Opis struktur danych 3 Kody błędów 5 Historia wersji

Bardziej szczegółowo

Informacje wstępne Autor Zofia Kruczkiewicz Wzorce oprogramowania 4

Informacje wstępne Autor Zofia Kruczkiewicz Wzorce oprogramowania 4 Utrwalanie danych zastosowanie obiektowego modelu danych warstwy biznesowej do generowania schematu relacyjnej bazy danych Informacje wstępne Autor Zofia Kruczkiewicz Wzorce oprogramowania 4 1. Relacyjne

Bardziej szczegółowo

Bazy danych 2. Wykład 1

Bazy danych 2. Wykład 1 Bazy danych 2 Wykład 1 Sprawy organizacyjne Materiały i listy zadań zamieszczane będą na stronie www.math.uni.opole.pl/~ajasi E-mail: standardowy ajasi@math.uni.opole.pl Sprawy organizacyjne Program wykładu

Bardziej szczegółowo

XQTav - reprezentacja diagramów przepływu prac w formacie SCUFL przy pomocy XQuery

XQTav - reprezentacja diagramów przepływu prac w formacie SCUFL przy pomocy XQuery http://xqtav.sourceforge.net XQTav - reprezentacja diagramów przepływu prac w formacie SCUFL przy pomocy XQuery dr hab. Jerzy Tyszkiewicz dr Andrzej Kierzek mgr Jacek Sroka Grzegorz Kaczor praca mgr pod

Bardziej szczegółowo

GS2TelCOMM. Rozszerzenie do TelCOMM 2.0. Opracował: Michał Siatkowski Zatwierdził: IMIĘ I NAZWISKO

GS2TelCOMM. Rozszerzenie do TelCOMM 2.0. Opracował: Michał Siatkowski Zatwierdził: IMIĘ I NAZWISKO GS2TelCOMM Rozszerzenie do TelCOMM 2.0 Opracował: Michał Siatkowski 29-03-2017 Zatwierdził: IMIĘ I NAZWISKO DATA TEL-STER 2017 Spis treści Wprowadzenie... 3 Architektura... 3 Instalacja... 3 Współpraca

Bardziej szczegółowo

Sieci komputerowe. Wstęp

Sieci komputerowe. Wstęp Sieci komputerowe Wstęp Sieć komputerowa to grupa komputerów lub innych urządzeń połączonych ze sobą w celu wymiany danych lub współdzielenia różnych zasobów, na przykład: korzystania ze wspólnych urządzeń

Bardziej szczegółowo

HP Service Anywhere Uproszczenie zarządzania usługami IT

HP Service Anywhere Uproszczenie zarządzania usługami IT HP Service Anywhere Uproszczenie zarządzania usługami IT Robert Nowak Architekt rozwiązań HP Software Dlaczego Software as a Service? Najważniejsze powody za SaaS UZUPEŁNIENIE IT 2 Brak zasobów IT Ograniczone

Bardziej szczegółowo

5.14 JSP - Przykład z obiektami sesji... 83 5.15 Podsumowanie... 84 5.16 Słownik... 85 5.17 Zadanie... 86

5.14 JSP - Przykład z obiektami sesji... 83 5.15 Podsumowanie... 84 5.16 Słownik... 85 5.17 Zadanie... 86 Spis treści 1 Wprowadzenie - architektura, protokoły, system WWW... 1 1.1 Wstęp.................................................. 1 1.2 Ważniejsze daty......................................... 2 1.3 Protokoły

Bardziej szczegółowo

TWÓJ BIZNES. Nasze rozwiązanie

TWÓJ BIZNES. Nasze rozwiązanie Innowacyjny System Elektronicznego Obiegu Dokumentów i Spraw opracowany przez firmę WASKO S.A., na podstawie wieloletnich doświadczeń zdobytych na rynku systemów teleinformatycznych. TWÓJ BIZNES Nasze

Bardziej szczegółowo

Systemy rozproszone. na użytkownikach systemu rozproszonego wrażenie pojedynczego i zintegrowanego systemu.

Systemy rozproszone. na użytkownikach systemu rozproszonego wrażenie pojedynczego i zintegrowanego systemu. Systemy rozproszone Wg Wikipedii: System rozproszony to zbiór niezależnych urządzeń (komputerów) połączonych w jedną, spójną logicznie całość. Połączenie najczęściej realizowane jest przez sieć komputerową..

Bardziej szczegółowo