Certyfikacja usług Service Certification

Transkrypt

1 Certyfikacja usług Service Certification Idea oraz sposoby podejścia do oceny jakości usług Michał Juchnowicz Politechnika Warszawska Wydział Elektroniki i Technik Informacyjnych 14 stycznia 2007 r. Abstrakt - Jakość aplikacji stanowi pierwszy warunek uzyskania ogólno organizacyjnego sukcesu i wdrożenia architektur zorientowanych na usługi (SOA). Z tak wieloma połączonymi ze sobą częściami tworzącymi aplikacje mogące być dostarczone praktycznie wszędzie, testowanie nie jest zwykłym sposobem poszukiwania błędów w kodzie programistów czy problemów pojawiających się w danym interfejsie użytkownika. Procesy zapewnienia jakości oprogramowania muszą ewoluować wraz z architekturą, aby dokładnie testować proces biznesowy i utrzymywać kontekst poprzez cały cykl zadań. Niniejszy artykuł jest wstępem do zaproponowania optymalnego rozwiązania oceny jakości usług wchodzących w skład architektury SOA. Wstęp Wzrost zainteresowania usługami Web Service, różnorodność dostępnych usług oraz nowe sposoby wykorzystania, w sposób gwałtowny zwiększyły konkurencję pomiędzy dostawcami usług. Niestety, po kilku latach od pojawienia się koncepcji systemów zorientowanych usługowo nie pojawił się żaden ustandaryzowany sposób wyboru usług, wychodzący poza porównanie ceny, przejrzenie ich funkcjonalności czy analizę syntaktyczną. W przypadku dwóch usług oferujących tę samą funkcjonalność i mających tą samą cenę, użytkownik nie ma możliwości stwierdzenia, która usługa jest lepsza pod względem wymagań niefunkcjonalnych, takich jak na przykład czas dostępu czy czas realizacji. Problem ten stanowi piętę Achillesa architektury SOA w przypadku automatycznego wyboru usług, pozwalającego na budowanie całych procesów biznesowych i wymianę poszczególnych usług wchodzących w skład takiego procesu, bez ingerencji kogoś z zewnątrz. Dlatego niezbędne jest określenie sposobu i odpowiednich kryteriów wyboru najlepszej i najodpowiedniejszej usługi spośród wszystkich oferowanych. Pracę nad rozwiązaniem tego problemu trwają od pojawienia się architektury SOA. Celem niniejszego artykułu jest przedstawienie problemu określania i oceny jakości w architekturze zorientowanej na usługi. W pierwszym rozdziale staram się przedstawić sens oceny jakości usług. Drugi rozdział poświęciłem przedstawieniu ogólnie stosowanego rozwiązania określenia jakości usług, stosowanego nie tylko w informatyce. Trzeci, czwarty i piąty rozdział jest obszernym opisem obecnie rozwijanych rozwiązań. Przedstawiam tu podejścia do oceny i określania poziomów jakości, rozwiązania 1

2 wykorzystywane w procesie wyboru żądanej usługi oraz inne bardziej ogólne rozwiązania. Rozdział szósty jest podsumowaniem problemów związanych z obecnymi sposobami oceny jakości i propozycją rozwiązania wykorzystującego mocne strony przedstawionych podejść. 1. Idea oceny jakości usług Web Service y dostarczyły możliwości zmiany Internetu z bazy danych statycznych dokumentów w rynek e-biznesu. Termin ten odnosi się do wykonywania transakcji biznesowych w kontekście rozproszonym, obejmującym organizację, jej klientów i partnerów. E-biznes jest blokowany przez bariery integracji technicznej. Ostatnio rozpoczęto prace standaryzacyjne w celu dogonienia rozwoju biznesowego i umożliwiono integrację funkcjonalną dzięki dwóm czynnikom: standaryzacji architektur pośredniczących tzw. middleware i standaryzacji protokołów komunikacyjnych. Standardy opisu, oferowania oraz interakcji z usługami sieciowymi pozwoliły organizacjom integrować swoje systemy w jednakowy sposób. Struktura usług Web Service dostarcza platformę integracyjną, bazującą na WSDL języku opisu interfejsów usługi, UDDI katalogu usług i SOAP będącego mechanizmem komunikacji. Funkcjonalna integracja może uwzględniać także dostarczanie infrastruktury jednej organizacji przez drugą, jak to jest w przypadku na przykład dostawcy Internetu, dostawcy magazynów pamięci czy udostępniania serwerów aplikacyjnych. Dostarczanie to polega na wykorzystaniu standardowych i ustalonych architektur oraz technologii. 2. Umowa o jakości usług Udostępnianie między organizacyjnych usług nie stanowi jedynie problemu technicznego. Relacje usługowe stanowią także relacje biznesowe pomiędzy organizacjami, zdefiniowane w umowie. Organizacje muszą się spotkać, uzgodnić zasady współpracy, mieć pewność, że usługa, którą zakupili spełni ich wymagania, i tym samym oni spełnią oczekiwania swoich klientów. Ważnym aspektem umowy dla usług IT jest zbiór gwarancji jakości usług przekazywanych przez dostawcę usługi, zwanym często umową o jakości usług (SLA Service Level Agreement). Umowa o jakości usług (SLA) jest ustaleniem pomiędzy klientem a dostawcą, opisującym techniczne i nietechniczne właściwości usługi, uwzględniając wymagania jakości usług i odpowiednie miary jakości przy pomocy, których będzie mierzone i oceniane dostarczanie wymagań. Niestety większość dzisiejszych umów SLA ma postać zwykłych tekstowych dokumentów, a to oznacza, że muszą być one dostarczane i monitorowane ręcznie, co jest bardzo drogie. 3. Podejścia do oceny jakości usług IBM przedstawił specjalny język XML do specyfikacji, monitorowania i zarządzania umowami o jakości usług WSLA (Web Service Level Agreement)[1]. Składa się on z trzech części. Pierwsza część definiuje strony zaangażowane w umowie. Druga część zawiera definicje usług z informacją o monitorowanych obiektach usługi z przypisanymi odpowiednimi parametrami jakości usługi SLA. Każdemu parametrowi SLA przypisana jest miara jakości usług, definiująca sposób pomiaru i/lub liczbową wartość parametrów SLA. Przykładem takiej miary może być czas odpowiedzi. Jedna miara może być użyta przez wiele parametrów SLA, na przykład dla różnych usług Web Service. Aktualna wartość miary mierzona jest przy pomocy wytycznych pomiarowych lub obliczona przy pomocy funkcji. Usługa może być także powiązana z wieloma planami i wyzwalaczami opisującymi, kiedy przeprowadzać działania monitorowania i pomiaru. W skład trzeciej części wchodzą SLO docelowe poziomy usług. SLO opisuje gwarantowany stan parametrów SLA w określonym czasie. Część ta zawiera także opis czynności wykonywanych w szczególnych sytuacjach oraz harmonogramy i zdarzenia ewaluacyjne. Podczas gdy specyfikacja SLA dostarczona jest przy pomocy WSLA, aspekt monitorowania zgodności z przypisanym SLA zaimplementowany jest w SLA Compliance Monitor wchodzący w skład IBM Web Service Toolkit.[2] Firma Hewlett-Packard rozwinęła inny język dla formalnego przedstawienia SLA dla usług Web Service w języku XML, będący częścią WSML (Web Service Management Language).[3] Język ten zawiera opis okresów ważności SLA, zaangażowanych stron i zbiór SLO. Każde SLO zawiera opis dni i okresów, kiedy SLO jest ważne, a także zestaw klauzul. Klauzula opisuje jedną lub wiele rzeczy (np. operację), dla których przeprowadzany jest pomiar, okresy i zdarzenia (np. zakończenie operacji) wyzwalające ewaluację, 2

3 wzory pomiarów używane do ewaluacji, jedną boolowską funkcję oceniającą oraz opis czynności przeprowadzanej, gdy funkcja oceniająca zwróci fałsz. WSML nie zawiera opisu funkcji oceniających usługę. Funkcje te opisywane są w odpowiednim matematycznym języku XML, takim jak MathML. To pozwala na znaczną elastyczność, ale wymusza na kliencie i dostawcy usługi posiadanie infrastruktury wspierającej matematyczny język. Oba powyższe języki są zorientowane w kierunku zarządzania jakością w wewnętrznych scenariuszach organizacyjnych. Zakładają one istnienie dodatkowych infrastruktur pomiarowych i zarządczych na obu końcach transakcji. Następnym proponowanym rozwiązaniem jest język WSOL (Web Service Offerings Language), skupiający uwagę na ofercie usług, czyli formalnej specyfikacji klasy usług (tab.1).[4] Tab. 1. Przykładowe klasy usług Klasa usługi Złota Srebrna Brązowa Czas przetwarzania Wydajność 1 sek. 1,5 sek. 2,2 sek. 140 żądań /sek. 120 żądań /sek. 100 żądań /sek. Cena za 0,10 0,06 0,03 usługę Źródło: opracowanie własne W przeciwieństwie do umów SLA, oferty usług są w zasadzie nienegocjowanymi umowami dostawca usługi określa ofertę usługi, a klient wybiera jedną z zaproponowanych. WSOL zawiera formalne definicje ograniczeń, deklaracji zarządczych i konstrukcji ponownego użycia. Każde ograniczenie WSOL oznacza pewny warunek do ocenienia i/lub po wywołaniu jakiejś operacji lub okresowo w przyjętych odstępach czasu. W skład zawartych ograniczeń wchodzą ograniczenia funkcjonalne (warunki wstępne i końcowe, niezmienniki), ograniczenia niefunkcjonalne (gwarantowana jakość usługi dla klienta i jakość usługi wymagana od dostawcy Web Service u) i polityka autoryzacji. Deklaracje są konstrukcją przedstawiającą informacje zarządcze dotyczące określonej klasy usługi. W deklaracjach ujęte są odpowiedzialności stron, okresy ważności, ceny i kary pieniężne za nie wypełnienie ograniczeń określonych w pierwszej części. Konstrukcja ponownego użycia ułatwia tworzenie oferty nowej usługi, dzięki wykorzystaniu dziedziczenia, zawierania czy jako instancji. Dodatkowo WSOL zawiera specyfikację dynamicznych relacji ofert usług. Relacje te określają, jaka oferta usługi jest odpowiednim zamiennikiem w przypadku, gdy określone ograniczenie używanej usługi nie może być spełnione. Monitorowanie usług opisanych w WSOL, oraz implementacja algorytmów i protokołów dynamicznego dostosowywania usług możliwe jest dzięki zastosowaniu infrastruktury WSOI Web Service Offering Infrastructure (rys.1).[5] Rys. 1. Umiejscowienie WSOI Źródło: opracowanie własne na podstawie: Tosic V., Ma W., Pagurek B., Esfandiari B., Web Service Offerings Infrastructure (WSOI) a management infrastructure for XML Web services, IEEE Network Operations and Management Symposium, 2004 Umowy SLA w językach WSLA i WSML zawierają gwarancje poziomu usług w postaci SLO i informację zarządczą jak na przykład odpowiedzialności stron czy ceny. WSOL nie specyfikuje umów SLA, ale określa oferty usług (gwarancje i wymagania) i informacje zarządcze, które mogą być sprowadzone do postaci prostych umów SLA. Postać ta jest mniej szczegółowa od prezentacji w WSLA i WSML. Języki te dodatkowo opisują harmonogramy ewaluacji, o wiele dokładniej niż okresowe ograniczenia w WSOL, a także zawierają opis czynności zarządczych podejmowanych przypadku nie spełniania przyjętych poziomów SLO, podczas gdy WSOL opisuje tylko kary pieniężne i zakłada, że strony umowy będą same wysyłały sobie komunikaty z powiadomieniami w przypadku problemów z wypełnieniem umowy. W tym kontekście WSLA i WSML są mocniejszymi językami. Jednakże w kontekście kosztów związanych z zastosowaniem języki te pozostają w tyle za WSOL. Język WSLA definiuje użycie miar jakości usług w zakresie SLA, podczas gdy WSOL powierza definicje miar zewnętrznym ontologiom. WSML może powierzać definicję funkcji oceniających zewnętrznym 3

4 bibliotekom, ale wadą jest to, że wymaga wsparcia dodatkowego języka matematycznego dla wyrażeń matematycznych. Wybór języka jest dowolny, co może sprawiać potencjalne problemy z kompatybilnością. To wszystko powoduje większy narzut uruchomieniowy dla języków WSLA i WSML niż narzut prostszego języka WSOL. Kolejną propozycją języka opisującego poziomy jakości usług dla Web Service ów jest język SLAng.[6] Język ten pozwala określić SLA na poziomie Web Service u, a także na kilku niższych poziomach, dlatego też ma szerszy zakres niż języki WSLA, WSML czy WSOL. SLAng definiuje siedem typów umów SLA. Opisują one możliwe uzgodnienia pomiędzy różnymi typami stron w umowie: aplikacją, Web Service em, komponentem, kontenerem, magazynem pamięci i siecią. Można podzielić ja na dwa typy SLA pionowe i poziome. W skład pionowych SLA wchodzą: Aplikacji pomiędzy aplikacjami lub usługami Web Service a komponentami Hostingu pomiędzy kontenerem a dostawcą komponentu Trwałości pomiędzy dostawcą komponentu a dostawcą serwera aplikacyjnego Komunikacji pomiędzy kontenerem a dostawcami sieci. Wśród poziomych SLA znajdują się: Usług pomiędzy dostawcami komponentów i usług Web Service Kontenera pomiędzy dostawcami kontenerów Sieciowe pomiędzy dostawcami sieci. Składnia języka SLAng określona jest przy użyciu XML Schema. Język ten ma predefiniowany format i definicje metryk jakości usług są wbudowane w schemat SLAng. Dodanie nowych metryk wymaga rozszerzenia schematu SLAng. Odmienne podejście przedstawione jest w koncepcji WS-QoS (Web Service Quality of Service) rozwijanej przez organizację standaryzacyjną OASIS. WS-QoS, w przeciwieństwie do poprzednich rozwiązań, nie przedstawia nowego języka opisu usług, a tylko proponuje rozszerzenie już istniejącego i przyjętego języka WSDL.[7] Autorzy WS-QoS proponują schemat XML, umożliwiający specyfikację kilku wbudowanych parametrów jakości usług, informacji o protokołach i cenach. W skład WS-QoS wchodzą trzy dokumenty XML: WS-QoS RequirementDefinition, WS-QoS OfferDefinition i WS-QoS Ontology. WS-QoS RequirementDefinition określa wymagania jakościowe klienta. Jest to opis minimalnych wymagań, które muszą być spełniane w każdych warunkach. WS-QoS OfferDefinition zawiera jeden lub kilka opisów ofert jakości usług, które dostawca usługi może dostarczyć po cenie odpowiedniej do określonego poziomu jakości. Oba powyższe dokumenty zawierają jeden lub wiele elementów QoSInfo, przetrzymujących informacje o poziomie jakości usługi związanym z wydajnością serwera, jakością warstw transportowych oraz protokołami wymaganymi dla zapewnienia bezpieczeństwa. Dodatkowe parametry jakości usług mogą być określane przy pomocy trzeciego dokumentu, WS- QoS Ontology, przez dostarczanie nazwy, opisu słownego, jednostki miary, i stwierdzenia czy lepsze są mniejsze czy większe wartości. Parametr jakości usługi jest określany przez dostawców jak i odbiorców usług, w taki sposób, aby łączenie gwarancji dostawców i wymagań klientów mogło być przeprowadzane przez Web Servcie Broker (WSB). Wyszukiwanie usług jest kierowane przez WSB, który pobiera z rejestru UDDI wszystkie usługi odpowiadające zapytaniu, a następnie porównuje je z wymaganiami klienta. Jednakże, wybór klas usług pasujących do wymagań klientów przeprowadzany jest tylko na podstawie ceny wybierana jest najtańsza usługa.(rys.2) WS-QoS nie zawiera specyfikacji wyrażeń i formalnie nie definiuje metryk jakości usług. WS- QoS nie ma także wbudowanego wsparcia dla okresowych ograniczeń jakości usług, ograniczeń funkcjonalnych, praw dostępu, kar pieniężnych i dynamicznych relacji pomiędzy klasami usługi. 4

5 Rys. 2. Interakcje pomiędzy czterema współpracującymi stronami Źródło: opracownie własne na podstawie: Tian M., Gramm A., Naumowicz T., Ritter H., Shiller J., A Concept for QoS, op. cit. 4. Podejścia wykrywania i wybierania usług na podstawie jakości Inna grupa koncepcji skupia się na wykrywaniu i wybieraniu usług Web Service. Do grupy tej należy podejście Ontology Web Language OWL-S (wcześniej DAML-S) dostarczające dostawcom usług zestaw konstrukcji w języku XML do opisywania właściwości i możliwości usługi w jednoznaczny, interpretowalny komputerowo sposób.[8] OWL-S ma ułatwić automatyzację czynności związanych z Web Service ami automatyczne wykrycie, uruchomienie i złożenie usługi oraz jej monitorowanie. OWL-S składa się z trzech modułów:[9] Profilu opisu możliwości usługi Web Service, jak i innych cech ważnych w procesie wykrywania usług Modelu Procesu opisu działania usługi, w tym określenia wejść i wyjść za pomocą klas OWL lub typów danych dostarczanych przez XML Schema, warunków wstępnych, których spełnienie wymagane, aby uruchomić usługę oraz efektów, czyli tego, co jest rezultatem usługi. Podstawy opisu jak usługa może być wykorzystana, w tym opisu protokołu komunikacyjnego, konkretnych szczegółów dotyczących usługi np. numerów portów, i jednoznacznych sposobów wymiany danych. Aby umożliwić wykrywanie i wybieranie usług z wykorzystaniem OWL-S, niezbędne jest zmapowanie informacji zawartych w Profilu OWL-S do rejestru UDDI. Istnieje także możliwość użycia architektury połączonego rejestru OWL-S/UDDI, w którym komponent OWL-S korzysta z portów UDDI do swoich operacji. W kilku projektach badawczych wykrywania i wybierania usługi pojawiała się opinia potrzeby rozszerzenia rejestru UDDI. Obecne implementacje UDDI mają bardzo ograniczony zakres, pozwalają na wyszukiwanie usług na podstawie ograniczonej liczby atrybutów. Usługę można wyszukiwać po nazwie usługi (service name), kluczu (keyreference) unikalnym dla każdej usługi oraz na podstawie listy kategorii biznesowych (categorybag), w których serwis został umieszczony. Ponadto, rejestr UDDI może zawierać listy organizacji, które już nie istnieją lub odniesienia do stron, które już nie są aktywne. Jednym z poważnych problemów obecnie jest sprawa interakcji rejestrów UDDI. Nadal nie ma 5

6 porozumienia na temat tego, kto powinien posiadać główny rejestr UDDI, tzw. root. Jedno z bardziej rozwiniętych podejść adresujących niektóre z powyższych ograniczeń dotyczy UDDIe.[10] UDDIe poszerza UDDI o wsparcie dla specyfikacji szeregu właściwości definiowanych przez użytkownika oraz możliwość przeszukiwania rejestru na podstawie tych właściwości. Każda właściwość zawiera nazwę, typ oraz jej wartość. UDDIe nie wspiera określenia jednostki pomiaru. Dla łatwiejszego użycia właściwości są określane w rozszerzonym pliku WSDL i publikowane w rejestrze UDDIe. Dzięki możliwości wysyłania prostych zapytań do UDDIe, rejestr ten może być wykorzystywany w procesie wykrywania i wybierania Web Servcie ów. UDDIe znajduje usługi spełniające kryteria zapytania, a oddzielny broker jakości usług wybiera jedną biorąc pod uwagę poziomy ważności, które klient przypisał do poszczególnych atrybutów jakości. UDDIe pozwala na proste określenie jakości i cen dla usług Web Service, ale ma bardzo ograniczone możliwości. Opisy jakości usług nie są wystarczająco szczegółowe dla działań zarządczych, nie zawierają na przykład informacji gdzie i jak oceniać ograniczenia jakości usług. UDDIe jest w porównaniu z innymi podejściami ograniczonym i mało elastycznym rozwiązaniem. Przy prezentacji grupy koncepcji wykrywania i wybierania usług warto wspomnieć też o jeszcze jednym języku XML do opisywania jakości usług QRL (Quality Requirements Language). QRL jest bardzo mocnym i ogólnym językiem, który może być używany nie tylko do wykrywania i wybierania Web Service ów, ale także innych systemów rozproszonych (np. wideo na żądanie). Niestety ogólność języka wpływa na jego złożoność, oraz wnosi wątpliwości, co do kompatybilności z językiem WSDL.[11] 5. Inne rozwiązania Innym powiązanym rozwiązaniem jest WS- Policy, będący ogólną strukturą specyfikacji polityk działania usług Web Servcies. Polityka może być jakąkolwiek właściwością Web Servcie u lub jego części.[12] Jest to bardzo elastyczne i rozszerzalne rozwiązanie polityki mogą być definiowane wewnątrz jak i na zewnątrz plików WSDL. Nie mniej jednak trzeba pamiętać, że WS- Policy jest tylko ogólną strukturą, podczas gdy szczegółowe specyfikacje określonych kategorii zasad będą definiowane w wyspecjalizowanych językach. Jednym z takich wyspecjalizowanych języków rozwijanych obecnie jest WS- SecurityPolicy, dotyczący wymagań zabezpieczenia komunikacji z usługą. Nie wiadomo obecnie czy jakiś specjalizowany język do specyfikacji polityki jakości, cen, kar czy innych informacji zarządczych będzie rozwijany. Firma IBM we wczesnych latach rozwoju koncepcji SOA pracowała nad językiem WSEL (Web Servcie Endpoint Language), będącym uzupełnieniem języka WSDL. Jednym z celów języka WSEL była specyfikacja zachowania i pewnych ograniczeń, włączając jakość usług, dla Web Service ów. Prace nad WSEL zostały zaprzestane a IBM promuje teraz WS-Policy i WSLA jako specyfikacje informacji, która miała być pokryta przez WSEL. 6. Podsumowanie Przedstawione powyżej rozwiązania w większości wymuszają użycie dodatkowej infrastruktury, aby móc z nich korzystać. Sytuacja ta może być uzasadniona w przypadku architektury zorientowanej na usługi wewnątrz przedsiębiorstw, umożliwiając firmom dokładne określenie swoich SLA i aktywne nimi zarządzanie. Prowadzi to jednak do zwiększenia nakładów czasowych i finansowych, zmniejszając tym samym elastyczność i niezależność koncepcji SOA. W przypadku globalnego zasobu usług Web Service, dodatkowa infrastruktura oddziela usługi wchodzące w jej skład od usług pozostających w standardowych rozwiązaniach. Aby móc przeprowadzać działania w wielu różnorodnych systemach, niezbędne jest używanie ogólnie przyjętych standardów. Standardy te mogą być stworzone przez integrację cech rozwiązań WSOL, WSLA, WSML i WS-Policy w jedną jednolitą i rozszerzalną strukturę i platformę. W takiej sytuacji najlepszym wyjściem wydaje się zaproponowanie dodatkowego rozwiązania, wykorzystującego już istniejące i ogólnie przyjęte standardy, z tą różnicą, że system ten będzie usługą samą w sobie. Usługa ta będzie oceniać jakość usług poddanych ewaluacji, gromadzić zebrane dane oraz umożliwiać klientom wgląd w metryki jakości poszczególnych usług i wybranie najlepszej. Wymaganą infrastrukturą dla tego rozwiązania jest tylko środowisko uruchomieniowe usługi i baza danych, co pozwala na wykorzystanie już istniejących w Internecie serwisów, a co za tym idzie umożliwia powszechne wykorzystanie usługi. 6

7 Bibliografia [1] Ludwig H., Keller A., Dan A., King R.P., A Service Level Agreement Language for Dynamic Electronic Services, IEEE International Workshop on Advanced Issues of E Commerce and Web Based Information Systems, 2002 [2] Tian M., Gramm A., Naumowicz T., Ritter H., Shiller J., A Concept for QoS Integration in Web Services, IEEE Web Information Systems Engineering Workshops, 2003 [3] Sahai A., Durante A., Machiraju V., Towards Automated SLA Management for Web Services, Hewlett-Packard, 2002, /2001/HPL R1.pdf [4] Tosic V., Pagurek B., Esfandiari B., Patel K., On the Management of Compositions of Web Services, Carleton University, Ottawa, Kanada, 2001 [5] Tosic V., Ma W., Pagurek B., Esfandiari B., Web Service Offerings Infrastructure (WSOI) a management infrastructure for XML Web services, IEEE Network Operations and Management Symposium, 2004 [6] Lamanna D.D., Skene J., Emmerich W., SLAng: a language for defining service level agreements, IEEE Distributed Computing Systems, 2003 [7] Srinivasan N., Paolucci M., Sycara K., Semantic Web Discovery in the OWL-S IDE, IEEE Conference on System Science, 2006 [8] DAML Servcies, /services/owl-s/ [9] ShaikhAli A., Rana O.F., Al-Ali R., Walker D.W., UDDIe: an extended registry for Web services, IEEE Applications and the Internet Workshops, 2003 [10] Martin-Diaz O., Ruiz-Cortes A., Corchuelo R., Toro M., A Framework for Classifying and Comparing Web Services Procurement Platforms, IEEE International Web Services Quality Workshop, 2003 [11] Hondo M., Kaler C. (red. nauk.), Web Services Policy Framework (WS-Policy), wersja 1.2, 2006, org/ws-policy pdf 7