Bezpieczne, niezawodne, transakcyjne usługi sieci Web: architektura i kompozycja

Artykuł
04/03/2007

Wrzesień 2003 r.

IBM Corporation

Donald F. Ferguson
IBM Fellow i przewodniczący
Tablica architektury grupy oprogramowania IBM

Tony Storey
IBM Fellow

Microsoft Corporation

Brad Lovering
Wybitny inżynier

John Shewchuk
Architekt usług sieci Web

Treść

1.0 Wprowadzenie
   1.1 Usługi komponowalne
   1.2 Przykład kompozycji w praktyce
2.0 Usługi sieci Web: architektura Service-Oriented
   2.1 Usługi są opisywane przez schemat, a kontrakt nie jest typem
   2.2 Zgodność usługi jest większa niż zgodność typu
   2.3 Orientacja usługi zakłada, że złe rzeczy mogą i będą się zdarzać
   2.4 Orientacja usługi umożliwia elastyczne powiązanie usług
3.0 Specyfikacje i funkcje usług sieci Web
   3.1 Podejście komponowalne do usług sieci Web
   3.2 Podstawy — transporty i komunikaty
      3.2.1 Transporty — HTTP, HTTP/S, SMTP
      3.2.2 Formaty komunikatów — XSD
      3.2.3 WS-Addressing
   Opis 3.3
      3.3.1 WSDL
      3.3.2 WS-Policy
      3.3.3 Uzyskiwanie opisów
      3.3.4 WS-MetadataExchange
      3.3.5 UDDI
   3.4 Zabezpieczenia usług
   3.5 Zabezpieczenia
      3.5.1 WS-Security
      3.5.2 WS-Trust
      3.5.3 WS-SecureConversation
      3.5.4 WS-Federation
   3.6 Niezawodna obsługa komunikatów
      3.6.1 WS-ReliableMessaging
   3.7 Transakcje
      3.7.1 WS-Coordination
      3.7.2 WS-AtomicTransaction
      3.7.3 WS-BusinessActivity
   3.8 Skład usługi
      3.8.1 BPEL4WS
4.0 Usługi sieci Web w praktyce — przykład
   4.1 Część 1: Środowisko klienta
   4.2 Część 2: Doświadczenie dostawcy
5.0 Wnioski
6.0 Potwierdzenia

1.0 Wprowadzenie

Obecnie usługi sieci Web — w szczególności usługi rozproszone, które przetwarzają komunikaty PROTOKOŁU SOAP zakodowane w formacie XML, wysyłane za pośrednictwem protokołu HTTP i opisane przy użyciu języka WSDL (Web Services Description Language) — są szeroko wdrażane. (Terminy XML, SOAP i HTTP są powszechnie używane dzisiaj i pod wieloma względami ich użycie wykraczało poza ich oryginalne akronimy. Aby uzyskać pełne nazwy tych akronimów, są wymienione tutaj: XML — eXtensible Markup Language, SOAP — Simple Object Access Protocol i HTTP — HyperText Transfer Protocol). Usługi internetowe są używane w wielu scenariuszach integracji aplikacji: od prostych, ad hoc, za zaporą, udostępniania danych do bardzo dużej skali handlu detalicznego internetowego i handlu walutami. Coraz częściej usługi sieci Web są stosowane w scenariuszach urządzeń przenośnych, urządzeń i sieci.

Usługi sieci Web zapewniają współdziałanie między składnikami oprogramowania, które mogą komunikować się między różnymi firmami i mogą znajdować się w różnych infrastrukturach. Rozwiązuje to jeden z najbardziej krytycznych problemów, z którymi borykają się klienci, deweloperzy oprogramowania i partnerzy. Protokoły HTTP i SOAP zapewniają współdziałanie komunikacji i komunikatów. Język WSDL zawiera opis usługi do obsługi współdziałania między narzędziami programistycznymi; uzupełnia współdziałanie komunikacji z możliwością wymiany definicji interfejsu.

Podstawowy zestaw specyfikacji usług sieci Web umożliwia klientom i dostawcom oprogramowania rozwiązywanie ważnych problemów. Opierając się na ich sukcesie, wielu deweloperów i firm jest gotowych do rozwiązywania trudniejszych problemów z technologią usług internetowych. Bardzo sukces usług sieci Web skłonił deweloperów do chęć jeszcze większej liczby możliwości z usług internetowych. Ponieważ znaczące narzędzia i współdziałanie komunikacji zakończyły się pomyślnie, deweloperzy oczekują teraz współdziałania rozszerzonych funkcji.

Oprócz podstawowej współdziałania komunikatów i wymiany interfejsów deweloperzy coraz częściej wymagają współdziałania usług aplikacji wyższego poziomu. Wiele aplikacji komercyjnych jest wykonywanych w środowisku ("oprogramowanie pośredniczące" lub "systemy operacyjne"), które zapewniają obsługę funkcji, takich jak zabezpieczenia i transakcje.

Firmy IBM, Microsoft i inne firmy w branży często proszony są o zapewnienie bezpieczeństwa, bardziej niezawodnych i lepszych możliwości obsługi transakcji w sieci Web. Ponadto prosimy o zapewnienie tych możliwości przy zachowaniu niezbędnej prostoty i współdziałania dostępnych obecnie w usługach sieci Web.

Ten dokument zawiera zwięzłe omówienie zestawu specyfikacji usług sieci Web, które odpowiadają tym potrzebom. Aby uzyskać szczegółowe informacje o specyfikacjach, dostarczamy odwołania do rzeczywistych dokumentów. Głównym celem tego dokumentu jest krótkie zdefiniowanie wartości, które te specyfikacje zapewniają naszym klientom. Opisujemy również, jak te specyfikacje uzupełniają się wzajemnie, aby tworzyć niezawodne środowiska dla aplikacji rozproszonych.

Stoimy przed kluczowym wyzwaniem inżynieryjnym: Jak zapewnić usługom internetowym nowe możliwości zabezpieczeń, niezawodności i transakcji bez dodawania większej złożoności niż jest to konieczne?

1.1 Usługi komponowalne

Zgodnie z protokołu SOAP i WSDL, IBM, Microsoft i nasi partnerzy przestrzegali zasady projektowania komponowania w definicji specyfikacji usług internetowych. Podejście, które wykonaliśmy, opiera się na zasadzie projektowania komponowania w definicji specyfikacji usług internetowych. Każda opracowana specyfikacja rozwiązuje natychmiastową potrzebę i jest cenna we własnym zakresie. Deweloperzy mogą na przykład wdrażać niezawodne komunikaty, aby uprościć opracowywanie rozwiązań lub wdrożyć BPEL4WS w celu zdefiniowania kompozycji usług. I chociaż każda specyfikacja jest sama w sobie, są one zaprojektowane do łączenia i pracy ze sobą.

Termin komposability używamy do opisywania niezależnych specyfikacji, które można połączyć w celu zapewnienia bardziej zaawansowanych możliwości. Dostawcy systemów operacyjnych i oprogramowania pośredniczącego mogą obsługiwać złożone możliwości, np. dostawcy mogą zintegrować niezawodną obsługę komunikatów na potrzeby komunikacji BPEL4WS procesów. Ten przykład łączy dwie niezależne specyfikacje, aby uprościć opracowywanie procesów komunikacyjnych, eliminując konieczność obsługi błędów komunikacji komunikatów podczas projektowania procesu.

Komposability umożliwia przyrostowe użycie lub postępowego odnajdywania nowych pojęć, narzędzi i usług. Deweloperzy muszą tylko uczyć się i implementować niezbędne elementy i nie tylko. Złożoność rozwiązania zwiększa się tylko dlatego, że wymagania problemu rosną i nie wynika z technologii "wzdęć".

Komposability ma i nadal jest jednym z kluczowych celów projektowych dla usług sieci Web. W ciągu ostatnich kilku lat zdefiniowaliśmy najbardziej podstawowe specyfikacje usług internetowych (SOAP i WSDL), aby z natury obsługiwać kompozycję. Jedną z podstawowych cech usługi sieci Web jest zwykła, wieloczęściowa struktura komunikatów. Ta struktura umożliwia kompozycji nowych funkcji. Nowe elementy komunikatów obsługujące nowe usługi mogą być dodawane do komunikatów w sposób, który nie zmienia przetwarzania istniejących funkcji. Na przykład można niezależnie dodawać identyfikatory transakcji i niezawodne numery sekwencji komunikatów. Te dwa rozszerzenia nie powodują konfliktu ze sobą i są zgodne ze wstępnie istniejącymi strukturami komunikatów.

Rysunek 1. Możliwość komponowania umożliwia używanie elementów zgodnie z potrzebami.

Rysunek 1 przedstawia prosty komunikat usług sieci Web zawierający elementy adresowania WS, WS-Securityi WS-ReliableMessaging. Zwróć uwagę, że elementy adresowania WS, WS-Security i WS-ReliableMessaging są niezależne, a te elementy mogą być używane niezależnie bez zmiany przetwarzania innych elementów.

Ta cecha umożliwia definiowanie zabezpieczeń, niezawodności i transakcji pod względem komponowalnych elementów komunikatów.

Pojęcie kompozycji umożliwia również utworzenie określonego zestawu dobrze zdefiniowanych usług sieci Web obsługujących zabezpieczenia, niezawodność itp. Te dobrze zdefiniowane usługi określają zachowanie usług niezbędnych do obsługi funkcji usług sieci Web wyższego poziomu. Przykładem jest usługa bezpiecznego tokenu zdefiniowana w WS-Trust, która wystawia i weryfikuje elementy zabezpieczeń w komunikatach.

Ponadto ważne jest, aby użytkownicy usługi mogli określić obsługiwane i wymagane gwarancje usług. Usługi muszą udokumentować swoje wymagania i obsługę transakcji, zabezpieczeń, niezawodnych komunikatów itp., WS-Policy umożliwia usługom sieci Web przyrostowe rozszerzanie języka WSDL w celu udokumentowania funkcji transakcji, zabezpieczeń i niezawodności, które obsługują lub wymagają. WSDL i WS-Policy umożliwiają tworzenie opisu usług. To z kolei umożliwia innym stronom zrozumienie, jakie elementy komunikatów i usługi wyższego poziomu należy stosować podczas interakcji z usługą.

1.2 Przykład kompozycji w praktyce

Rysunek 2 zawiera omówienie przedstawiające kompozycję w praktyce. Klient i dostawca używają usług sieci Web do przetwarzania zamówień.

Rysunek 2. Kompozycja w systemie przetwarzania zamówień

W tworzeniu tych usług sieci Web deweloperzy używają języka WSDL i powiązanych dokumentów do opisywania interfejsu biznesowego. Te dokumenty WSDL opisują zestaw komunikatów, które będą przetwarzane przez klienta i dostawcę usług sieci Web, np. komunikat SubmitPurchaseOrder (SubmitPO), który przepływa od klienta do dostawcy. Jest to wyświetlane w górnej części rysunku 2. Po utworzeniu podstawowych elementów aplikacji deweloperzy mogą zdecydować się na obsługę dodatkowej możliwości, na przykład w tym miejscu decydują się na dokonanie transakcji przetwarzania zamówień. W tym celu utworzyć następujących elementów w istniejącej strukturze:

Usługi kojarzą WS-Policy dokumentów opisujących ich obsługę transakcji z opisem usług WSDL. Należy pamiętać, że te instrukcje zasad rozszerzają się, ale nie zmieniają zasadniczo istniejącej funkcjonalności biznesowej.
Aby obsługiwać przetwarzanie transakcyjne, usługi dodaj dodatkowy element komunikatu opisujący transakcje, które komponują się z, ale zasadniczo nie zmieniają istniejących komunikatów aplikacji.
Gdy usługa dostawcy odbiera komunikaty zawierające element transakcji, używa tych informacji do komunikowania się z wyznaczoną usługą sieci Web nazywaną koordynatorem obsługującym funkcję transakcji. Ponownie ta dodatkowa usługa sieci Web jedynie dodaje do rozwiązania i nie wymaga modyfikacji opisu istniejących funkcji biznesowych.
Na koniec usługi mogą implementować dodatkowe operacje w celu obsługi integracji z usługą koordynatora transakcji.

Na powyższej ilustracji wyróżniono te dodatkowe elementy.

Model jest przyrostowy i komponowalny, ponieważ:

Dodawanie nowych funkcji można wykonywać niezależnie od dodawania innych funkcji.
Dodanie funkcji nie zakłóca istniejących komunikatów, logiki przetwarzania komunikatów ani języka WSDL.

Komposability jest coraz ważniejszą zasadą projektowania, ale podejście nie zawsze jest zrozumiałe. Chociaż poszczególne specyfikacje usług sieci Web definiują sposób współdziałania poszczególnych elementów i usług, ten oficjalny dokument ma na celu przedstawienie sposobu tworzenia kolekcji specyfikacji w celu zapewnienia bardziej zaawansowanych usług sieci Web.

2.0 Usługi sieci Web: architektura Service-Oriented

W ostatnich latach byliśmy świadkami lawiny aktywności skoncentrowanej na rozwoju usług internetowych. W przypadku wszystkich tych działań ważne jest, aby cofnąć się i zadać pytanie: "Dlaczego?" Z pewnością usługi sieci Web nie umożliwiają nowych rodzajów możliwości obliczeniowych — po tym, jak wszystkie usługi sieci Web nadal działają na istniejących komputerach, wykonując ten sam zestaw instrukcji i uzyskiwanie dostępu do tych samych danych. Ponadto protokoły usługi sieci Web w wielu przypadkach mogą rzeczywiście zwiększyć obciążenie protokołu dla danego zadania.

Jednym z kluczowych powodów, dla których widzimy takie zainteresowanie usługami sieci Web, jest to, że usługi sieci Web są odpowiednie do włączenia architektury Service-Oriented (SOA). W przypadku korzystania z usług sieci Web do tworzenia SOA rozwiązania składają się z kolekcji usług autonomicznych, identyfikowanych przez adresy URL, z interfejsami udokumentowanymi przy użyciu języka WSDL i przetwarzaniem dobrze zdefiniowanych komunikatów XML. SOA to naturalne uzupełnienie zorientowanych na obiekt (OO), proceduralnych i skoncentrowanych na danych podejściach do implementacji rozwiązań. W rzeczywistości podczas tworzenia systemu SOA poszczególne usługi są zwykle konstruowane przy użyciu co najmniej jednej z tych technologii.

Architektura Service-Oriented różni się od systemów OO i proceduralnych w jednym kluczowym aspekcie: powiązania. Services współdziałają w oparciu o , jakie funkcje udostępniają i sposób ich dostarczania. OO i systemy proceduralne łączą elementy na podstawie typu lub nazwy. Poniższe sekcje zawierają więcej szczegółów.

2.1 Usługi są opisywane przez schemat, a kontrakt nie jest typem

W przeciwieństwie do poprzednich systemów model usługi sieci Web nie działa na pojęcie typów udostępnionych, które wymagają wspólnej implementacji. Zamiast tego usługi współdziałają wyłącznie z kontraktami (WSDL/BPEL4WS na potrzeby zachowania przetwarzania komunikatów) i schematami (WSDL/XSD dla struktury komunikatów). Dzięki temu usługa może opisać strukturę komunikatów, które mogą wysyłać i/lub odbierać i sekwencjonować ograniczenia dotyczące tych komunikatów. Separacja między strukturą a zachowaniem a jawnym, weryfikowalnym opisem tych cech maszyn upraszcza integrację w środowiskach heterogenicznych.

Ponadto te informacje wystarczająco scharakteryzują interfejs usługi, dzięki czemu integracja aplikacji nie wymaga współużytkowanego środowiska wykonawczego w celu utworzenia struktury komunikatów lub zachowania.

Model zorientowany na usługi zakłada w pełni rozproszone środowisko, w którym trudno, jeśli nie jest to niemożliwe, propagować zmiany w schemacie i/lub umowie do wszystkich stron, które napotkały usługę. Orientacja usługi oznacza, że kontrakty i schemat powinny pozostać zgodne z poprzednimi wersjami i mogą zawierać informacje, które są nieukończone przez określone systemy przetwarzania.

Z tego powodu technologie kontraktu i schematu przeznaczone do użytku w projektach zorientowanych na usługi zapewniają większą elastyczność niż tradycyjne interfejsy obiektowe. W szczególności usługi używają funkcji, takich jak symbole wieloznaczne elementu XML (np. xsd:any), rozszerzenia schematu i opcjonalne bloki nagłówka PROTOKOŁU SOAP, aby rozwijać usługi w sposób, który nie przerywa wdrożonych aplikacji. Te cechy są kluczem do komponowania usług sieci Web.

2.2 Zgodność usługi jest większa niż zgodność typu

Projekty proceduralne i obiektowe zwykle są zgodne ze zgodnością semantyczną. Orientacja usługi zapewnia bogatszy model określania zgodności. Zgodność strukturalna jest oparta na umowie (WSDL i opcjonalnie BPEL4WS) i schemacie (XSD) i można je zweryfikować. Ponadto pojawienie się WS-Policy zapewnia dodatkową zautomatyzowaną analizę zgodności zapewniania bezpieczeństwa usług między usługami. Jest to wykonywane na podstawie jawnych asercji możliwości i wymagań w postaci instrukcji WS-Policy.

Korzystając z usługi WS-Policy, usługi opisują swoje możliwości i wymagania dotyczące zapewniania usług w postaci wyrażenia zasad czytelnego dla maszyny zawierającego kombinacje asercji. Dzięki temu usługa może wybierać się nawzajem w oparciu o "jak" lub "z jaką jakością" dostarczają swoje kontrakty,

Asercji zasad są identyfikowane przez stabilne i globalnie unikatowe nazwy, których znaczenie jest spójne w czasie i przestrzeni bez względu na to, do której usługi zastosowano asercji. Asercji zasad mogą również mieć parametry, które kwalifikują dokładną interpretację twierdzenia.

2.3 Orientacja usługi zakłada, że złe rzeczy mogą i będą się zdarzać

Niektóre poprzednie podejścia do aplikacji rozproszonych jawnie zakładały wspólną przestrzeń typów, model wykonywania i model referencyjny procedury/obiektu. W istocie model programowania "w pamięci" zdefiniował model systemu rozproszonego.

Orientacja usługi po prostu zakłada, że usługi są wykonywane autonomicznie i nie ma pojęcia lokalnego wykonywania ani wspólnego środowiska operacyjnego. Z tego powodu SOA jawnie zakłada, że typowe są błędy komunikacji, dostępności i typu.

Aby zachować integralność systemu, projekty zorientowane na usługi jawnie polegają na różnych technologiach do obsługi asynchronicznych i częściowych trybów awarii. Techniki, takie jak obsługa komunikatów asynchronicznych, transakcje, niezawodne komunikaty i nadmiarowe wdrażanie, są normą w systemach zorientowanych na usługi.

Ponadto, w przeciwieństwie do modelu w pamięci, orientacja usługi zakłada, że nie tylko wiadomość przychodząca może być źle sformułowana, ale także, że mogła zostać przesłana do złośliwych lub całkowicie nieoczekiwanych celów. W związku z tym systemy zorientowane na usługi chronią się, umieszczając ciężar dowodu na wszystkich nadawców komunikatów, wymagając od aplikacji udowodnienia, że wymagane prawa zostały przyznane nadawcy. Spójne z pojęciem autonomii usługi architektury zorientowane na usługi zwykle polegają na relacjach zaufania zarządzanych przez administratora, aby uniknąć mechanizmów uwierzytelniania dla poszczególnych usług typowych w klasycznych aplikacjach internetowych.

2.4 Orientacja usługi umożliwia elastyczne powiązanie usług

Jedną z podstawowych koncepcji architektury zorientowanej na usługi (SOA) jest elastyczne powiązanie usług. Bardziej tradycyjne modele proceduralne, składowe i obiekty wiążą składniki ze sobą za pomocą odwołań (wskaźników) lub nazw. SoA obsługuje bardziej dynamiczne odnajdywanie wystąpień usługi, które zapewniają interfejs, semantyka i gwarancje usług, których oczekuje żądający.

W systemach proceduralnych lub obiektowych obiekt wywołujący zazwyczaj znajduje serwer na podstawie typów, które eksportuje lub współdzieloną przestrzeń nazw. W systemie SOA wywołujące mogą wyszukiwać rejestry, takie jak udDI dla usługi.

Jest to komunikat zgodny z wymaganiami wywołującego. Zgodność może wystąpić za pośrednictwem języka WSDL lub pasujących komunikatów ze znanych schematów XML.
Dokumenty te obsługują zabezpieczenia usług wymagane przez obiekt wywołujący. Na przykład obiekt wywołujący może wymagać pewnych podejść do zabezpieczeń lub transakcji.

Luźne powiązanie w odniesieniu do implementacji usługi, która umożliwia alternatywne implementacje zachowania, może służyć do spełnienia szeregu wymagań biznesowych. Na przykład alternatywne wdrożenia mogą odpowiadać alternatywnym dostawcom w łańcuchu dostaw, co umożliwia szybsze reagowanie na zmieniające się warunki rynkowe. Podobnie alternatywna implementacja może być geograficznie rozproszonych centrów danych, co pozwala na odporność na awarie.

3.0 Specyfikacje i funkcje usług sieci Web

Ta sekcja zawiera omówienie specyfikacji usług sieci Web.

3.1 Podejście komponowalne do usług sieci Web

W tej sekcji krótko opisano dostępne specyfikacje usługi sieci Web. Wyjaśniamy ich wartość dostawcom rozwiązań, ich rolę w szerszej architekturze i tym, jak się uzupełniają.

Na poniższej ilustracji przedstawiono ogólne grupowanie specyfikacji usług internetowych opublikowanych przez IBM, Microsoft i inne. Należy pamiętać, że ta ilustracja nie oznacza ścisłej warstwy między grupami; zamiast tego ma na celu zapewnienie intuicji dotyczącej relacji między obszarami funkcjonalnymi. Na przykład zabezpieczenia komunikatów nie wymagają opisu, a podobnie opis to przydatna koncepcja czasu programowania dla obsługi komunikatów.

Rysunek 3. Architektura protokołu usług sieci Web z możliwością współdziałania

3.2 Podstawy — transporty i komunikaty

Jeśli wyślem ci list napisany w języku francuskim, ale spodziewałeś się rozmowy telefonicznej w języku angielskim, nie będziemy się komunikować. Współdziałanie usług sieci Web stoi w obliczu tego samego problemu; w tym celu udostępniamy wspólny zestaw transportów i technologii obsługi komunikatów.

Ponadto, aby upewnić się, że te technologie są skuteczne w praktyce, IBM, Microsoft i inne stworzyły organizację współdziałania usług sieci Web (WS-I). Niedawno WS-I wydała podstawowy profil, który formalnie dokumentuje współdziałanie mechanizmów transportu i obsługi komunikatów usług internetowych.

3.2.1 Transporty — HTTP, HTTP/S, SMTP

Ten zestaw specyfikacji definiuje podstawowe mechanizmy komunikacyjne służące do przenoszenia danych pierwotnych między usługami sieci Web.

Przykłady protokołów HTTP, HTTP/S i Simple Mail Transport Protocol (SMTP) należą do tej grupy. Implementacje usług sieci Web mogą dodatkowo obsługiwać inne transporty, ale niezwykle ważne jest zapewnienie obsługi standardowych, współdziałalnych protokołów.

3.2.2 Formaty komunikatów — XSD

Kolejna grupa specyfikacji definiuje mechanizmy współdziałania kodowania komunikatów usługi sieci Web na potrzeby transportu. Transporty przenoszą bloki "bajtów" między usługami. Jest to przydatne tylko wtedy, gdy uczestnicy mogą konwertować bajty na przydatne struktury danych, które przetwarza ich aplikacja.

Grupa specyfikacji obsługi komunikatów definiuje sposób poprawnego formatowania komunikatów. Definicje schematu XML i XML zapewniają mechanizm abstrakcyjnego uzgadniania struktur komunikatów (danych). protokołu SOAP definiuje standardowe kodowanie do reprezentowania komunikatów XML w informacjach bajtowych, które usługi wymieniają się za pośrednictwem transportu.

3.2.3 WS-Addressing

Komunikaty i odpowiedzi idą gdzieś i pochodzą z miejsca. adresowania WS zapewnia współdziałanie, niezależne od transportu podejście do identyfikowania nadawców i odbiorników wiadomości. WS-Addressing zapewnia również bardziej szczegółowe podejście do identyfikowania określonych elementów w usłudze, która wysyła lub powinna otrzymywać komunikat.

Obecnie większość systemów korzystających z usług sieci Web koduje miejsce docelowe komunikatu usługi sieci Web przy użyciu adresu URL umieszczonego w transporcie HTTP. Miejsce docelowe odpowiedzi jest określane przez adres transportu zwrotnego. To podejście opiera się na podstawowym modelu serwera przeglądarki HTTP.

Korzystając z dzisiejszego podejścia, informacje źródłowe i docelowe nie są częścią samego komunikatu. Może to spowodować kilka problemów. Informacje mogą zostać utracone, jeśli połączenie transportowe zakończy się (na przykład jeśli odpowiedź trwa długo i przekroczono limit czasu połączenia) lub jeśli komunikat jest przekazywany przez pośrednika, takiego jak zapora.

WS-Addressing udostępnia mechanizm umieszczania elementu docelowego, źródła i innych ważnych informacji o adresie bezpośrednio w komunikacie usługi sieci Web. Krótko mówiąc, WS-Addressing rozdziela informacje o adresach z dowolnego konkretnego modelu transportu.

W wielu scenariuszach komunikaty są kierowane bezpośrednio do usługi, a informacje dotyczące adresowania w komunikacie można opisać po prostu przy użyciu adresu URL. Jednak w praktyce często zdarza się, że komunikaty są przeznaczone dla określonych elementów lub zasobów w usłudze. Na przykład usługa koordynacji może koordynować wiele różnych zadań. Koordynator musi skojarzyć większość komunikatów przychodzących z konkretnym wystąpieniem zadania, które zarządza, a nie samą usługą koordynacji.

WS-Addressing udostępnia prosty, ale zaawansowany mechanizm nazywany odwołaniem do punktu końcowego do adresowania jednostek zarządzanych przez usługę. Chociaż takie informacje mogą być kodowane w sposób ad hoc w adresie URL usługi, odwołania do punktów końcowych udostępnia standardowy element XML, który umożliwia ustrukturyzowane podejście do kodowania tego szczegółowego adresowania.

Połączenie precyzyjnej kontroli nad adresowaniem w połączeniu z kodowaniem neutralnym transportowo źródła i miejsca docelowego wiadomości umożliwia wysyłanie komunikatów usługi sieci Web w wielu transportach, za pośrednictwem pośredników i umożliwia zarówno asynchroniczne, jak i rozszerzone wzorce komunikacji.

WS-Addressing umożliwia również nadawcy wskazanie, gdzie powinna działać odpowiedź w sposób niezależny od transportu. Odpowiedź na komunikat może niekoniecznie zostać wysłana do nadawcy. Na przykład w protokole HTTP bez WS-Addressing nie można określić, że odpowiedź powinna być wysyłana gdzie indziej.

Te ulepszenia modelu obsługi komunikatów umożliwiają korzystanie z usług sieci Web do obsługi wielu scenariuszy biznesowych. Na przykład niektóre zadania bankowe wymagają przeglądu przez człowieka w celu zatwierdzenia w określonych krokach. Zwykle istnieje wiele aktywnych wystąpień zadania w dowolnym momencie. WS-Addressing zapewnia ogólny mechanizm kojarzenia przychodzących lub wychodzących komunikatów z określonymi zadaniami. Mechanizm używany przez usługę jest niewidoczny dla użytkowników korzystających z usługi za pośrednictwem odwołania do punktu końcowego.

Opis 3.3

Specyfikacje transportu i komunikatów umożliwiają usługom sieci Web komunikowanie się przy użyciu komunikatów. Ale jak uczestnicy wiedzą, czym są wiadomości? Jak dokument usługi sieci Web lub opisuje wysyłane i odbierane komunikaty? Korzystanie z usługi sieci Web wymaga zrozumienia komunikatów, które usługa sieci Web będzie używać i tworzyć — interfejs dla usługi sieci Web. Grupa opisów specyfikacji umożliwia usłudze sieci Web wyrażanie interfejsu i możliwości.

Oprócz współdziałania komunikatów; te specyfikacje umożliwiają również współdziałanie narzędzi programistycznych. Specyfikacje opisu zawierają standardowy model, który umożliwia różnym dostawcom wspólne wsparcie dla deweloperów. W ten sam sposób, w jaki usługi sieci Web izolować partnerów od wyboru implementacji i infrastruktury, specyfikacje opisu izolować partnerów od wyborów narzędzi programistycznych.

3.3.1 WSDL

Web Services Description Language (WSDL) i schematu XML (XSD) są podstawowymi specyfikacjami w tej grupie. Schemat XML umożliwia deweloperom i dostawcom usług definiowanie typów XML dla struktur danych, np. zamówienia zakupu i komunikatów, np. komunikatu CreatePO. Usługa WSDL umożliwia usłudze sieci Web dokumentowanie odbieranych i wysyłanych komunikatów. Innymi słowy, co "akcje" lub "funkcje" usługa wykonuje pod względem odbieranych i wysyłanych komunikatów.

WSDL zapewnia obsługę różnych wzorców interakcji komunikatów. Obsługuje jednokierunkowe komunikaty wejściowe, które nie mają odpowiedzi, żądania/odpowiedzi i jeden sposób wysyła z odpowiedzią lub bez niej. Ostatnie dwa wzorce umożliwiają usłudze określanie innych potrzebnych usług.

Proponowane ulepszenia języka WSDL zapewniają obsługę dokumentowania protokołów i formatów komunikatów, które obsługuje usługa, oraz adres usługi.

3.3.2 WS-Policy

Definicje WSDL i XSD często nie udostępniają wystarczającej ilości informacji, aby wywołać usługę sieci Web. WSDL i XSD definiują składnię interfejsu usługi, ale nie wyrażają informacji na temat sposobu, w jaki usługa dostarcza interfejs lub czego usługa oczekuje od obiektu wywołującego. Czy na przykład usługa wymaga zabezpieczeń lub implementuje transakcje?

WS-Policy umożliwia usłudze określenie, czego oczekuje od wywołujących i sposobu implementowania interfejsu. WS-Policy ma kluczowe znaczenie dla osiągnięcia współdziałania na wyższym poziomie funkcjonalności usługi. Zabezpieczenia, transakcje, niezawodne komunikaty i inne specyfikacje wymagają konkretnego schematu WS-Policy. Umożliwiają one usługom opisywanie gwarancji funkcjonalności, której oczekują od osób wywołujących i ich dostarczanie.

Platforma WS-Policy udostępnia model podstawowy do definiowania wyrażeń zasad.

WS-Policy obsługuje gramatykę agregacji instrukcji zasad i umożliwia konstruowanie bardziej elastycznych i kompletnych zestawów zasad.

WS-PolicyAttachment określa sposób kojarzenia zestawu zasad z komunikatami XML i elementami WSDL (operacje i typy portów).

Razem WS-Policy i WS-PolicyAttachment zapewniają strukturę. Poszczególne specyfikacje definiują instrukcje zasad i schemat specyficzne dla domeny.

Na koniec @PageWS-PolicyAssertions udostępnia podstawowy zestaw wspólnych instrukcji zasad, których można użyć do osiągnięcia współdziałania.

3.3.3 Uzyskiwanie opisów

Obsługa języków XML, XSD, WSDL i WS-Policy opisujących interfejs i gwarancje usług dla usługi. Jak jednak potencjalni użytkownicy usługi znajdą te informacje?

Obecnie najczęstszym podejściem jest wymiana wiadomości e-mail lub wyrazy ust. Konieczne jest bardziej ogólnego przeznaczenia skalowalny model. Istnieją dwie opcje. Usługa może przejść bezpośrednio do usługi, aby uzyskać informacje przy użyciu WS-MetadataExchange lub może zdecydować się na użycie usługi UDDI, która agreguje te informacje dla wielu usług docelowych.

Deweloperzy używają WS-MetadataExchange, gdy mają odwołanie do usługi i muszą zrozumieć, co robi. Deweloperzy używają funkcji UDDI, gdy chcą znaleźć odwołanie do usługi obsługującej określony zestaw funkcji.

3.3.4 WS-MetadataExchange

Jak opisano powyżej, usługi zazwyczaj udostępniają informacje, takie jak WSDL, WS-Policy i XSD, które opisują samą usługę. Zbieralność odnosimy się do informacji o usłudze jako metadanych. Specyfikacja WS-MetadataExchange umożliwia usłudze dostarczanie metadanych innym osobom za pośrednictwem interfejsu usług sieci Web. Biorąc pod uwagę tylko odwołanie do usługi sieci Web, potencjalny użytkownik może uzyskać dostęp do zestawu operacji WSDL/SOAP w celu pobrania metadanych opisujących usługę. Klienci mogą używać WS-MetadataExchange w czasie projektowania, podczas tworzenia klientów lub w czasie wykonywania.

3.3.5 UDDI

Często warto zbierać metadane dotyczące kolekcji usług i udostępniać informacje w postaci, która jest przeszukiwalna. Takie usługi agregacji metadanych to przydatne repozytorium, w którym organizacje mogą publikować usługi, które udostępniają, opisywać interfejsy swoich usług i włączać taksonomie specyficzne dla domeny usług. Specyfikacja uniwersalnego opisu i odnajdywania (UDDI) definiuje usługę agregacji metadanych.

Rozwiązania mogą wysyłać zapytania dotyczące interfejsu UDDI w czasie projektowania w celu znalezienia usług zgodnych z ich wymaganiami. Deweloperzy mogą używać tych usług w definicji ich BPEL4WS przepływów pracy, na przykład. Rozwiązania mogą również wykonywać zapytania dotyczące interfejsu UDDI w czasie wykonywania. W tym scenariuszu obiekt wywołujący "wie" interfejs, którego wymaga, i wyszukuje usługę, która spełnia wymagania funkcjonalne lub jest dostarczana przez znanego partnera.

Należy pamiętać, że jednym z mechanizmów, które mogą służyć do wypełniania usługi UDDI z metadanymi, jest uzyskanie metadanych z usług przy użyciu programu WS-MetadataExchange.

3.4 Zabezpieczenia usług

Usługi internetowe wygenerowały po części tyle entuzjazmu ze względu na ich zdolność do łączenia różnych systemów. Deweloperzy stworzyli wiele w pełni funkcjonalnych rozwiązań korzystających z podstawowych możliwości transportu, obsługi komunikatów i opisu. Jednak aby zostać zaakceptowane przez deweloperów tworzących bardziej zaawansowane rozwiązania integracji, usługi sieci Web muszą zapewniać funkcjonalność, aby zapewnić ten sam poziom gwarancji usług oferowanych przez bardziej tradycyjne rozwiązania oprogramowania pośredniczącego. To nie wystarczy, aby po prostu wymieniać wiadomości. Aplikacje i usługi znajdują się w oprogramowania pośredniczącego i systemach, które zapewniają cenne funkcje wyższego poziomu, takie jak zabezpieczenia, niezawodność i operacje transakcyjne. Usługi sieci Web muszą zapewnić mechanizm współdziałania między tymi funkcjami.

3.5 Zabezpieczenia

Ta rodzina specyfikacji @Pagema kluczowe znaczenie dla usług sieci Web między organizacjami. Te specyfikacje obsługują uwierzytelnianie i integralność komunikatów, poufność, zaufanie i prywatność. Obsługują one również federację zabezpieczeń między różnymi organizacjami.

3.5.1 WS-Security

WS-Security to podstawowy blok konstrukcyjny dla bezpiecznych usług sieci Web. Obecnie większość rozproszonych usług sieci Web polega na obsłudze poziomu transportu dla funkcji zabezpieczeń. Przykłady to uwierzytelnianie HTTP/S i BASIC-Auth. Te podejścia do zabezpieczeń zapewniają minimum niezbędne do bezpiecznej komunikacji. Jednak poziom zapewnianej przez nie funkcji jest znacznie mniejszy niż zapewniany przez istniejące środowiska pośredniczące i rozproszone.

Dwa przykłady podkreślają braki BASIC-Auth i HTTP/S.

A wysyła komunikat do usługi B. B częściowo przetwarza komunikaty i przekazuje je do usługi C. PROTOKÓŁ HTTP/S zezwala na uwierzytelnianie, poufność i integralność między A-B i B-C. Jednak C i A nie mogą się uwierzytelniać ani ukrywać informacji przed B.
W przypadku usług A, B i C do używania BASIC-Auth do uwierzytelniania. Muszą oni udostępniać te same replikowane informacje o użytkowniku i haśle. Jest to niedopuszczalne w wielu scenariuszach.

WS-Security rozwiązuje te problemy. Obsługuje:

Podpisane, zaszyfrowane tokeny zabezpieczające. Element może wygenerować token, który C może zweryfikować jako pochodzący z A. B nie może utworzyć tokenu.
Element może oznaczać wybrane elementy lub całą wiadomość. Dzięki temu usługa B i C może potwierdzić, że komunikat nie uległ zmianie od czasu wysłania go.
Element może przypieczętować komunikat lub wybrane elementy. Gwarantuje to, że tylko usługa przeznaczona dla tych elementów może korzystać z tych informacji. Uniemożliwia to usłudze B wyświetlanie informacji przeznaczonych dla języka C i na odwrót.

WS-Security używa istniejących modeli zabezpieczeń (Kerberos, X509 itp.). Specyfikacje określają konkretnie sposób używania istniejących modeli w sposób współdziałania. Obliczenia wieloskoku, wielopartyjnej usługi sieci Web nie mogą być bezpieczne bez zabezpieczeń WS..

3.5.2 WS-Trust

Zabezpieczenia opierają się na wstępnie zdefiniowanych relacjach zaufania. Protokół Kerberos działa, ponieważ uczestnicy "ufają" centrum dystrybucji kluczy Protokołu Kerberos. Infrastruktura kluczy publicznych działa, ponieważ uczestnicy ufają głównym urzędom certyfikacji. WS-Trust definiuje rozszerzalny model konfigurowania i weryfikowania relacji zaufania.

Kluczową koncepcją WS-Trust jest usługa Security Token Service (STS). StS to wyróżniająca się usługa sieci Web, która wystawia, wymienia i weryfikuje tokeny zabezpieczające. WS-Trust umożliwia usługom sieci Web konfigurowanie i uzgadnianie serwerów zabezpieczeń, którym "ufają" i poleganie na tych serwerach.

Usługa STS ma szeroką możliwość zastosowania, ponieważ może służyć do wystawiania tokenów zabezpieczających, które tworzą szeroką gamę asercji. W wielu przypadkach będzie używany do wystawiania tych samych asercji, ale w różnych formatach. Na przykład usługa STS może wydać token Kerberos twierdząc, że właściciel klucza jest Susan i może to zrobić na podstawie certyfikatu X.509 wystawionego przez zaufany urząd certyfikacji. Dzięki temu organizacje korzystające z różnych technologii zabezpieczeń mogą federować. Usługa STS może również wydać token zabezpieczający, twierdząc, że właściciel klucza jest członkiem grupy BankTellers na podstawie przychodzącego tokenu zabezpieczającego, który potwierdza oświadczenie tożsamości.

3.5.3 WS-SecureConversation

Niektóre scenariusze usługi sieci Web obejmują tylko krótką sporadyczną wymianę kilku komunikatów. WS-Security łatwo obsługuje ten model. Inne scenariusze obejmują długi czas trwania, konwersacje z wieloma komunikatami między usługami sieci Web. WS-Security obsługuje również ten model, ale rozwiązanie nie jest optymalne.

W tych scenariuszach istnieją dwa nie optymalne użycie WS-Security:

Powtarzające się użycie obliczeń kosztownych operacji kryptograficznych, takich jak weryfikacja klucza publicznego.
Wysyłanie i odbieranie wielu komunikatów przy użyciu tych samych kluczy kryptograficznych, zapewniając więcej informacji, które umożliwiają atakom siłowym "złamanie kodu".

Z tych powodów protokoły, takie jak HTTP/S, używają kluczy publicznych do wykonywania prostych negocjacji definiujących kluczy specyficznych dla konwersacji. Ta wymiana kluczy umożliwia wydajniejsze implementacje zabezpieczeń, a także zmniejsza ilość informacji zaszyfrowanych przy użyciu określonego zestawu kluczy.

WS-SecureConversation zapewnia podobną obsługę WS-Security. Uczestnicy często używają WS-Security z kluczami publicznymi, aby rozpocząć "konwersację" lub "sesję" i użyć WS-SecureConversation, aby uzgodnić klucze specyficzne dla sesji na potrzeby podpisywania i szyfrowania informacji.

3.5.4 WS-Federation

WS-Federation umożliwia zestawom organizacji ustanowienie jednej domeny zabezpieczeń wirtualnych. Na przykład agent podróży, linia lotnicza i sieć hotelowa mogą utworzyć taką federację. Użytkownik końcowy, który "loguje się" do dowolnego członka federacji, skutecznie zalogował się do wszystkich członków. WS-Federation definiuje kilka modeli zapewniających zabezpieczenia federacyjne za pośrednictwem protokołów między WS-Trust a topologiami WS-SecureConversation.

Ponadto klienci często mają "właściwości", gdy zajmują się przedsiębiorstwem. Przykładem jest preferencja dla okien lub siedzeń na przejściach lub średniej wielkości samochodu. WS-Federation umożliwia członkom skonfigurowanie przestrzeni właściwości federacyjnej. Dzięki temu każdy uczestnik ma bezpieczny kontrolowany dostęp do informacji o właściwościach każdego członka na temat użytkowników końcowych.

Właściwości i informacje o osobach fizycznych mogą być ściśle przechowywane w celu ochrony prywatności lub dlatego, że informacje zapewniają przewagę konkurencyjną dla określonego członka. Aby spełnić te wymagania, WS-Federation obsługuje model pseudonimu . Użytkownicy uwierzytelnieni w biurze podróży wygenerowali "aliasy" w interakcjach z linią lotniczą lub hotelem. Chroni to prywatność użytkownika końcowego i przewagę konkurencyjną, jaką może uzyskać biuro podróży, wiedząc o właściwościach użytkowników.

3.6 Niezawodna obsługa komunikatów

W świecie internetu prawie wszystkie kanały komunikacyjne są zawodne. Wiadomości znikają. Przerwy w połączeniach.

Bez niezawodnego standardu obsługi komunikatów deweloperzy aplikacji usługi sieci Web muszą tworzyć te funkcje w swoich aplikacjach. Podstawowe podejścia i techniki są dobrze zrozumiałe, na przykład wiele systemów operacyjnych i oprogramowania pośredniczącego zapewnia, że komunikaty mają unikatowe identyfikatory, udostępniają numery sekwencji i używają ponownej transmisji w przypadku utraty komunikatów. Jeśli deweloperzy usługi sieci Web aplikacji implementują te modele w swoich aplikacjach. Mogą one podjąć różne założenia lub wybory projektowe, co spowoduje niewielkie, jeśli istnieje niezawodna obsługa komunikatów.

3.6.1 WS-ReliableMessaging

WS-ReliableMessaging definiuje mechanizmy, które umożliwiają usługom internetowym zapewnienie dostarczania komunikatów za pośrednictwem zawodnych sieci komunikacyjnych.

WS-ReliableMessaging zapewnia, że usługi implementują metody współdziałania, a także umożliwia dostawcom środowiska uruchomieniowego ułatwienie tworzenia aplikacji przez dostarczanie usług implementujących protokoły. Znacznie upraszcza to zadania tworzenia aplikacji. Logika biznesowa ma wówczas znacznie mniej warunków błędów, które musi obsłużyć.

Na koniec przemysł ma bogaty zestaw oprogramowania pośredniczącego zorientowanego na komunikaty w celu niezawodnego routingu i dystrybucji komunikatów. Każda implementacja używa zastrzeżonych protokołów. WS-Reliable Protokoły obsługi komunikatów umożliwiają niezawodne wymienianie komunikatów przez różne systemy operacyjne i pośredniczące. W związku z tym obsługuje mostkowanie dwóch różnych infrastruktury w jeden, logicznie kompletny, całościowy model.

3.7 Transakcje

Złożony scenariusz biznesowy może wymagać od wielu stron wymiany wielu zestawów komunikatów. Przykładem jest zestaw instytucji finansowych tworzących ofertę finansową, która obejmuje polisy ubezpieczeniowe, renty, konta kontrolne i konta brokerskie. Wiele komunikatów wymienianych między uczestnikami stanowi logiczne "zadanie" lub "cel".

Aby odniesieć sukces, strony muszą mieć możliwość:

Rozpocznij nowe skoordynowane zadania.
Kojarzenie operacji z ich zadaniem logicznym. Strony mogą jednocześnie konfigurować wiele kont dla różnych klientów.
Zgadzam się na wynik obliczeń. Czy na przykład wszyscy zgadzają się, że pakiety finansowe zostały skonfigurowane?

Koordynacja WS, WS-AtomicTransaction i WS-BusinessActivity obsługują te wymagania.

3.7.1 WS-Coordination

@Pagekoordynacji WS jest ogólnym mechanizmem uruchamiania i uzgadniania wyników wieloczęściowych zadań usługi sieci Web z wieloma komunikatami. WS-Coordination ma trzy kluczowe elementy:

Element komunikatu nazywany kontekstem koordynacji, który przepływa we wszystkich komunikatach wymienianych przez usługi sieci Web podczas obliczeń. Kontekst koordynacji zawiera odwołanie do punktu końcowego WS-Addressing do usługi koordynacji, a z kolei zawiera informacje identyfikujące koordynowane konkretne zadanie.
Usługa koordynatora . Usługa koordynatora zapewnia usługę opisaną przy użyciu języka WSDL, która zapewnia możliwość uruchamiania skoordynowanego zadania, kończenie koordynowanego zadania, umożliwienie uczestnikowi zarejestrowania się w zadaniu i utworzenie kontekstu koordynacji będącego częścią wszystkich komunikatów w grupie.
Usługa koordynacji obejmuje również interfejs zdefiniowany w WSDL, który uczestniczących usług używa w celu poinformowania o wyniku skoordynowanego zadania.

Usługa sieci Web, która odbiera komunikat z nowym kontekstem koordynacji rejestruje się w usłudze koordynacji w kontekście w celu odbierania informacji o wyniku. Inne specyfikacje mogą rozszerzyć tę platformę w celu zapewnienia określonych wymagań dotyczących domeny.

WS-Coordination to ogólna struktura i możliwości. WS-AtomicTransaction i WS-BusinessActivity rozszerzyć tę strukturę, aby umożliwić uczestnikom obliczeń rozproszonych niezawodne określanie wyników.

3.7.2 WS-AtomicTransaction

WS-AtomicTransaction definiuje określony zestaw protokołów, które podłączają się do modelu WS-Coordination w celu zaimplementowania tradycyjnych dwufazowych protokołów transakcji atomowej. Należy pamiętać, że niepodzielna, dwufazowa model jest tylko w odniesieniu do zaangażowanych usług. Witryny lub infrastruktura oferująca usługi mogą anonsować zatwierdzenie dwufazowe, ale należy użyć innego modelu wewnątrz przedsiębiorstwa, takiego jak rekompensata lub przechowywanie wersji. Ta wolność sprawia, że prosty model zatwierdzania dwufazowego jest bardziej przydatny w przypadku długotrwałych obliczeń internetowych.

3.7.3 WS-BusinessActivity

WS-BusinessActivity definiuje określony zestaw protokołów, które są podłączone do modelu WS-Coordination w celu zaimplementowania długotrwałych, opartych na rekompensatach protokołów transakcji. Podczas gdy BPEL4WS definiuje model transakcji dla procesów biznesowych, WS-BusinessActivity określa odpowiedni renderowanie protokołu. To ponownie jest przykładem komponowania specyfikacji usług sieci Web.

3.8 Skład usługi

Najbardziej górnym elementem warstw usługi internetowej jest kompozycja usługi. Kompozycja usługi umożliwia deweloperom "redagowanie" usług, które wymieniają komunikaty PROTOKOŁU SOAP i definiują swój interfejs w języku WSDL i WS-Policy do rozwiązania agregowanego. Agregacja jest skomponowaną usługą sieci Web.

3.8.1 BPEL4WS

Specyfikacja Business Process Execution Language for Web Services (BPEL4WS) obsługuje kompozycję usług. Umożliwia deweloperom definiowanie struktury i zachowania zestawu usług sieci Web, które wspólnie implementują udostępnione rozwiązanie biznesowe. Każdy element zestawu usług definiuje interfejs przy użyciu WSDL i WS-Policy. Skomponowane rozwiązanie jest samą usługą sieci Web, która obsługuje komunikaty HTTP/SOAP i definiuje interfejs przy użyciu języków WSDL i WS-Policy.

Kompozycja ma trzy aspekty: struktura , informacje i zachowanie . BPEL4WS wprowadza trzy konstrukcje wspierające każdy aspekt kompozycji.

partnerLink definiuje nazwane skojarzenie między usługą złożoną a usługą sieci Web, która uczestniczy w ogólnym rozwiązaniu. Usługa złożona i usługa uczestnicząca definiują swoje interfejsy nawzajem przy użyciu języków WSDL i WS-Policy. Przykładem może być związek między firmą produkcyjną a dostawcą.

Koncepcja partnerLink i interfejsy WSDL/WS-Policy między składem a partnerami definiują struktury kompozycji usług. Definiują one typy usług, które współpracują ze sobą w celu utworzenia kompozycji, oraz wiadomości, które wymieniają z którymi poziomami zapewniania (zabezpieczenia, transakcje itp.)

BPEL4WS zapewnia również obsługę definiowania informacji kompozycji usługi. BPEL4WS definiuje pojęcie zmiennej. Usługa złożona definiuje zestaw zmiennych, z których każda ma definicję XSD. Bieżący stan określonej usługi to stan jego zmiennych. Definiuje to, jakie komunikaty zostały odebrane lub wysłane.

Na koniec BPEL4WS obsługuje definiowanie zachowania usługi złożonej przez koncepcję działania . Zdefiniowana usługa BPEL4WS to zestaw działań lub "kroków", które definiują zachowanie usługi. Najbardziej podstawowe działania to wysyłanie wiadomości do partnera lub odbieranie wiadomości od partnera. Każdy komunikat odpowiada zmiennej. BPEL4WS zapewnia obsługę przenoszenia danych między zmiennymi.

Jednym z kluczowych aspektów działań BPEL4WS jest to, że BPEL4WS zapewnia specjalną obsługę definiowania zewnętrznego (publicznego) zachowania usług przez umożliwienie kontrolowanego korzystania z zachowań niedeterministycznych. Na przykład fakt, że kontrola kredytowa jest wykonywana w określony sposób w procesie decyzyjnym przyjęcia zamówienia zakupu, może być sprawą prywatną dla dostawcy. BPEL4WS umożliwia ukrycie procesu decyzyjnego przez usunięcie zachowania kontroli kredytowej z opisu procesu, ale pokazanie, że odpowiedź na żądanie zakupu może być akceptacja lub odrzucenie. Tego typu abstrakcyjny proces można używać w połączeniu z językiem WSDL do definiowania protokołów biznesowych między partnerami biznesowymi i pionowych domen branżowych, takich jak łańcuch dostaw.

BPEL4WS obsługuje również kilka podejść do kontrolowania przepływu wykonywania działań. Obejmują one sekwencjonowanie i przepływy oparte na grafach. BPEL4WS obsługują predykaty zmiennych w celu określenia ścieżek sterujących, które następuje w usłudze złożonej.

Podsumowując, BPEL4WS wykonuje dwa dodatki do wcześniej zdefiniowanych specyfikacji usługi sieci Web.

BPEL4WS rozszerza obsługę języka WSDL i WS-Policy do opisywania usług. BPEL4WS obsługują łączenie usług sieci Web w usługi agregujące i dokumentowanie skojarzeń między usługami, takich jak przepływ informacji i zachowanie. Zapewnia to obsługę współdziałania między wyższymi narzędziami warstwowymi obsługującymi wspólne projektowanie usług sieci Web.
BPEL4WS to język wykonywania . BPEL4WS umożliwia deweloperom pełne określenie zachowania złożonej usługi sieci Web. Firma IBM, Microsoft i inni partnerzy będą dostarczać środowiska, które wykonują dokumenty BPEL4WS i obsługują powiązanie czasu projektowania i wykonywania z partnerami.

4.0 Usługi sieci Web w praktyce — przykład

W poniższym scenariuszu pokazano, jak specyfikacje usług WS mogą być używane razem do tworzenia usług sieci Web, które zaspokajają rzeczywiste potrzeby. Scenariusz przedstawia przykład zaawansowanych funkcji dostępnych dla deweloperów ze względu na możliwość komponowania różnych specyfikacji usług WS.

Usługi sieci Web opisane w tym scenariuszu zostały utworzone na potrzeby wspólnego IBM-Microsoft demonstracji technologii, która odbyła się 17 września 2003 r. Zostały one użyte do utworzenia aplikacji, która jest współdziałalna, bezpieczna, niezawodna i transakcyjna; i to obejmuje granice organizacyjne.

Pokaz pokazuje działający przykład federacyjnego przetwarzania zamówień i systemu spisu zarządzanego dostawcy (VMI) dla dealera samochodów zamawiania części od producenta samochodów; producent z kolei uzyskuje części od dostawcy obsługującego wiele magazynów. Cała komunikacja aplikacji do aplikacji w systemie została utworzona wyłącznie przy użyciu protokołów usługi sieci Web opisanych wcześniej i uruchomionych na kolekcji komputerów z oprogramowaniem IBM i Microsoft.

Scenariusz dotyczy niektórych z najczęstszych aspektów prowadzenia działalności gospodarczej — interakcji między firmą detaliczną, jej hurtownią i dostawcą hurtowym. W scenariuszu pokazano, jak różne specyfikacje usług WS mogą być komponowane w celu automatyzacji podstawowych procesów biznesowych, takich jak:

Uwierzytelnianie w celu wymuszenia zabezpieczeń (WS-Security)
Federacja zaufania między różnymi organizacjami (WS-Trust i WS-Federation)
Wymiana danych w celu ukończenia transakcji (WS-AtomicTransaction)
Zapewnienie, że zamówienia zostały przesłane za pośrednictwem niezawodnej obsługi komunikatów (WS-ReliableMessaging)

4.1 Część 1: Środowisko klienta

Przykład zaczyna się od Heather, pracownika firmy o nazwie Auto Dealer, logując się do bezpiecznej witryny sieci Web intranet jej dealera. Ta witryna internetowa jest tworzona przy użyciu standardowych, gotowych technologii internetowych. Heather wchodzi na stronę za pomocą przeglądarki. Dostęp do witryny jest chroniony hasłem.

Rysunek 4. Heather loguje się do bezpiecznej intranetowej witryny internetowej swojej firmy i przechodzi do jej dostosowanej strony Moja strona.

Heather klika na mojej stronie. W tle aplikacja zbiera informacje z bazy danych spisu auto dealera. Jeśli poziomy spisu elementu spadną poniżej zdefiniowanego progu, raport zostanie wygenerowany i wyświetlony na stronie "Twoje alerty" na stronie Heather.

Heather widzi, że jej firma ma niski zapas na ostrzach wipera windshieldPro.

Heather klika link i jest bezproblemowo przekierowywany do bezpiecznej strony internetowej w ekstranetzie Auto Manufacturer, gdzie Heather może złożyć zamówienie. Środowisko jest bezproblemowe, ponieważ oprogramowanie auto dealera jest oparte na usługach internetowych. Usługa internetowa łącząca intranet auto dealera z ekstranetem Auto Manufacturer została skomponowana przy użyciu WS-Federation. WS-Federation gwarantuje, że poświadczenia zabezpieczeń przyznane przez jedną lokację są honorowane przez drugą lokację.

Oto jak to działa. Auto Dealer i Auto Manufacturer zgodzili się sfederować swoje strony. WS-Federation koordynuje serię komunikacji serwer-serwer. Gdy tylko Heather kliknęła link WindshieldPro, aby przejeźć ją na stronę internetową producenta samochodów, serwer strony internetowej producenta samochodów odpytywał swoją usługę autoryzacji, która z kolei odpytywała usługę autoryzacji auto dealera. Usługa autoryzacji Auto Dealer potwierdza, że Heather jest autoryzowanym użytkownikiem, przesyłającym poświadczenia wraz z nazwą dealera Heather, z powrotem do usługi autoryzacji producenta samochodów, która udziela dostępu Heather. Dzieje się tak bezproblemowo, że wszystkie notatki Heather jest to, że przeszła z jednej strony internetowej do innej.

Usługa sieci Web wysyła również zapytanie do bazy danych klienta Auto Manufacturer w celu zamawiania informacji połączonych z kontem Heathera. Informacje są prezentowane na spersonalizowanej stronie internetowej "Moja strona" Auto Manufacturer.

Rysunek 5. Tworzenie usługi internetowej przy użyciu WS-Federated umożliwia Heather bezproblemowe przejście ze swojej spersonalizowanej strony w auto dealerze do jej spersonalizowanej strony w firmie Auto Manufacturer.

Spersonalizowana strona internetowa Heather w ekstranetzie Auto Manufacturer pozwala jej zobaczyć, że obecnie nie ma zaległych zamówień; ma jedno zamówienie (dla 50 SuperTires) w podróży; i że jej lista ukończonych zamówień obejmuje 20 sztuk CDPlus i 50 jednostek Leather Cleaner.

Heather klika pozycję "Utwórz nowe zamówienie", a nowa strona zostanie wstępnie wypełniona częścią, której chce — bloki wiperu WindshieldPro i datę zamówienia. Wszystko, co musi wprowadzić, to ilość. Wszystkie inne informacje potrzebne do ukończenia zamówienia są wypełniane z bazy danych Auto Manufacturer.

Rysunek 6. Zamówienie można łatwo złożyć, ponieważ większość danych zamówienia została już zaimportowana z pliku Heather w bazie danych klienta Auto Manufacturer.

Heather przesyła zamówienie i wyszukuje dodatkowe przedmioty do zakupu, lub klika wylogowywanie, aby zakończyć sesję i uniemożliwić nikomu innemu złożenie zamówienia z jej komputera nienadzorowanego.

Należy pamiętać, że tworzenie usługi sieci Web z WS-Federation zapewniane zarówno auto dealerowi, jak i producentowi samochodów z niższymi kosztami administracyjnymi i zabezpieczeniami końcowymi. Bez tej technologii producent samochodów musiałby utrzymywać listę wszystkich autoryzowanych pracowników dealerskich i ich haseł. Byłoby to kosztowne, podatne na błędy i zmniejszyć bezpieczeństwo aplikacji.

Na przykład jeśli Heather zrezygnowała z pracy, jej konto użytkownika zostanie usunięte w auto dealerze. Ale jeśli administrator w salonie nie zapomniał skontaktować się z Producentem samochodów o jej odejściu, będzie nadal mieć dostęp do witryny zakupu. W przypadku usługi WS-Federation nie jest to problem, ponieważ jedynym systemem, który należy zmienić, jest usługa dostawcy tożsamości auto dealera. Systemy producenta automatycznego, zarówno aplikacja, jak i usługa autoryzacji, nie mają wrodzonej wiedzy o Heather, jej nazwie użytkownika lub jej haśle.

4.2 Część 2: Doświadczenie dostawcy

Chociaż Heather zamawia ostrze wipera WindshieldPro z Auto Manufacturer, minęło pół wieku od czasu, gdy firma rzeczywiście dokonała własnych ostrzy. Szyba przedniaPro ostrza wiperowe pochodzą od dostawcy, dostawcy.

Tony jest przedstawicielem handlowym dostawcy i zaczyna swój dzień, logując się do intranetu dostawcy, tak jak Heather zalogował się do intranetu auto dealera. Jednak zamiast używać standardowej przeglądarki internetowej, Tony współpracuje z aplikacją systemu Windows, która ma wbudowaną obsługę usług sieci Web.

Rysunek 7. Osobista strona Tony'ego w intranecie dostawcy przypomina mu, aby sprawdzić zamówienia i zapasy u jednego z jego głównych klientów, Auto Manufacturer.

Gdy Tony kliknie, aby sprawdzić zamówienia i spis, jego aplikacja używa usługi internetowej, aby poprosić o dane spisu, do których Tony może uzyskać dostęp.

Jednym z kluczowych aspektów żądania usług sieci Web na poziomie aplikacji dla danych jest to, że składa się z WS-Federation, który uwierzytelnia jego dostęp do ekstranetu producenta automatycznego.

Usługa sieci Web zwraca wyniki z powrotem do strony Dostawcy, na której jest wyświetlana według typu produktu i bieżącej liczby zapasów.

Rysunek 8. Usługa sieci Web wypełnia stronę Dostawcy Tony'ego danymi spisu z baz danych spisu producenta automatycznego. Żądanie zostało wykonane bezpiecznie, tworząc je za pomocą WS-Security i WS-Federation.

Dostawca zawarł umowę zakupu just in time z producentem samochodów. Tony ma uprawnienia do zapewnienia automatycznego zamówienia ponownego dostarczania w ramach spisu zarządzanego dostawcy (VMI) w imieniu producenta automatycznego, gdy zapasy spadną poniżej 20. Tony klika na WindshieldPro, aby złożyć zamówienie. Wszystkie komunikaty między tony i producentem automatycznym są chronione, ponieważ aplikacja jest obsługiwana przez usługi sieci Web składające się z ochrony WS-Security.

Rysunek 9. Umowa just in time z producentem auto pozwala Tony'owi na wprowadzenie zamówienia w imieniu firmy.

Aplikacja Tony'ego udostępnia mu ekran umożliwiający utworzenie żądań od dostawcy z zamówieniem zakupu producenta automatycznego. Tony zamawia 50 WindishieldPros czyszczenia, które mają być dostarczane bezpośrednio do producenta samochodów.

Gdy Tony kliknie przycisk OK, usługa magazynu, usługa sieci Web składająca się z transakcji niepodzielnych WS, WS-Security i WS-ReliableMessaging, próbuje złożyć zamówienie z inną usługą sieci Web, podrzędnymi usługami magazynu. Gdy odpowiedź nie zostanie natychmiast zwrócona z usługi magazynu (z powodu tymczasowej awarii sieci) WS-ReliableMessaging będzie nadal ponownie wysyłać zapytanie, dopóki nie otrzyma odpowiedzi.

Gdy usługa magazynu otrzyma zamówienie, przekazuje je wewnętrznie do dwóch fizycznych magazynów firmy. Ponieważ obejmuje to bazy danych między obydwoma magazynami, WS-AtomicTransaction jest używana do zapewnienia zachowania transakcyjnego między bazami danych.

Aplikacja Magazyn dzieli zamówienia między podrzędne usługi Magazynu w celu zapewnienia pokrycia zapasów, 70% zamówienia trafia do magazynu 1, a pozostałe 30% przechodzi do magazynu 2. Koordynator główny w magazynie głównym wysyła komunikat do głównego koordynatora magazynu 2 z prośbą o 30% zamówienia. Główny koordynator magazynu 2 sprawdza jego spis i wysyła komunikat do głównego koordynatora głównego magazynu głównego, że nie ma wystarczającej ilości zapasów.

Główny koordynator główny wiedząc, że nie ma wystarczającej ilości spisu anuluje całą transakcję i wysyła komunikat do aplikacji usługi sieci Web Tony wskazujący stan, poziomy zapasów i że transakcja została anulowana. Koordynator główny rozpoczyna wycofywanie transakcji i po zakończeniu wraca do magazynu, aby stwierdzić, że transakcja została anulowana.

Tony, z bieżącą wiedzą spisu, wysyła kolejne żądanie do magazynu. Koordynator główny koordynuje między innymi jednostkami transakcyjnymi (kontrolerem innych transakcji) i przesyła to żądanie do 2 magazynów przechodzących przez ten sam proces, co poprzednio. Używamy WS-Security do podpisywania całej treści komunikatu, więc bez względu na to, która domena jest w Tobie dostępna, wiesz, że jesteś bezpieczny.

Teraz koordynator główny zatwierdza transakcje, blokuje zasoby i kończy transakcję. Komunikat jest wysyłany z powrotem do Tony wskazujący, że transakcja została ukończona pomyślnie.

WS-AtomicTransaction komponuje się z WS-ReliableMessaging i WS-Security w tych komunikatach, aby zaoferować kompletny system rozproszony gotowy do użycia w przedsiębiorstwie.

5.0 Wnioski

Ibm, Microsoft i nasi partnerzy opracowują specyfikacje usług internetowych, które mogą być używane jako bloki konstrukcyjne nowej generacji zaawansowanych, bezpiecznych, niezawodnych, transakcyjnych usług internetowych.

Te specyfikacje są zaprojektowane w sposób modularny i komponowalny, tak aby deweloperzy mogli korzystać tylko z tych możliwości, których potrzebują. Ta "podobna do składników" możliwość komponowania pozwoli deweloperom tworzyć zaawansowane usługi internetowe w prosty i elastyczny sposób, jednocześnie wprowadzając tylko poziom złożoności dyktowanej przez określoną aplikację.

Ta technologia umożliwi organizacjom łatwe tworzenie aplikacji przy użyciu architektury Service-Oriented (SOA). Ponadto firmy IBM i Microsoft zademonstrowały bezpieczne, niezawodne, transakcyjne aplikacje SOA, które ilustrują bogactwo procesów biznesowych, które można utworzyć przy użyciu tego podejścia. Ponadto te pokazy działają w środowisku zabezpieczeń federacyjnych w środowisku heterogenicznym składającym się z oprogramowania IBM WebSphere i Microsoft .NET.

Przewidujemy, że te technologie usługi sieci Web będą dostępne w systemach operacyjnych, oprogramowania pośredniczącego z narzędziami, które ułatwią deweloperom korzystanie z tych technologii. Będzie to ekscytujące, aby zobaczyć aplikacje, które pojawiają się jako deweloperzy i organizacje używają tych systemów do tworzenia nowej generacji rozwiązań opartych na usługach internetowych.

6.0 Potwierdzenia

Chcemy uznać następujące osoby, które przyczyniły się do tych pomysłów: (alfabetyczne) Tony Andrews, Bob Atkinson, Keith Ballinger, Don Box, John Brezak, Allen Brown, Felipe Cabrera, Erik Christensen, George Copeland, Michael Coulson, Giovanni Della-Libera, Brendan Dixon, Mike Dusche, Colleen Evans, Max Feingold, Jeff Frey, Henrik Frystyk Nielsen, Praerit Garg, Omri Gazitt, Scot Gellock, Josh Gray, Martin Gudgin, MaryAnn Hondo, Destry Hood, Efim Hudis, Tomasz Janczuk, Jim Johnson, Ryan Johnson, Gopal Kakivaya, Chris Kaler, Johannes Klein, Scott Konersmann, Brian LaMacchia, Dave Langworthy, Andrew Layman, Paul Leach, Al Lee, Frank Leymann, Rodney Limprecht, Joe Long, Steve Lucco, John Manferdelli, Ashok Malhotra, Jonathan Marsh, Steve Millet, Angela Mills, Tony Nadalin, Martin Nally, Karla Norsworthy, Stefan Pharies, Scott Robinson, Yordan Rouskov, Sujay Sahni, Jeff Schlimmer, Oliver Sharp, Yasser Shohoud, Dan Simon, Jeff Spelman, Keith Stobie, Satish Thatte, Robert Wahbe, Elliot Waingold, Richard Ward, Sanjiva Weerawarana, Hervey Wilson, Eric Zinda.

Udostępnij za pośrednictwem