Przegląd
Programowanie oparte na komponentach stało się bardziej popularne niż kiedykolwiek. Prawie nie buduje się dziś aplikacji, która nie wykorzystuje komponentów w jakiejś formie, zwykle od różnych dostawców. Ponieważ aplikacje stały się bardziej wyrafinowane, wzrosła również potrzeba wykorzystania komponentów rozproszonych na zdalnych maszynach.
Przykładem aplikacji opartej na komponentach jest kompleksowe rozwiązanie e-commerce. Aplikacja e-commerce rezydująca na farmie internetowej musi przesyłać zamówienia do aplikacji planowania zasobów przedsiębiorstwa (ERP). W wielu przypadkach aplikacja ERP znajduje się na innym sprzęcie i może działać na innym systemie operacyjnym.
Microsoft Distributed Component Object Model (DCOM), rozproszona infrastruktura obiektowa, która umożliwia aplikacji wywoływanie komponentów Component Object Model (COM) zainstalowanych na innym serwerze, została przeniesiona na wiele platform innych niż Windows. Jednak DCOM nigdy nie zyskał szerokiej akceptacji na tych platformach, więc rzadko jest używany do ułatwienia komunikacji między komputerami z systemem Windows i innymi systemami. Dostawcy oprogramowania ERP często tworzą komponenty dla platformy Windows, które komunikują się z systemem zaplecza za pośrednictwem zastrzeżonego protokołu.
Niektóre usługi wykorzystywane przez aplikację e-commerce mogą w ogóle nie znajdować się w centrum danych. Na przykład, jeśli aplikacja e-commerce akceptuje płatność kartą kredytową za towary zakupione przez klienta, musi wywołać usługi banku handlowego w celu przetworzenia informacji o karcie kredytowej klienta. Jednak ze względów praktycznych DCOM i powiązane technologie, takie jak CORBA i Java RMI, są ograniczone do aplikacji i komponentów zainstalowanych w korporacyjnym centrum danych. Dwa główne powody tego są takie, że domyślnie technologie te wykorzystują zastrzeżone protokoły, a protokoły te są z natury zorientowane na połączenia.
Klienci komunikujący się z serwerem przez Internet napotykają wiele potencjalnych barier w komunikacji z serwerem. Świadomi bezpieczeństwa administratorzy sieci na całym świecie wdrożyli routery korporacyjne i zapory ogniowe, aby uniemożliwić praktycznie każdy rodzaj komunikacji przez Internet. Często potrzeba aktu bożego, aby administrator sieci otworzył porty poza absolutnym minimum.
Jeśli masz wystarczająco dużo szczęścia, aby administrator sieci otworzył odpowiednie porty do obsługi Twojej usługi, prawdopodobnie Twoi klienci nie będą mieli tyle szczęścia. W rezultacie zastrzeżone protokoły, takie jak te używane przez DCOM, CORBA i Java RMI, nie są praktyczne w scenariuszach internetowych.
Jak już wspomniałem, innym problemem związanym z tymi technologiami jest to, że są one z natury zorientowane na połączenia i dlatego nie są w stanie sprawnie radzić sobie z przerwami w sieci. Ponieważ Internet nie jest pod bezpośrednią kontrolą użytkownika, nie można przyjmować żadnych założeń dotyczących jakości lub niezawodności połączenia. Jeśli wystąpi przerwa w sieci, następne połączenie klienta z serwerem może zakończyć się niepowodzeniem.
Zorientowany na połączenia charakter tych technologii sprawia również, że trudno jest zbudować infrastrukturę równoważącą obciążenie, niezbędną do osiągnięcia wysokiej skalowalności. Po zerwaniu połączenia między klientem a serwerem nie można po prostu skierować następnego żądania do innego serwera.
Deweloperzy próbowali przezwyciężyć te ograniczenia, wykorzystując model o nazwie bezpaństwowy programowanie, ale odniosły one ograniczony sukces, ponieważ technologie te są dość ciężkie i sprawiają, że ponowne nawiązanie połączenia ze zdalnym obiektem jest kosztowne.
Ponieważ przetwarzanie karty kredytowej klienta jest realizowane przez zdalny serwer w Internecie, DCOM nie jest idealny do ułatwiania komunikacji między klientem e-commerce a serwerem przetwarzania kart kredytowych. Podobnie jak w przypadku rozwiązania ERP, komponent innej firmy jest często instalowany w centrum danych klienta (w tym przypadku przez dostawcę rozwiązania do przetwarzania kart kredytowych). Komponent ten służy jako niewiele więcej niż proxy, które ułatwia komunikację między oprogramowaniem e-commerce a bankiem handlowym za pośrednictwem zastrzeżonego protokołu.
Czy widzisz tu jakiś wzór? Ze względu na ograniczenia istniejących technologii w ułatwianiu komunikacji między systemami komputerowymi, producenci oprogramowania często uciekają się do budowania własnej infrastruktury. Oznacza to, że zasoby, które mogły zostać wykorzystane do dodania ulepszonej funkcjonalności do systemu ERP lub systemu przetwarzania kart kredytowych, zostały zamiast tego poświęcone na pisanie zastrzeżonych protokołów sieciowych.
Starając się lepiej wspierać takie scenariusze internetowe, Microsoft początkowo przyjął strategię rozszerzania istniejących technologii, w tym COM Internet Services (CIS), która pozwala na ustanowienie połączenia DCOM między klientem a zdalnym komponentem przez port 80. Z różnych powodów CIS nie został powszechnie zaakceptowany.
Stało się jasne, że potrzebne jest nowe podejście. Firma Microsoft postanowiła więc rozwiązać ten problem oddolnie. Przyjrzyjmy się niektórym wymaganiom, które rozwiązanie musiało spełnić, aby odnieść sukces.
- Interoperacyjność Usługa zdalna musi być w stanie być wykorzystywana przez klientów na innych platformach.
- Przyjazność dla Internetu Rozwiązanie powinno działać dobrze w przypadku obsługi klientów, którzy uzyskują dostęp do usługi zdalnej z Internetu.
- Silnie typowane interfejsy Nie powinno być żadnych niejasności co do typu danych wysyłanych do i odbieranych z usługi zdalnej. Co więcej, typy danych zdefiniowane przez usługę zdalną powinny być dość dobrze odwzorowane na typy danych zdefiniowane przez większość proceduralnych języków programowania.
- Możliwość wykorzystania istniejących standardów internetowych Wdrożenie usługi zdalnej powinno w jak największym stopniu wykorzystywać istniejące standardy internetowe i unikać ponownego wymyślania rozwiązań problemów, które zostały już rozwiązane. Rozwiązanie oparte na powszechnie przyjętych standardach internetowych może wykorzystać istniejące zestawy narzędzi i produkty stworzone dla tej technologii.
- Obsługa dowolnego języka Rozwiązanie nie powinno być ściśle powiązane z konkretnym językiem programowania. Na przykład Java RMI jest ściśle powiązane z językiem Java. Trudno byłoby wywołać funkcjonalność na zdalnym obiekcie Java z Visual Basic lub Perl. Klient powinien być w stanie zaimplementować nową usługę sieci Web lub użyć istniejącej usługi sieci Web niezależnie od języka programowania, w którym klient został napisany.
- Obsługa dowolnej rozproszonej infrastruktury komponentów Rozwiązanie nie powinno być ściśle powiązane z konkretną infrastrukturą komponentów. W rzeczywistości nie powinieneś być zobowiązany do zakupu, instalacji lub utrzymania rozproszonej infrastruktury obiektowej tylko po to, aby zbudować nową usługę zdalną lub korzystać z istniejącej usługi. Podstawowe protokoły powinny ułatwiać podstawowy poziom komunikacji między istniejącymi rozproszonymi infrastrukturami obiektowymi, takimi jak DCOM i CORBA.
Biorąc pod uwagę tytuł tej książki, nie powinno dziwić, że rozwiązanie stworzone przez Microsoft jest znane jako Usługi sieciowe. Usługa sieciowa udostępnia interfejs do wywoływania określonego działania w imieniu klienta. Klient może uzyskać dostęp do usługi sieci Web poprzez wykorzystanie standardów internetowych.
Bloki konstrukcyjne usług sieciowych
Poniższa grafika przedstawia podstawowe bloki konstrukcyjne potrzebne do ułatwienia zdalnej komunikacji między dwiema aplikacjami.
Omówmy cel każdego z tych bloków konstrukcyjnych. Ponieważ wielu czytelników zna DCOM, wspomnę również o odpowiedniku DCOM każdego bloku konstrukcyjnego.
- Odkrycie Aplikacja kliencka, która potrzebuje dostępu do funkcji udostępnianych przez usługę sieci Web, musi mieć sposób na określenie lokalizacji usługi zdalnej. Odbywa się to poprzez proces ogólnie określany jako odkrycie. Odnajdywanie może być ułatwione poprzez scentralizowany katalog, jak również poprzez bardziej doraźne metody. W DCOM, Service Control Manager (SCM) zapewnia usługi wykrywania.
- Opis Po ustaleniu punktu końcowego dla konkretnej usługi sieci Web, klient potrzebuje wystarczających informacji, aby prawidłowo z nią współdziałać. Opis usługi sieci Web obejmuje ustrukturyzowane metadane dotyczące interfejsu, który ma być wykorzystywany przez aplikację kliencką, a także pisemną dokumentację usługi sieci Web, w tym przykłady użycia. Komponent DCOM udostępnia ustrukturyzowane metadane o swoich interfejsach za pośrednictwem biblioteki typów (typelib). Metadane w typelib komponentu są przechowywane w zastrzeżonym formacie binarnym i są dostępne za pośrednictwem zastrzeżonego interfejsu programowania aplikacji (API).
- Format wiadomości W celu wymiany danych, klient i serwer muszą uzgodnić wspólny sposób kodowania i formatowania wiadomości. Standardowy sposób kodowania danych gwarantuje, że dane zakodowane przez klienta zostaną poprawnie zinterpretowane przez serwer. W DCOM wiadomości wysyłane między klientem a serwerem są formatowane zgodnie z definicją protokołu DCOM Object RPC (ORPC).
Bez standardowego sposobu formatowania wiadomości, opracowanie zestawu narzędzi abstrahujących dewelopera od podstawowych protokołów jest prawie niemożliwe. Stworzenie warstwy abstrakcji między deweloperem a podstawowymi protokołami pozwala deweloperowi skupić się bardziej na danym problemie biznesowym, a mniej na infrastrukturze wymaganej do wdrożenia rozwiązania.
- Kodowanie Dane przesyłane między klientem a serwerem muszą być zakodowane w treści wiadomości. DCOM wykorzystuje schemat kodowania binarnego do serializacji danych zawartych w parametrach wymienianych między klientem a serwerem.
- Transport Po sformatowaniu wiadomości i serializacji danych w treści wiadomości, wiadomość musi zostać przesłana między klientem a serwerem za pośrednictwem protokołu transportowego. DCOM obsługuje wiele zastrzeżonych protokołów powiązanych z wieloma protokołami sieciowymi, takimi jak TCP, SPX, NetBEUI i NetBIOS przez IPX.
Decyzje dotyczące projektowania usług internetowych
Omówmy niektóre decyzje projektowe, które stoją za tymi elementami składowymi usług internetowych.
Wybór protokołów transportowych
Pierwszym krokiem było ustalenie, w jaki sposób klient i serwer będą się ze sobą komunikować. Klient i serwer mogą znajdować się w tej samej sieci LAN, ale klient może potencjalnie komunikować się z serwerem przez Internet. Dlatego protokół transportowy musi być w równym stopniu dostosowany zarówno do środowisk sieci LAN, jak i do Internetu.
Jak wspomniałem wcześniej, technologie takie jak DCOM, CORBA i Java RMI nie nadają się do obsługi komunikacji między klientem a serwerem przez Internet. Protokoły takie jak Hypertext Transfer Protocol (HTTP) i Simple Mail Transfer Protocol (SMTP) są sprawdzonymi protokołami internetowymi. Protokół HTTP definiuje schemat komunikacji typu żądanie-odpowiedź służący do wysyłania żądań i otrzymywania powiązanych odpowiedzi. Protokół SMTP definiuje protokół przesyłania wiadomości z możliwością routingu, przeznaczony do komunikacji asynchronicznej. Przyjrzyjmy się, dlaczego protokoły HTTP i SMTP dobrze sprawdzają się w Internecie.
Aplikacje internetowe oparte na protokole HTTP są z natury bezstanowe. Nie wymagają one stałego połączenia między klientem a serwerem. Dzięki temu protokół HTTP idealnie nadaje się do konfiguracji zapewniających wysoką dostępność, takich jak zapory sieciowe. Jeśli serwer, który obsłużył pierwotne żądanie klienta, stanie się niedostępny, kolejne żądania mogą być automatycznie przekierowywane do innego serwera, a klient nie musi o tym wiedzieć ani się tym przejmować.
Prawie wszystkie firmy dysponują infrastrukturą obsługującą protokół SMTP. Protokół SMTP doskonale nadaje się do komunikacji asynchronicznej. W przypadku zakłóceń w działaniu usługi infrastruktura pocztowa automatycznie podejmuje ponowne próby wysłania wiadomości. W przeciwieństwie do protokołu HTTP, wiadomości SMTP można przekazać do lokalnego serwera pocztowego, który podejmie próbę dostarczenia wiadomości w imieniu użytkownika.
Kolejną istotną zaletą zarówno protokołu HTTP, jak i SMTP jest ich powszechność. Pracownicy przyzwyczaili się już do korzystania zarówno z poczty elektronicznej, jak i przeglądarek internetowych, a administratorzy sieci czują się bardzo swobodnie, obsługując te usługi. Technologie takie jak translacja adresów sieciowych (NAT) i serwery proxy umożliwiają dostęp do Internetu za pośrednictwem protokołu HTTP z izolowanych sieci LAN przedsiębiorstw. Administratorzy często udostępniają serwer SMTP znajdujący się wewnątrz zapory sieciowej. Wiadomości wysyłane na ten serwer są następnie kierowane do miejsca docelowego przez Internet.
W przypadku oprogramowania do obsługi transakcji kartami kredytowymi konieczna jest natychmiastowa odpowiedź ze strony banku obsługującego sprzedawcę, aby ustalić, czy zamówienie powinno zostać przekazane do systemu ERP. Protokół HTTP, oparty na schemacie komunikatów typu „żądanie–odpowiedź”, doskonale nadaje się do tego zadania.
Większość pakietów oprogramowania ERP nie jest w stanie obsłużyć dużych ilości zamówień, które mogą potencjalnie pochodzić z aplikacji e-commerce. Ponadto nie jest konieczne, aby zamówienia były przekazywane do systemu ERP w czasie rzeczywistym. W związku z tym można wykorzystać protokół SMTP do umieszczania zamówień w kolejce, tak aby mogły być przetwarzane kolejno przez system ERP.
Jeśli system ERP obsługuje transakcje rozproszone, inną opcją jest wykorzystanie serwera Microsoft Message Queue (MSMQ). O ile aplikacja e-commerce i system ERP znajdują się w tej samej sieci LAN, łączność za pomocą protokołów innych niż internetowe nie stanowi większego problemu. Zaletą serwera MSMQ w porównaniu z protokołem SMTP jest to, że komunikaty można umieszczać w kolejce i usuwać z niej w ramach jednej transakcji. Jeśli próba przetworzenia komunikatu pobranego z kolejki zakończy się niepowodzeniem, komunikat ten zostanie automatycznie umieszczony z powrotem w kolejce po przerwaniu transakcji.
Wybór schematu kodowania
Protokoły HTTP i SMTP umożliwiają przesyłanie danych między klientem a serwerem. Żaden z nich nie określa jednak, w jaki sposób należy zakodować dane zawarte w treści wiadomości. Firma Microsoft potrzebowała standardowego, niezależnego od platformy sposobu kodowania danych wymienianych między klientem a serwerem.
Ponieważ celem było wykorzystanie protokołów internetowych, naturalnym wyborem okazał się język XML (Extensible Markup Language). XML oferuje wiele zalet, w tym obsługę różnych platform, wspólny system typów oraz obsługę standardowych zestawów znaków.
Schematy kodowania binarnego, takie jak te stosowane w DCOM, CORBA i Java RMI, muszą uwzględniać kwestie zgodności między różnymi platformami sprzętowymi. Na przykład różne platformy sprzętowe stosują różne wewnętrzne reprezentacje binarne liczb wielobajtowych. Platformy Intel porządkują bajty liczby wielobajtowej zgodnie z konwencją little endian; wiele procesorów RISC porządkuje bajty liczby wielobajtowej zgodnie z konwencją big endian.
XML pozwala uniknąć problemów związanych z kodowaniem binarnym, ponieważ wykorzystuje schemat kodowania oparty na tekście, oparty na standardowych zestawach znaków. Ponadto niektóre protokoły transportowe, takie jak SMTP, mogą obsługiwać wyłącznie wiadomości tekstowe.
Metody kodowania binarnego, takie jak te stosowane w DCOM i CORBA, są uciążliwe i wymagają infrastruktury wspierającej, która pozwala programistom uniknąć zajmowania się szczegółami. XML jest znacznie lżejszy i łatwiejszy w obsłudze, ponieważ można go tworzyć i wykorzystywać przy użyciu standardowych technik analizy tekstu.
Ponadto dostępne są różnorodne parsery XML, które jeszcze bardziej upraszczają tworzenie i wykorzystywanie dokumentów XML praktycznie na każdej nowoczesnej platformie. XML jest formatem lekki i charakteryzuje się doskonałą obsługą narzędziową, dzięki czemu kodowanie XML zapewnia niesamowity zasięg, ponieważ praktycznie każdy klient na dowolnej platformie może komunikować się z Twoją usługą internetową.
Wybór zasad formatowania
Często konieczne jest dołączenie dodatkowych metadanych do treści komunikatu. Na przykład może zaistnieć potrzeba dołączenia informacji o rodzaju usług, które usługa internetowa musi zapewnić w celu zrealizowania żądania, takich jak rejestracja w transakcji lub informacje dotyczące routingu. Język XML nie udostępnia mechanizmu pozwalającego odróżnić treść komunikatu od powiązanych z nim danych.
Protokoły transportowe, takie jak HTTP, zapewniają rozszerzalny mechanizm obsługi danych nagłówkowych, jednak niektóre dane związane z komunikatem mogą nie być specyficzne dla danego protokołu transportowego. Na przykład klient może wysłać komunikat, który musi zostać przekierowany do wielu miejsc docelowych, potencjalnie za pośrednictwem różnych protokołów transportowych. Gdyby informacje o routingu zostały umieszczone w nagłówku HTTP, musiałyby zostać przetłumaczone przed wysłaniem do kolejnego pośrednika za pośrednictwem innego protokołu transportowego, takiego jak SMTP. Ponieważ informacje o routingu są specyficzne dla danej wiadomości, a nie dla protokołu transportowego, powinny stanowić część tej wiadomości.
Protokół SOAP (Simple Object Access Protocol) zapewnia niezależny od protokołu sposób powiązania informacji nagłówkowych z treścią komunikatu. Każdy komunikat SOAP musi zawierać kopertę. Koperta składa się z treści, zawierającej dane użytkowe komunikatu, oraz nagłówka, który może zawierać metadane związane z komunikatem.
SOAP nie nakłada żadnych ograniczeń dotyczących formatowania treści komunikatu. Stanowi to potencjalny problem, ponieważ bez spójnego sposobu kodowania danych trudno jest opracować zestaw narzędzi, który pozwoliłby na abstrakcyjne podejście do protokołów bazowych. Być może będziesz musiał poświęcić sporo czasu na zapoznanie się z interfejsem usługi internetowej zamiast na rozwiązywanie bieżącego problemu biznesowego.
Potrzebny był standardowy sposób formatowania komunikatu zdalnego wywołania procedury (RPC) oraz kodowania listy jego parametrów. Właśnie to zapewnia sekcja 7 specyfikacji SOAP. Opisuje ona standardową konwencję nazewniczą oraz styl kodowania dla komunikatów zorientowanych na procedury.
Ponieważ SOAP zapewnia standardowy format serializacji danych do komunikatu XML, platformy takie jak ASP.NET i Remoting mogą za użytkownika zająć się szczegółami.
Wybór mechanizmów opisu
SOAP zapewnia standardowy sposób formatowania komunikatów wymienianych między usługą internetową a klientem. Klient potrzebuje jednak dodatkowych informacji, aby prawidłowo zserializować żądanie i zinterpretować odpowiedź. Schemat XML umożliwia tworzenie schematów, które można wykorzystać do opisania zawartości komunikatu.
Schemat XML udostępnia podstawowy zestaw wbudowanych typów danych, które można wykorzystać do opisania treści komunikatu. Można również tworzyć własne typy danych. Na przykład bank inwestycyjny może utworzyć złożony typ danych w celu opisania treści i struktury treści komunikatu służącego do przesłania żądania płatności kartą kredytową.
Schemat zawiera zbiór definicji typów danych i elementów. Usługa internetowa wykorzystuje schemat nie tylko do określenia typu danych, które powinny znajdować się w komunikacie, ale także do sprawdzania poprawności komunikatów przychodzących i wychodzących.
Jednak samo schemat nie dostarcza wystarczających informacji, by skutecznie opisać usługę internetową. Schemat nie opisuje wzorców komunikatów między klientem a serwerem. Na przykład klient musi wiedzieć, czy może spodziewać się odpowiedzi po przesłaniu zamówienia do systemu ERP. Klient musi również wiedzieć, za pośrednictwem jakiego protokołu transportowego usługa internetowa oczekuje otrzymywania żądań. Wreszcie klient musi znać adres, pod którym można połączyć się z usługą internetową.
Informacje te są zawarte w dokumencie WSDL (Web Services Description Language). WSDL to dokument XML, który zawiera pełny opis konkretnej usługi internetowej. Narzędzia takie jak ASP.NET WSDL.exe i Remoting SOAPSUDS.exe mogą przetwarzać pliki WSDL i automatycznie generować proxy dla programisty.
Podobnie jak w przypadku każdego komponentu wykorzystywanego do tworzenia oprogramowania, usłudze internetowej powinna również towarzyszyć pisemna dokumentacja przeznaczona dla programistów, którzy tworzą oprogramowanie korzystające z tej usługi. Dokumentacja ta powinna opisywać, do czego służy usługa internetowa, jakie interfejsy udostępnia oraz zawierać kilka przykładów jej wykorzystania. Dobra dokumentacja jest szczególnie ważna, jeśli usługa internetowa jest udostępniana klientom przez Internet.
Wybór mechanizmów ujawniania informacji
Gdy już opracujesz i udokumentujesz usługę internetową, w jaki sposób potencjalni klienci mogą ją znaleźć? Jeśli usługa internetowa jest przeznaczona do użytku przez członka twojego zespołu programistów, możesz podejść do tego dość nieformalnie – na przykład udostępniając adres URL dokumentu WSDL koledze siedzącemu kilka boksów dalej. Jednak gdy potencjalni klienci szukają informacji w Internecie, skuteczna promocja usługi internetowej to zupełnie inna historia.
Potrzebny jest wspólny sposób ogłaszania usług internetowych. Universal Description, Discovery, and Integration (UDDI) zapewnia właśnie taki mechanizm. UDDI to zgodna ze standardami branżowymi scentralizowana usługa katalogowa, która może służyć do ogłaszania i lokalizowania usług internetowych. UDDI umożliwia użytkownikom wyszukiwanie usług internetowych przy użyciu szeregu kryteriów, w tym nazwy firmy, kategorii i typu usługi internetowej.
Usługi internetowe można również ogłaszać za pośrednictwem DISCO – zastrzeżonego formatu dokumentów XML zdefiniowanego przez firmę Microsoft, który umożliwia stronom internetowym ogłaszanie udostępnianych przez nie usług. DISCO definiuje prosty protokół ułatwiający lokalizowanie zasobów za pomocą hiperłączy. Głównym użytkownikiem DISCO jest Microsoft Visual Studio.NET. Programista może wybrać konkretny serwer internetowy i przeglądać różne usługi internetowe udostępniane przez ten serwer.
Czego brakuje w usługach internetowych?
Być może zauważyliście, że niektóre kluczowe elementy infrastruktury komponentów rozproszonych nie są zdefiniowane przez usługi internetowe. Dwa z bardziej rzucających się w oczy braków to dobrze zdefiniowany interfejs API służący do tworzenia i korzystania z usług internetowych oraz zestaw usług komponentowych, takich jak obsługa transakcji rozproszonych. Omówmy każdy z tych brakujących elementów.
- Interfejs API przeznaczony dla usług internetowych Większość infrastruktur komponentów rozproszonych definiuje interfejs API służący do wykonywania takich zadań, jak inicjalizacja środowiska uruchomieniowego, tworzenie instancji komponentu oraz odzwierciedlanie metadanych używanych do opisu komponentu. Ponieważ większość języków programowania wysokiego poziomu zapewnia pewien stopień współdziałania z językiem C, interfejs API jest zazwyczaj udostępniany jako płaski zbiór sygnatur metod w języku C. RMI posuwa się nawet do ścisłego powiązania swojego interfejsu API z jednym językiem wysokiego poziomu – Javą.
Aby zapewnić niezależność usług internetowych od języków programowania, firma Microsoft pozostawiła poszczególnym dostawcom oprogramowania swobodę w zakresie powiązania obsługi usług internetowych z konkretną platformą. W dalszej części książki omówię dwie implementacje usług internetowych dla platformy .NET: ASP.NET i Remoting.
- Usługi związane z komponentami Platforma usług internetowych nie zapewnia wielu usług powszechnie spotykanych w infrastrukturach komponentów rozproszonych, takich jak zdalne zarządzanie cyklem życia obiektów, buforowanie obiektów oraz obsługa transakcji rozproszonych. Wdrożenie tych usług pozostawia się infrastrukturze komponentów rozproszonych.
Niektóre usługi, takie jak obsługa transakcji rozproszonych, można wprowadzić w późniejszym terminie, w miarę dojrzewania technologii. Inne, takie jak pula obiektów i ewentualnie zarządzanie cyklem życia obiektów, można uznać za szczegóły implementacyjne platformy. Na przykład Remoting definiuje rozszerzenia zapewniające obsługę zarządzania cyklem życia obiektów, a Microsoft Component Services zapewnia obsługę puli obiektów.
Podsumowanie
Programowanie oparte na komponentach okazało się prawdziwym dobrodziejstwem dla wydajności programistów, jednak niektórych usług nie da się zamknąć w komponencie znajdującym się w centrum danych klienta. Starsze technologie, takie jak DCOM, CORBA i Java RMI, nie nadają się do zapewnienia klientom dostępu do usług przez Internet, dlatego firma Microsoft uznała za konieczne rozpoczęcie prac od podstaw i stworzenie zgodnego ze standardami branżowymi sposobu uzyskiwania dostępu do usług zdalnych.
Usługi sieciowe jest terminem ogólnym opisującym zbiór standardowych protokołów i usług branżowych wykorzystywanych w celu zapewnienia podstawowego poziomu interoperacyjności między aplikacjami. Poparcie branżowe, jakim cieszą się usługi internetowe, jest bezprecedensowe. Nigdy wcześniej tak wiele wiodących firm technologicznych nie zaangażowało się w promowanie standardu ułatwiającego interoperacyjność między aplikacjami, niezależnie od platformy, na której są one uruchamiane.
Jednym z czynników decydujących o sukcesie usług internetowych jest to, że opierają się one na istniejących standardach internetowych, takich jak XML i HTTP. Dzięki temu każdy system zdolny do analizowania tekstu i komunikowania się za pośrednictwem standardowego protokołu transportowego może współpracować z usługą internetową. Firmy mogą również wykorzystać dotychczasowe inwestycje w te technologie.