Przegl\u0105d<\/b>
\nProgramowanie oparte na komponentach sta\u0142o si\u0119 bardziej popularne ni\u017c kiedykolwiek. Prawie nie buduje si\u0119 dzi\u015b aplikacji, kt\u00f3ra nie wykorzystuje komponent\u00f3w w jakiej\u015b formie, zwykle od r\u00f3\u017cnych dostawc\u00f3w. Poniewa\u017c aplikacje sta\u0142y si\u0119 bardziej wyrafinowane, wzros\u0142a r\u00f3wnie\u017c potrzeba wykorzystania komponent\u00f3w rozproszonych na zdalnych maszynach.<\/p>\n
<\/p>\n
Przyk\u0142adem aplikacji opartej na komponentach jest kompleksowe rozwi\u0105zanie e-commerce. Aplikacja e-commerce rezyduj\u0105ca na farmie internetowej musi przesy\u0142a\u0107 zam\u00f3wienia do aplikacji planowania zasob\u00f3w przedsi\u0119biorstwa (ERP). W wielu przypadkach aplikacja ERP znajduje si\u0119 na innym sprz\u0119cie i mo\u017ce dzia\u0142a\u0107 na innym systemie operacyjnym.<\/p>\n
Microsoft Distributed Component Object Model (DCOM), rozproszona infrastruktura obiektowa, kt\u00f3ra umo\u017cliwia aplikacji wywo\u0142ywanie komponent\u00f3w Component Object Model (COM) zainstalowanych na innym serwerze, zosta\u0142a przeniesiona na wiele platform innych ni\u017c Windows. Jednak DCOM nigdy nie zyska\u0142 szerokiej akceptacji na tych platformach, wi\u0119c rzadko jest u\u017cywany do u\u0142atwienia komunikacji mi\u0119dzy komputerami z systemem Windows i innymi systemami. Dostawcy oprogramowania ERP cz\u0119sto tworz\u0105 komponenty dla platformy Windows, kt\u00f3re komunikuj\u0105 si\u0119 z systemem zaplecza za po\u015brednictwem zastrze\u017conego protoko\u0142u.<\/p>\n
Niekt\u00f3re us\u0142ugi wykorzystywane przez aplikacj\u0119 e-commerce mog\u0105 w og\u00f3le nie znajdowa\u0107 si\u0119 w centrum danych. Na przyk\u0142ad, je\u015bli aplikacja e-commerce akceptuje p\u0142atno\u015b\u0107 kart\u0105 kredytow\u0105 za towary zakupione przez klienta, musi wywo\u0142a\u0107 us\u0142ugi banku handlowego w celu przetworzenia informacji o karcie kredytowej klienta. Jednak ze wzgl\u0119d\u00f3w praktycznych DCOM i powi\u0105zane technologie, takie jak CORBA i Java RMI, s\u0105 ograniczone do aplikacji i komponent\u00f3w zainstalowanych w korporacyjnym centrum danych. Dwa g\u0142\u00f3wne powody tego s\u0105 takie, \u017ce domy\u015blnie technologie te wykorzystuj\u0105 zastrze\u017cone protoko\u0142y, a protoko\u0142y te s\u0105 z natury zorientowane na po\u0142\u0105czenia.<\/p>\n
Klienci komunikuj\u0105cy si\u0119 z serwerem przez Internet napotykaj\u0105 wiele potencjalnych barier w komunikacji z serwerem. \u015awiadomi bezpiecze\u0144stwa administratorzy sieci na ca\u0142ym \u015bwiecie wdro\u017cyli routery korporacyjne i zapory ogniowe, aby uniemo\u017cliwi\u0107 praktycznie ka\u017cdy rodzaj komunikacji przez Internet. Cz\u0119sto potrzeba aktu bo\u017cego, aby administrator sieci otworzy\u0142 porty poza absolutnym minimum.<\/p>\n
Je\u015bli masz wystarczaj\u0105co du\u017co szcz\u0119\u015bcia, aby administrator sieci otworzy\u0142 odpowiednie porty do obs\u0142ugi Twojej us\u0142ugi, prawdopodobnie Twoi klienci nie b\u0119d\u0105 mieli tyle szcz\u0119\u015bcia. W rezultacie zastrze\u017cone protoko\u0142y, takie jak te u\u017cywane przez DCOM, CORBA i Java RMI, nie s\u0105 praktyczne w scenariuszach internetowych.<\/p>\n
Jak ju\u017c wspomnia\u0142em, innym problemem zwi\u0105zanym z tymi technologiami jest to, \u017ce s\u0105 one z natury zorientowane na po\u0142\u0105czenia i dlatego nie s\u0105 w stanie sprawnie radzi\u0107 sobie z przerwami w sieci. Poniewa\u017c Internet nie jest pod bezpo\u015bredni\u0105 kontrol\u0105 u\u017cytkownika, nie mo\u017cna przyjmowa\u0107 \u017cadnych za\u0142o\u017ce\u0144 dotycz\u0105cych jako\u015bci lub niezawodno\u015bci po\u0142\u0105czenia. Je\u015bli wyst\u0105pi przerwa w sieci, nast\u0119pne po\u0142\u0105czenie klienta z serwerem mo\u017ce zako\u0144czy\u0107 si\u0119 niepowodzeniem.<\/p>\n
Zorientowany na po\u0142\u0105czenia charakter tych technologii sprawia r\u00f3wnie\u017c, \u017ce trudno jest zbudowa\u0107 infrastruktur\u0119 r\u00f3wnowa\u017c\u0105c\u0105 obci\u0105\u017cenie, niezb\u0119dn\u0105 do osi\u0105gni\u0119cia wysokiej skalowalno\u015bci. Po zerwaniu po\u0142\u0105czenia mi\u0119dzy klientem a serwerem nie mo\u017cna po prostu skierowa\u0107 nast\u0119pnego \u017c\u0105dania do innego serwera.<\/p>\n
Deweloperzy pr\u00f3bowali przezwyci\u0119\u017cy\u0107 te ograniczenia, wykorzystuj\u0105c model o nazwie bezpa\u0144stwowy <\/i>programowanie<\/i>, ale odnios\u0142y one ograniczony sukces, poniewa\u017c technologie te s\u0105 do\u015b\u0107 ci\u0119\u017ckie i sprawiaj\u0105, \u017ce ponowne nawi\u0105zanie po\u0142\u0105czenia ze zdalnym obiektem jest kosztowne.<\/p>\n
Poniewa\u017c przetwarzanie karty kredytowej klienta jest realizowane przez zdalny serwer w Internecie, DCOM nie jest idealny do u\u0142atwiania komunikacji mi\u0119dzy klientem e-commerce a serwerem przetwarzania kart kredytowych. Podobnie jak w przypadku rozwi\u0105zania ERP, komponent innej firmy jest cz\u0119sto instalowany w centrum danych klienta (w tym przypadku przez dostawc\u0119 rozwi\u0105zania do przetwarzania kart kredytowych). Komponent ten s\u0142u\u017cy jako niewiele wi\u0119cej ni\u017c proxy, kt\u00f3re u\u0142atwia komunikacj\u0119 mi\u0119dzy oprogramowaniem e-commerce a bankiem handlowym za po\u015brednictwem zastrze\u017conego protoko\u0142u.<\/p>\n
Czy widzisz tu jaki\u015b wz\u00f3r? Ze wzgl\u0119du na ograniczenia istniej\u0105cych technologii w u\u0142atwianiu komunikacji mi\u0119dzy systemami komputerowymi, producenci oprogramowania cz\u0119sto uciekaj\u0105 si\u0119 do budowania w\u0142asnej infrastruktury. Oznacza to, \u017ce zasoby, kt\u00f3re mog\u0142y zosta\u0107 wykorzystane do dodania ulepszonej funkcjonalno\u015bci do systemu ERP lub systemu przetwarzania kart kredytowych, zosta\u0142y zamiast tego po\u015bwi\u0119cone na pisanie zastrze\u017conych protoko\u0142\u00f3w sieciowych.<\/p>\n
Staraj\u0105c si\u0119 lepiej wspiera\u0107 takie scenariusze internetowe, Microsoft pocz\u0105tkowo przyj\u0105\u0142 strategi\u0119 rozszerzania istniej\u0105cych technologii, w tym COM Internet Services (CIS), kt\u00f3ra pozwala na ustanowienie po\u0142\u0105czenia DCOM mi\u0119dzy klientem a zdalnym komponentem przez port 80. Z r\u00f3\u017cnych powod\u00f3w CIS nie zosta\u0142 powszechnie zaakceptowany.<\/p>\n
Sta\u0142o si\u0119 jasne, \u017ce potrzebne jest nowe podej\u015bcie. Firma Microsoft postanowi\u0142a wi\u0119c rozwi\u0105za\u0107 ten problem oddolnie. Przyjrzyjmy si\u0119 niekt\u00f3rym wymaganiom, kt\u00f3re rozwi\u0105zanie musia\u0142o spe\u0142ni\u0107, aby odnie\u015b\u0107 sukces.<\/p>\n
Bior\u0105c pod uwag\u0119 tytu\u0142 tej ksi\u0105\u017cki, nie powinno dziwi\u0107, \u017ce rozwi\u0105zanie stworzone przez Microsoft jest znane jako Us\u0142ugi sieciowe<\/i>. Us\u0142uga sieciowa udost\u0119pnia interfejs do wywo\u0142ywania okre\u015blonego dzia\u0142ania w imieniu klienta. Klient mo\u017ce uzyska\u0107 dost\u0119p do us\u0142ugi sieci Web poprzez wykorzystanie standard\u00f3w internetowych.<\/p>\n
Bloki konstrukcyjne us\u0142ug sieciowych<\/b>
\nPoni\u017csza grafika przedstawia podstawowe bloki konstrukcyjne potrzebne do u\u0142atwienia zdalnej komunikacji mi\u0119dzy dwiema aplikacjami.<\/p>\n
Om\u00f3wmy cel ka\u017cdego z tych blok\u00f3w konstrukcyjnych. Poniewa\u017c wielu czytelnik\u00f3w zna DCOM, wspomn\u0119 r\u00f3wnie\u017c o odpowiedniku DCOM ka\u017cdego bloku konstrukcyjnego.<\/p>\n
Bez standardowego sposobu formatowania wiadomo\u015bci, opracowanie zestawu narz\u0119dzi abstrahuj\u0105cych dewelopera od podstawowych protoko\u0142\u00f3w jest prawie niemo\u017cliwe. Stworzenie warstwy abstrakcji mi\u0119dzy deweloperem a podstawowymi protoko\u0142ami pozwala deweloperowi skupi\u0107 si\u0119 bardziej na danym problemie biznesowym, a mniej na infrastrukturze wymaganej do wdro\u017cenia rozwi\u0105zania.<\/p>\n
Decyzje dotycz\u0105ce projektowania us\u0142ug internetowych<\/b><\/p>\n
Om\u00f3wmy niekt\u00f3re decyzje projektowe, kt\u00f3re stoj\u0105 za tymi elementami sk\u0142adowymi us\u0142ug internetowych.<\/p>\n
Wyb\u00f3r protoko\u0142\u00f3w transportowych<\/b><\/p>\n
Pierwszym krokiem by\u0142o ustalenie, w jaki spos\u00f3b klient i serwer b\u0119d\u0105 si\u0119 ze sob\u0105 komunikowa\u0107. Klient i serwer mog\u0105 znajdowa\u0107 si\u0119 w tej samej sieci LAN, ale klient mo\u017ce potencjalnie komunikowa\u0107 si\u0119 z serwerem przez Internet. Dlatego protok\u00f3\u0142 transportowy musi by\u0107 w r\u00f3wnym stopniu dostosowany zar\u00f3wno do \u015brodowisk sieci LAN, jak i do Internetu.<\/p>\n
Jak wspomnia\u0142em wcze\u015bniej, technologie takie jak DCOM, CORBA i Java RMI nie nadaj\u0105 si\u0119 do obs\u0142ugi komunikacji mi\u0119dzy klientem a serwerem przez Internet. Protoko\u0142y takie jak Hypertext Transfer Protocol (HTTP) i Simple Mail Transfer Protocol (SMTP) s\u0105 sprawdzonymi protoko\u0142ami internetowymi. Protok\u00f3\u0142 HTTP definiuje schemat komunikacji typu \u017c\u0105danie-odpowied\u017a s\u0142u\u017c\u0105cy do wysy\u0142ania \u017c\u0105da\u0144 i otrzymywania powi\u0105zanych odpowiedzi. Protok\u00f3\u0142 SMTP definiuje protok\u00f3\u0142 przesy\u0142ania wiadomo\u015bci z mo\u017cliwo\u015bci\u0105 routingu, przeznaczony do komunikacji asynchronicznej. Przyjrzyjmy si\u0119, dlaczego protoko\u0142y HTTP i SMTP dobrze sprawdzaj\u0105 si\u0119 w Internecie.<\/p>\n
Aplikacje internetowe oparte na protokole HTTP s\u0105 z natury bezstanowe. Nie wymagaj\u0105 one sta\u0142ego po\u0142\u0105czenia mi\u0119dzy klientem a serwerem. Dzi\u0119ki temu protok\u00f3\u0142 HTTP idealnie nadaje si\u0119 do konfiguracji zapewniaj\u0105cych wysok\u0105 dost\u0119pno\u015b\u0107, takich jak zapory sieciowe. Je\u015bli serwer, kt\u00f3ry obs\u0142u\u017cy\u0142 pierwotne \u017c\u0105danie klienta, stanie si\u0119 niedost\u0119pny, kolejne \u017c\u0105dania mog\u0105 by\u0107 automatycznie przekierowywane do innego serwera, a klient nie musi o tym wiedzie\u0107 ani si\u0119 tym przejmowa\u0107.<\/p>\n
Prawie wszystkie firmy dysponuj\u0105 infrastruktur\u0105 obs\u0142uguj\u0105c\u0105 protok\u00f3\u0142 SMTP. Protok\u00f3\u0142 SMTP doskonale nadaje si\u0119 do komunikacji asynchronicznej. W przypadku zak\u0142\u00f3ce\u0144 w dzia\u0142aniu us\u0142ugi infrastruktura pocztowa automatycznie podejmuje ponowne pr\u00f3by wys\u0142ania wiadomo\u015bci. W przeciwie\u0144stwie do protoko\u0142u HTTP, wiadomo\u015bci SMTP mo\u017cna przekaza\u0107 do lokalnego serwera pocztowego, kt\u00f3ry podejmie pr\u00f3b\u0119 dostarczenia wiadomo\u015bci w imieniu u\u017cytkownika.<\/p>\n
Kolejn\u0105 istotn\u0105 zalet\u0105 zar\u00f3wno protoko\u0142u HTTP, jak i SMTP jest ich powszechno\u015b\u0107. Pracownicy przyzwyczaili si\u0119 ju\u017c do korzystania zar\u00f3wno z poczty elektronicznej, jak i przegl\u0105darek internetowych, a administratorzy sieci czuj\u0105 si\u0119 bardzo swobodnie, obs\u0142uguj\u0105c te us\u0142ugi. Technologie takie jak translacja adres\u00f3w sieciowych (NAT) i serwery proxy umo\u017cliwiaj\u0105 dost\u0119p do Internetu za po\u015brednictwem protoko\u0142u HTTP z izolowanych sieci LAN przedsi\u0119biorstw. Administratorzy cz\u0119sto udost\u0119pniaj\u0105 serwer SMTP znajduj\u0105cy si\u0119 wewn\u0105trz zapory sieciowej. Wiadomo\u015bci wysy\u0142ane na ten serwer s\u0105 nast\u0119pnie kierowane do miejsca docelowego przez Internet.<\/p>\n
W przypadku oprogramowania do obs\u0142ugi transakcji kartami kredytowymi konieczna jest natychmiastowa odpowied\u017a ze strony banku obs\u0142uguj\u0105cego sprzedawc\u0119, aby ustali\u0107, czy zam\u00f3wienie powinno zosta\u0107 przekazane do systemu ERP. Protok\u00f3\u0142 HTTP, oparty na schemacie komunikat\u00f3w typu \u201e\u017c\u0105danie\u2013odpowied\u017a\u201d, doskonale nadaje si\u0119 do tego zadania.<\/p>\n
Wi\u0119kszo\u015b\u0107 pakiet\u00f3w oprogramowania ERP nie jest w stanie obs\u0142u\u017cy\u0107 du\u017cych ilo\u015bci zam\u00f3wie\u0144, kt\u00f3re mog\u0105 potencjalnie pochodzi\u0107 z aplikacji e-commerce. Ponadto nie jest konieczne, aby zam\u00f3wienia by\u0142y przekazywane do systemu ERP w czasie rzeczywistym. W zwi\u0105zku z tym mo\u017cna wykorzysta\u0107 protok\u00f3\u0142 SMTP do umieszczania zam\u00f3wie\u0144 w kolejce, tak aby mog\u0142y by\u0107 przetwarzane kolejno przez system ERP.<\/p>\n
Je\u015bli system ERP obs\u0142uguje transakcje rozproszone, inn\u0105 opcj\u0105 jest wykorzystanie serwera Microsoft Message Queue (MSMQ). O ile aplikacja e-commerce i system ERP znajduj\u0105 si\u0119 w tej samej sieci LAN, \u0142\u0105czno\u015b\u0107 za pomoc\u0105 protoko\u0142\u00f3w innych ni\u017c internetowe nie stanowi wi\u0119kszego problemu. Zalet\u0105 serwera MSMQ w por\u00f3wnaniu z protoko\u0142em SMTP jest to, \u017ce komunikaty mo\u017cna umieszcza\u0107 w kolejce i usuwa\u0107 z niej w ramach jednej transakcji. Je\u015bli pr\u00f3ba przetworzenia komunikatu pobranego z kolejki zako\u0144czy si\u0119 niepowodzeniem, komunikat ten zostanie automatycznie umieszczony z powrotem w kolejce po przerwaniu transakcji.<\/p>\n
Wyb\u00f3r schematu kodowania<\/b><\/p>\n
Protoko\u0142y HTTP i SMTP umo\u017cliwiaj\u0105 przesy\u0142anie danych mi\u0119dzy klientem a serwerem. \u017baden z nich nie okre\u015bla jednak, w jaki spos\u00f3b nale\u017cy zakodowa\u0107 dane zawarte w tre\u015bci wiadomo\u015bci. Firma Microsoft potrzebowa\u0142a standardowego, niezale\u017cnego od platformy sposobu kodowania danych wymienianych mi\u0119dzy klientem a serwerem.<\/p>\n
Poniewa\u017c celem by\u0142o wykorzystanie protoko\u0142\u00f3w internetowych, naturalnym wyborem okaza\u0142 si\u0119 j\u0119zyk XML (Extensible Markup Language). XML oferuje wiele zalet, w tym obs\u0142ug\u0119 r\u00f3\u017cnych platform, wsp\u00f3lny system typ\u00f3w oraz obs\u0142ug\u0119 standardowych zestaw\u00f3w znak\u00f3w.<\/p>\n
Schematy kodowania binarnego, takie jak te stosowane w DCOM, CORBA i Java RMI, musz\u0105 uwzgl\u0119dnia\u0107 kwestie zgodno\u015bci mi\u0119dzy r\u00f3\u017cnymi platformami sprz\u0119towymi. Na przyk\u0142ad r\u00f3\u017cne platformy sprz\u0119towe stosuj\u0105 r\u00f3\u017cne wewn\u0119trzne reprezentacje binarne liczb wielobajtowych. Platformy Intel porz\u0105dkuj\u0105 bajty liczby wielobajtowej zgodnie z konwencj\u0105 little endian; wiele procesor\u00f3w RISC porz\u0105dkuje bajty liczby wielobajtowej zgodnie z konwencj\u0105 big endian.<\/p>\n
XML pozwala unikn\u0105\u0107 problem\u00f3w zwi\u0105zanych z kodowaniem binarnym, poniewa\u017c wykorzystuje schemat kodowania oparty na tek\u015bcie, oparty na standardowych zestawach znak\u00f3w. Ponadto niekt\u00f3re protoko\u0142y transportowe, takie jak SMTP, mog\u0105 obs\u0142ugiwa\u0107 wy\u0142\u0105cznie wiadomo\u015bci tekstowe.<\/p>\n
Metody kodowania binarnego, takie jak te stosowane w DCOM i CORBA, s\u0105 uci\u0105\u017cliwe i wymagaj\u0105 infrastruktury wspieraj\u0105cej, kt\u00f3ra pozwala programistom unikn\u0105\u0107 zajmowania si\u0119 szczeg\u00f3\u0142ami. XML jest znacznie l\u017cejszy i \u0142atwiejszy w obs\u0142udze, poniewa\u017c mo\u017cna go tworzy\u0107 i wykorzystywa\u0107 przy u\u017cyciu standardowych technik analizy tekstu.<\/p>\n
Ponadto dost\u0119pne s\u0105 r\u00f3\u017cnorodne parsery XML, kt\u00f3re jeszcze bardziej upraszczaj\u0105 tworzenie i wykorzystywanie dokument\u00f3w XML praktycznie na ka\u017cdej nowoczesnej platformie. XML jest formatem lekki i charakteryzuje si\u0119 doskona\u0142\u0105 obs\u0142ug\u0105 narz\u0119dziow\u0105, dzi\u0119ki czemu kodowanie XML zapewnia niesamowity zasi\u0119g, poniewa\u017c praktycznie ka\u017cdy klient na dowolnej platformie mo\u017ce komunikowa\u0107 si\u0119 z Twoj\u0105 us\u0142ug\u0105 internetow\u0105.<\/p>\n
Wyb\u00f3r zasad formatowania<\/b><\/p>\n
Cz\u0119sto konieczne jest do\u0142\u0105czenie dodatkowych metadanych do tre\u015bci komunikatu. Na przyk\u0142ad mo\u017ce zaistnie\u0107 potrzeba do\u0142\u0105czenia informacji o rodzaju us\u0142ug, kt\u00f3re us\u0142uga internetowa musi zapewni\u0107 w celu zrealizowania \u017c\u0105dania, takich jak rejestracja w transakcji lub informacje dotycz\u0105ce routingu. J\u0119zyk XML nie udost\u0119pnia mechanizmu pozwalaj\u0105cego odr\u00f3\u017cni\u0107 tre\u015b\u0107 komunikatu od powi\u0105zanych z nim danych.<\/p>\n
Protoko\u0142y transportowe, takie jak HTTP, zapewniaj\u0105 rozszerzalny mechanizm obs\u0142ugi danych nag\u0142\u00f3wkowych, jednak niekt\u00f3re dane zwi\u0105zane z komunikatem mog\u0105 nie by\u0107 specyficzne dla danego protoko\u0142u transportowego. Na przyk\u0142ad klient mo\u017ce wys\u0142a\u0107 komunikat, kt\u00f3ry musi zosta\u0107 przekierowany do wielu miejsc docelowych, potencjalnie za po\u015brednictwem r\u00f3\u017cnych protoko\u0142\u00f3w transportowych. Gdyby informacje o routingu zosta\u0142y umieszczone w nag\u0142\u00f3wku HTTP, musia\u0142yby zosta\u0107 przet\u0142umaczone przed wys\u0142aniem do kolejnego po\u015brednika za po\u015brednictwem innego protoko\u0142u transportowego, takiego jak SMTP. Poniewa\u017c informacje o routingu s\u0105 specyficzne dla danej wiadomo\u015bci, a nie dla protoko\u0142u transportowego, powinny stanowi\u0107 cz\u0119\u015b\u0107 tej wiadomo\u015bci.<\/p>\n
Protok\u00f3\u0142 SOAP (Simple Object Access Protocol) zapewnia niezale\u017cny od protoko\u0142u spos\u00f3b powi\u0105zania informacji nag\u0142\u00f3wkowych z tre\u015bci\u0105 komunikatu. Ka\u017cdy komunikat SOAP musi zawiera\u0107 kopert\u0119. Koperta sk\u0142ada si\u0119 z tre\u015bci, zawieraj\u0105cej dane u\u017cytkowe komunikatu, oraz nag\u0142\u00f3wka, kt\u00f3ry mo\u017ce zawiera\u0107 metadane zwi\u0105zane z komunikatem.<\/p>\n
SOAP nie nak\u0142ada \u017cadnych ogranicze\u0144 dotycz\u0105cych formatowania tre\u015bci komunikatu. Stanowi to potencjalny problem, poniewa\u017c bez sp\u00f3jnego sposobu kodowania danych trudno jest opracowa\u0107 zestaw narz\u0119dzi, kt\u00f3ry pozwoli\u0142by na abstrakcyjne podej\u015bcie do protoko\u0142\u00f3w bazowych. By\u0107 mo\u017ce b\u0119dziesz musia\u0142 po\u015bwi\u0119ci\u0107 sporo czasu na zapoznanie si\u0119 z interfejsem us\u0142ugi internetowej zamiast na rozwi\u0105zywanie bie\u017c\u0105cego problemu biznesowego.<\/p>\n
Potrzebny by\u0142 standardowy spos\u00f3b formatowania komunikatu zdalnego wywo\u0142ania procedury (RPC) oraz kodowania listy jego parametr\u00f3w. W\u0142a\u015bnie to zapewnia sekcja 7 specyfikacji SOAP. Opisuje ona standardow\u0105 konwencj\u0119 nazewnicz\u0105 oraz styl kodowania dla komunikat\u00f3w zorientowanych na procedury.<\/p>\n
Poniewa\u017c SOAP zapewnia standardowy format serializacji danych do komunikatu XML, platformy takie jak ASP.NET i Remoting mog\u0105 za u\u017cytkownika zaj\u0105\u0107 si\u0119 szczeg\u00f3\u0142ami.<\/p>\n
Wyb\u00f3r mechanizm\u00f3w opisu<\/b><\/p>\n
SOAP zapewnia standardowy spos\u00f3b formatowania komunikat\u00f3w wymienianych mi\u0119dzy us\u0142ug\u0105 internetow\u0105 a klientem. Klient potrzebuje jednak dodatkowych informacji, aby prawid\u0142owo zserializowa\u0107 \u017c\u0105danie i zinterpretowa\u0107 odpowied\u017a. Schemat XML umo\u017cliwia tworzenie schemat\u00f3w, kt\u00f3re mo\u017cna wykorzysta\u0107 do opisania zawarto\u015bci komunikatu.<\/p>\n
Schemat XML udost\u0119pnia podstawowy zestaw wbudowanych typ\u00f3w danych, kt\u00f3re mo\u017cna wykorzysta\u0107 do opisania tre\u015bci komunikatu. Mo\u017cna r\u00f3wnie\u017c tworzy\u0107 w\u0142asne typy danych. Na przyk\u0142ad bank inwestycyjny mo\u017ce utworzy\u0107 z\u0142o\u017cony typ danych w celu opisania tre\u015bci i struktury tre\u015bci komunikatu s\u0142u\u017c\u0105cego do przes\u0142ania \u017c\u0105dania p\u0142atno\u015bci kart\u0105 kredytow\u0105.<\/p>\n
Schemat zawiera zbi\u00f3r definicji typ\u00f3w danych i element\u00f3w. Us\u0142uga internetowa wykorzystuje schemat nie tylko do okre\u015blenia typu danych, kt\u00f3re powinny znajdowa\u0107 si\u0119 w komunikacie, ale tak\u017ce do sprawdzania poprawno\u015bci komunikat\u00f3w przychodz\u0105cych i wychodz\u0105cych.<\/p>\n
Jednak samo schemat nie dostarcza wystarczaj\u0105cych informacji, by skutecznie opisa\u0107 us\u0142ug\u0119 internetow\u0105. Schemat nie opisuje wzorc\u00f3w komunikat\u00f3w mi\u0119dzy klientem a serwerem. Na przyk\u0142ad klient musi wiedzie\u0107, czy mo\u017ce spodziewa\u0107 si\u0119 odpowiedzi po przes\u0142aniu zam\u00f3wienia do systemu ERP. Klient musi r\u00f3wnie\u017c wiedzie\u0107, za po\u015brednictwem jakiego protoko\u0142u transportowego us\u0142uga internetowa oczekuje otrzymywania \u017c\u0105da\u0144. Wreszcie klient musi zna\u0107 adres, pod kt\u00f3rym mo\u017cna po\u0142\u0105czy\u0107 si\u0119 z us\u0142ug\u0105 internetow\u0105.<\/p>\n
Informacje te s\u0105 zawarte w dokumencie WSDL (Web Services Description Language). WSDL to dokument XML, kt\u00f3ry zawiera pe\u0142ny opis konkretnej us\u0142ugi internetowej. Narz\u0119dzia takie jak ASP.NET WSDL.exe i Remoting SOAPSUDS.exe mog\u0105 przetwarza\u0107 pliki WSDL i automatycznie generowa\u0107 proxy dla programisty.<\/p>\n
Podobnie jak w przypadku ka\u017cdego komponentu wykorzystywanego do tworzenia oprogramowania, us\u0142udze internetowej powinna r\u00f3wnie\u017c towarzyszy\u0107 pisemna dokumentacja przeznaczona dla programist\u00f3w, kt\u00f3rzy tworz\u0105 oprogramowanie korzystaj\u0105ce z tej us\u0142ugi. Dokumentacja ta powinna opisywa\u0107, do czego s\u0142u\u017cy us\u0142uga internetowa, jakie interfejsy udost\u0119pnia oraz zawiera\u0107 kilka przyk\u0142ad\u00f3w jej wykorzystania. Dobra dokumentacja jest szczeg\u00f3lnie wa\u017cna, je\u015bli us\u0142uga internetowa jest udost\u0119pniana klientom przez Internet.<\/p>\n
Wyb\u00f3r mechanizm\u00f3w ujawniania informacji<\/b><\/p>\n
Gdy ju\u017c opracujesz i udokumentujesz us\u0142ug\u0119 internetow\u0105, w jaki spos\u00f3b potencjalni klienci mog\u0105 j\u0105 znale\u017a\u0107? Je\u015bli us\u0142uga internetowa jest przeznaczona do u\u017cytku przez cz\u0142onka twojego zespo\u0142u programist\u00f3w, mo\u017cesz podej\u015b\u0107 do tego do\u015b\u0107 nieformalnie \u2013 na przyk\u0142ad udost\u0119pniaj\u0105c adres URL dokumentu WSDL koledze siedz\u0105cemu kilka boks\u00f3w dalej. Jednak gdy potencjalni klienci szukaj\u0105 informacji w Internecie, skuteczna promocja us\u0142ugi internetowej to zupe\u0142nie inna historia.<\/p>\n
Potrzebny jest wsp\u00f3lny spos\u00f3b og\u0142aszania us\u0142ug internetowych. Universal Description, Discovery, and Integration (UDDI) zapewnia w\u0142a\u015bnie taki mechanizm. UDDI to zgodna ze standardami bran\u017cowymi scentralizowana us\u0142uga katalogowa, kt\u00f3ra mo\u017ce s\u0142u\u017cy\u0107 do og\u0142aszania i lokalizowania us\u0142ug internetowych. UDDI umo\u017cliwia u\u017cytkownikom wyszukiwanie us\u0142ug internetowych przy u\u017cyciu szeregu kryteri\u00f3w, w tym nazwy firmy, kategorii i typu us\u0142ugi internetowej.<\/p>\n
Us\u0142ugi internetowe mo\u017cna r\u00f3wnie\u017c og\u0142asza\u0107 za po\u015brednictwem DISCO \u2013 zastrze\u017conego formatu dokument\u00f3w XML zdefiniowanego przez firm\u0119 Microsoft, kt\u00f3ry umo\u017cliwia stronom internetowym og\u0142aszanie udost\u0119pnianych przez nie us\u0142ug. DISCO definiuje prosty protok\u00f3\u0142 u\u0142atwiaj\u0105cy lokalizowanie zasob\u00f3w za pomoc\u0105 hiper\u0142\u0105czy. G\u0142\u00f3wnym u\u017cytkownikiem DISCO jest Microsoft Visual Studio.NET. Programista mo\u017ce wybra\u0107 konkretny serwer internetowy i przegl\u0105da\u0107 r\u00f3\u017cne us\u0142ugi internetowe udost\u0119pniane przez ten serwer.<\/p>\n
Czego brakuje w us\u0142ugach internetowych?<\/b><\/p>\n
By\u0107 mo\u017ce zauwa\u017cyli\u015bcie, \u017ce niekt\u00f3re kluczowe elementy infrastruktury komponent\u00f3w rozproszonych nie s\u0105 zdefiniowane przez us\u0142ugi internetowe. Dwa z bardziej rzucaj\u0105cych si\u0119 w oczy brak\u00f3w to dobrze zdefiniowany interfejs API s\u0142u\u017c\u0105cy do tworzenia i korzystania z us\u0142ug internetowych oraz zestaw us\u0142ug komponentowych, takich jak obs\u0142uga transakcji rozproszonych. Om\u00f3wmy ka\u017cdy z tych brakuj\u0105cych element\u00f3w.<\/p>\n
Aby zapewni\u0107 niezale\u017cno\u015b\u0107 us\u0142ug internetowych od j\u0119zyk\u00f3w programowania, firma Microsoft pozostawi\u0142a poszczeg\u00f3lnym dostawcom oprogramowania swobod\u0119 w zakresie powi\u0105zania obs\u0142ugi us\u0142ug internetowych z konkretn\u0105 platform\u0105. W dalszej cz\u0119\u015bci ksi\u0105\u017cki om\u00f3wi\u0119 dwie implementacje us\u0142ug internetowych dla platformy .NET: ASP.NET i Remoting.<\/p>\n
Niekt\u00f3re us\u0142ugi, takie jak obs\u0142uga transakcji rozproszonych, mo\u017cna wprowadzi\u0107 w p\u00f3\u017aniejszym terminie, w miar\u0119 dojrzewania technologii. Inne, takie jak pula obiekt\u00f3w i ewentualnie zarz\u0105dzanie cyklem \u017cycia obiekt\u00f3w, mo\u017cna uzna\u0107 za szczeg\u00f3\u0142y implementacyjne platformy. Na przyk\u0142ad Remoting definiuje rozszerzenia zapewniaj\u0105ce obs\u0142ug\u0119 zarz\u0105dzania cyklem \u017cycia obiekt\u00f3w, a Microsoft Component Services zapewnia obs\u0142ug\u0119 puli obiekt\u00f3w.<\/p>\n
Podsumowanie<\/b><\/p>\n
Programowanie oparte na komponentach okaza\u0142o si\u0119 prawdziwym dobrodziejstwem dla wydajno\u015bci programist\u00f3w, jednak niekt\u00f3rych us\u0142ug nie da si\u0119 zamkn\u0105\u0107 w komponencie znajduj\u0105cym si\u0119 w centrum danych klienta. Starsze technologie, takie jak DCOM, CORBA i Java RMI, nie nadaj\u0105 si\u0119 do zapewnienia klientom dost\u0119pu do us\u0142ug przez Internet, dlatego firma Microsoft uzna\u0142a za konieczne rozpocz\u0119cie prac od podstaw i stworzenie zgodnego ze standardami bran\u017cowymi sposobu uzyskiwania dost\u0119pu do us\u0142ug zdalnych.<\/p>\n
Us\u0142ugi sieciowe<\/i> jest terminem og\u00f3lnym opisuj\u0105cym zbi\u00f3r standardowych protoko\u0142\u00f3w i us\u0142ug bran\u017cowych wykorzystywanych w celu zapewnienia podstawowego poziomu interoperacyjno\u015bci mi\u0119dzy aplikacjami. Poparcie bran\u017cowe, jakim ciesz\u0105 si\u0119 us\u0142ugi internetowe, jest bezprecedensowe. Nigdy wcze\u015bniej tak wiele wiod\u0105cych firm technologicznych nie zaanga\u017cowa\u0142o si\u0119 w promowanie standardu u\u0142atwiaj\u0105cego interoperacyjno\u015b\u0107 mi\u0119dzy aplikacjami, niezale\u017cnie od platformy, na kt\u00f3rej s\u0105 one uruchamiane.<\/p>\n
Jednym z czynnik\u00f3w decyduj\u0105cych o sukcesie us\u0142ug internetowych jest to, \u017ce opieraj\u0105 si\u0119 one na istniej\u0105cych standardach internetowych, takich jak XML i HTTP. Dzi\u0119ki temu ka\u017cdy system zdolny do analizowania tekstu i komunikowania si\u0119 za po\u015brednictwem standardowego protoko\u0142u transportowego mo\u017ce wsp\u00f3\u0142pracowa\u0107 z us\u0142ug\u0105 internetow\u0105. Firmy mog\u0105 r\u00f3wnie\u017c wykorzysta\u0107 dotychczasowe inwestycje w te technologie.<\/p>","protected":false},"excerpt":{"rendered":"
Overview Component-based programming has become more popular than ever. Hardly an application is built today that does not involve leveraging components in some form, usually from different vendors. As applications have grown more sophisticated, the need to leverage components distributed on remote machines has also grown.<\/p>","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-231","post","type-post","status-publish","format-standard","hentry","category-smtp-servers"],"_links":{"self":[{"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/posts\/231","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/comments?post=231"}],"version-history":[{"count":1,"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/posts\/231\/revisions"}],"predecessor-version":[{"id":232,"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/posts\/231\/revisions\/232"}],"wp:attachment":[{"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/media?parent=231"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/categories?post=231"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.smtp-server.net\/pl\/wp-json\/wp\/v2\/tags?post=231"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}