Sprawozdanie merytoryczne z wykonanych prac rozwojowych w ramach Projektu rozwojowego MNiSzW nr R02 036 02 pt. Protokoły i prototyp platformy umożliwiające działanie elektronicznego rynku usług, z uwzględnieniem osób zagrożonych wykluczeniem z rynku pracy zrealizowanego w Instytucie Podstaw Informatyki PAN, 01-237 Warszawa, ul. Ordona 21. Kierownik projektu: doc. dr hab. Stanisław Ambroszkiewicz Spis treści: 1. Obszerne streszczenie 1.1. Zakres tematyczny 1.2. Syntetyczne omówienie wyników 2. Realizacja projektu a założenia zawarte we Wniosku 2.1. Problemy w trakcie realizacji i ich rozwiązanie 2.2. Szczegółowy opis realizacji na podstawie Wniosku 3. Podsumowanie rezultatów 4. Opis załączonej dokumentacji technicznej zrealizowanej technologii 5. Uwagi końcowe 6. DODATEK A: Raport Prof. E. Pleszczyńskiej 7. DODATEK B: Raport zbiorczy z testowania z 4 załącznikami Opis dokumentacji dołączonej do sprawozdania merytorycznego w formie papierowej: 1. Techniczne opracowania: ELA-enT: Specyfikacja języka i protokołów oraz Opis Dokumentacji Technicznej platformy ELA-enT. 2. Dokumentacje 3 przykładowych usług generowanych ze Słownika EntishDictionary. 3. Raport zbiorczy z podłączania i testowania usług na platformie ELA-enT. 4. Manuskrypt książki (wersja robocza 0.81) pt. Elektroniczne rynki usług: technologie i ich realizacje. (ponad 250 stron, w najbliższym czasie do w recenzji wydawniczej: Akademicka Oficyna Wydawnicza EXIT, Warszawa). Autorzy: S. Ambroszkiewicz, M. Barański, W. Bartyna, M. Faderewski, D. Mikułowski, E. Pleszczyńska, i G. Terlikowski. W formie elektronicznej (na płytce DVD) wszystko, co jest powyżej (łączne z Raportem końcowym i tym Raportem merytorycznym) oraz dokumentacja techniczna i instalacyjną platformy ELA-enT.
1. Obszerne streszczenie 1.1 Zakres tematyczny Elektroniczne rynki są obecnie jednym z najpoważniejszych wyzwań dla technologii informatycznych determinujących ich dalszy rozwój. Rzecz idzie o automatyzację szeroko pojętych procesów biznesowych, w tym nie tylko o obsługę zamówień, ale przede wszystkim o automatyczną realizację złożonych i często długoterminowych transakcji pomiędzy partnerami biznesowymi. Elektroniczne rynki usług (w skrócie ERU) ograniczają się do zazwyczaj prostych usług świadczonych przez drobnych wykonawców, ale za to na masową skalę. W ramach PO IG 8.1 Wspieranie działalności gospodarczej w dziedzinie gospodarki elektronicznej, finansowane jest bardzo wiele projektów dotyczących mniej lub bardziej bezpośrednio elektronicznych rynków usług, np. projekt Elektroniczny Rynek Usług - wdrożenie innowacyjnej platformy kojarzenia partnerów handlowych. Zarówno na świecie jak i w kraju istnieją i są rozwijane platformy do realizacji elektronicznych rynków usług. Jedną z wyróżniających się platform jest oferia.pl działająca w ramach Allegro. Zasadniczym problemem takich platform jest dowolność w tworzeniu ofert i zleceń przez użytkowników, co z jednej strony jest zaletą, ale z drugiej strony powoduje to, że (np. w oferia.pl) pojawiają się oferty nie mające związku (lub niewielki) z kategoriami (predefiniowanymi przez administratora), w której są one umieszczane. Podobnie jest ze zleceniami. W rezultacie, platformy te w najlepszym razie (po uporządkowaniu przez administratora) bardziej przypominają tradycyjne rozwiązania, takie jak Panorama Firm (pf.pl ), czy Polskie Książki Telefoniczne (pkt.pl), niż elektroniczne rynki. To znaczy, służą one do ogłaszania zleceń i ofert, zaś same transakcje zawierane są poza platformą nieautomatycznie, w sposób tradycyjny. W sumie sprowadza się to do żmudnego ręcznego wyszukiwania partnera i równie żmudnego i czasochłonnego ustalania warunków i zawierania umowy. Tymczasem istotą elektronicznych rynków usług, jest nie tyle kojarzenie zleceniodawcy z potencjalnymi wykonawcami, co przedstawienie przez system ofert wykonania zlecenia w sposób automatyczny i bez angażowania bezpośrednio zleceniodawcy i potencjalnych wykonawców. Po wyborze jednej z ofert przez zleceniodawcę, system powinien generować umowę na jej realizację, spełniającą wszystkie wymagania prawne łącznie z podpisami cyfrowymi. 1.2. Syntetyczne omówienie wyników Technologia informacyjna do rozwoju ERU zaproponowana w naszym projekcie rozwojowym (w postaci specyfikacji odpowiednich protokołów i ich realizacji jako prototypowej platformy nazwanej ELA-enT) wychodzi naprzeciw powyższym wymaganiom. Zgodnie z paradygmatem SOA, komponentami zaproponowanej technologii są: Menadżery Zadań (zintegrowane z Serwerami Zadań występującymi we Wniosku) reprezentujące klientów, czyli zleceniodawców, Serwery Usług (reprezentujące usługodawców), InfoService (jako rozproszone repozytoria do publikacji i wyszukiwania usług) oraz EntishDictionary jako rozproszony słownik implementujący język opisu usług i opisu formułowania zleceń (zadań). Protokoły komunikacyjne pomiędzy komponentami są następujące: protokół do publikacji usług pomiędzy Serwerem Usług a InfoService; protokół do wyszukiwania usług pomiędzy Menadżerem Zadań a InfoService; protokół do aranżacji (negocjacji) warunków wykonania usługi, realizującej zlecenie, pomiędzy Menadżerem Zadań a Serwerem Usług; protokół do zawierania umów (e-faktur) pomiędzy Menadżerem Zadań a Serwerem Usług. EntishDictionary pozwala na wprowadzanie nowych pojęć do języka opisu usług oraz do formułowania typu usługi jak również formułowania zadania zleconego do wykonania przez
klienta. Kontrola tego słownika pozwala na kontrolę całego systemu od strony semantycznej. Jest to kluczowa funkcjonalność elektronicznego rynku usług pozwalająca na konstrukcję formalnej ontologii usług, pozwalająca na jednoznaczne i automatyczne przetwarzanie przez system zadań i opisów usług, (czyli tego, co usługi wykonują). Kontrola nad poprawnością działania sytemu spoczywa na trzech zasadniczych komponentach: Menadżer Zadań, InfoService, oraz Serwer Usług. Zwykły użytkownik (zarówno zleceniodawca jak i usługodawca) może korzystać z systemu, ale nie może zakłócić jego działania. Menadżer Zadań jest przyjaznym interfejsem (w przeglądarce WWW) dla zleceniodawcy, który formułuje zlecenie na podstawie kategorii i typów usług dostępnych aktualnie w systemie. Menadżer Zadań dynamicznie aktualizuje te typy na podstawie bieżących wpisów w EntishDictionary. Usługodawca, zanim podłączy swoją usługę do systemu, musi stworzyć dla niej interfejs (w postaci aplikacji programistycznej odpowiadającej Serwerowi Usług i implementującej część z powyższych protokołów) i zarejestrować ją w InfoService. Zazwyczaj wykonawca prostej usługi nie jest w stanie stworzyć takiej aplikacji, która wymaga uprzedniego stworzenia opisu semantycznego (ontologii) tej usługi w EntishDictionary. W tym celu na Serwerach Usług działają tzw. Menadżery Wykonawcy usługi; osobny Menadżer dla każdego typu usługi. W prototypowej platformie zostało zrealizowanych 75 takich Menadżerów. Usługodawca po rejestracji i akceptacji na Serwerze Usług, dostaje (poprzez przeglądarkę WWW) dostęp do Menadżera Wykonawcy odpowiedniego typu usługi, który odpowiednio konfiguruje, żeby stworzyć swoje własne oferty. Klient (zleceniodawca) zleca swojemu Menadżerowi Zadań zadanie do realizacji, który z kolei, poprzez InfoService, dowiaduje się, na jakich Serwerach Usług są zarejestrowane usługi mogące wykonać to zadanie. Menadżer Zadań kontaktuje się z tymi Serwerami Usług, żeby automatycznie zebrać oferty i zaprezentować je klientowi. Po wyborze oferty, generowana jest umowa i kierowana jest do Menadżera Wykonawcy tego usługodawcy, który zgłosił tę ofertę. Usługodawca może przyjąć tę umowę do realizacji. Menadżer Zadań reprezentuje swojego klienta, natomiast Serwer Usług reprezentuje wykonawcę usługi. Takie rozwiązanie jest kluczowe do zarządzania zaufaniem w zaproponowanej technologii. Jakkolwiek same zawarte umowy w systemie mają moc prawną na podstawie podpisów cyfrowych zleceniodawcy i wykonawcy, to dochodzenie tych praw przez strony może być scedowane na reprezentanta, tj. firmę w ramach, której działa Menadżer Zadań bądź Serwer Usług a (może to być ta sama firma). Ponieważ podpis cyfrowy nie jest jeszcze powszechny, więc w proponowanej technologii dopuszczona jest możliwość podpisywanie umów przez reprezentantów, tj., Menadżera Zadań i Serwera Usług, po uprzednim przekazaniu takich uprawnień odpowiednio przez zleceniodawcę i wykonawcę usługi. Problem podpisu cyfrowego znika, jeśli Menadżer Zadań i Serwer Usług są prowadzone przez tę samą firmę. Wszystkie wymienione wyżej komponenty systemu mogą być implementowane niezależnie. Współdziałanie różnorodnych komponentów jest zapewnione poprzez zgodność ich implementacji ze specyfikacją wyżej wymienionych protokołów. Wersja demonstracyjna (w pełni funkcjonalna) platformy ELA-enT jest dostępna na WWW pod http://ent.ipipan.waw.pl i będzie utrzymywana, co najmniej przez najbliższych 5 lat. Specyfikacja proponowanej technologii wraz z dokumentacją techniczną platformy (zawierającą kody źródłowe) jest publiczne dostępna dla zainteresowanych stron po uprzednim zgłoszeniu. Obecnie w IPI PAN są prowadzone dalej prace nad wersją wdrożeniową, która też może być udostępniona zainteresowanym stronom, np. w ramach współpracy.
2. Realizacja projektu a założenia zawarte we Wniosku 2.1. Problemy w trakcie realizacji i ich rozwiązanie Faktyczna realizacja projektu w zasadzie nie odbiegała od założeń zawartych we wniosku, z tym, że harmonogram wykonania początkowych zadań został nieco przesunięty w czasie. Dotyczyło to przede wszystkim wprowadzania usług do systemu, które okazało się organizacyjnie trudne, bardziej pracochłonne i kosztowne niż to było przewidziane we wniosku. Te dwa ostatnie problemy dało się prosto rozwiązać przez przesunięcie środków z promocji projektu na prace związane z wprowadzaniem opisu typów usług do Słownika (czyli EntishDictionary), oraz implementacje Menadżerów Wykonawcy dla tych typów. Ponieważ założone zostało we Wniosku, że takich typów będzie, około 75, więc wysiłek projektowy i implementacyjny związany z realizacją tych Menadżerów był znacznie większy niż początkowo było zaplanowane. Problem organizacyjny dotyczył, z jednej strony, tworzenia opisów usług przez osoby zagrożone wykluczeniem (w większości były to osoby niepełnosprawne), na tyle szczegółowych, żeby można było na ich podstawie wprowadzać te opisy (w sposób formalny) do Słownika; w tym celu został stworzony specjalny formularz z dostępem poprzez przeglądarkę www. Z drugiej strony ten problem dotyczył testowania zrealizowanych Menadżerów Wykonawcy polegającego zarówno na wprowadzaniu ofert jak i na generowaniu zleceń do Menadżera zadań i ich realizacji w postaci umów; tutaj również został opracowany specjalny formularz do raportowania. Problem ten potęgował się, ponieważ typów usług miało być wiele, a znalezienie osób niepełnosprawnych potrafiących wykonywać i opisywać proste i różne usługi było trudne. Rozwiązanie tego problemu uzyskano poprzez nabór i często żmudne szkolenie osób niepełnosprawnych. W związku z powyższym dopiero po pomyślnym rozwiązaniu problemów organizacyjnych, implementacja Menadżerów Wykonawców i ich testowania nabrała tempa i została pomyślnie zrealizowana. Innych istotnych problemów podczas realizacji projektu nie było i projekt jako całość został zrealizowany zgodnie z Wnioskiem. Szczegółowy opis tej realizacji jest przedstawiony niżej. 2.2. Szczegółowy opis realizacji na podstawie Wniosku Szczegółowy opis realizacji poszczególnych zadań z Harmonogramu realizacji projektu był dołączany sukcesywnie w Raportach rocznych, tak, że całość opisu znajduje się w na końcu Raportu końcowego. Natomiast opis realizacji na podstawie Opisu projektu we Wniosku przedstawia się następująco. Cel projektu (efekt końcowy) projektu został przedstawiony we Wniosku w następujący sposób. 1) planowany efekt końcowy realizacji badań stosowanych i prac rozwojowych objętych projektem Efektem końcowym projektu ma być realizacja i weryfikacja prototypu nowej technologii informacyjno-komunikacyjnej (zaimplementowanej w formie platformy na podstawie zaproponowanych protokołów komunikacyjnych) umożliwiającej swobodny dostęp wykonawców usług jak i zleceniodawców do wyłaniającego się elektronicznego rynku usług.
Technologia ta poprzez automatyzację wyszukiwania i zawierania umów (w formie elektronicznej tzw. e-faktur) stworzy nowe możliwości zatrudniania osób na rynku pracy. 2 charakterystyka formy wyniku końcowego (dokumentacja techniczna, prototyp wyrobu, dokumentacja konstrukcyjna, inna forma podać jaka ) Efektem końcowym ma być umożliwienie inicjacji i dalszego spontanicznego rozwoju elektronicznego rynku usług realizowanego na proponowanych przez nas protokołach komunikacyjnych. Natomiast wynikiem końcowym projektu będzie prototyp platformy implementującej te protokoły, sprawdzony pod względem technologicznym oraz zweryfikowany w zakresie jej wykorzystania i praktycznej użyteczności zwłaszcza dla OZW. Do platformy zostanie dołączona pełna dokumentacja dotycząca konstrukcji, działania i obsługi tej platformy. Opublikowana zostanie też pełna dokumentacja konstrukcyjna, czyli dokładna specyfikacja protokołów komunikacyjnych, na których będzie opierać się działanie platformy. Te specyfikacje powinny służyć do niezależnych implementacji poszczególnych komponentów platformy. Komponenty te (implementowane niezależnie, ale zgodnie ze specyfikacjami) będą współdziałać z naszą prototypową platformą. Oprócz dokumentacji platformy zostanie także przygotowane opracowanie, w formie książki, zawierające opis działania platformy, jej doraźny jak i dalekosiężny cel wraz z ekspertyzą działania stymulowanego w projekcie, tzn., inicjacji ERU. W opracowaniu zawarta będzie również ocena dalszych możliwości wdrażania prototypu w środowiskach szczególnie zagrożonych wykluczeniem z rynku pracy. Projekt był realizowany na podstawie założeń opisanych we Wniosku w 2. Opis badań stosowanych i prac rozwojowych objętych projektem. Natomiast sama koncepcja usługi biznesowej została wykrystalizowana w trakcie trwania projektu i warta jest przedstawienia, ponieważ stanowi nowy i istotny wynik naukowo badawczy w dziedzinie elektronicznych procesów biznesowych. 2.2.1. Koncepcja usługi biznesowej Zaproponowana we Wniosku technologia informacyjna do realizacji ERU została oparta na obowiązującym obecnie paradygmacie SOA (Service Oriented Architecture) stosowanym w systemach rozproszonych. Klasyczna wersja paradygmatu SOA 1, może być podsumowana następująco: SOA provides a standard programming model that allows self-contained, modular software components residing on any network to be published, discovered, and invoked by each other as services. There are essentially three components of SOA: Service Provider, Service Requester (or Client), and Service Registry. The provider hosts the service and controls access to it, and is responsible for publishing a description of its service to a service registry. The requester (client) is a software component in search of a component to invoke in order to realize a request. The service registry is a central repository that facilitates service discovery by the requesters. 1 IBM Services Architecture Team, Web Services architecture overview: The next stage of evolution for e-business, http://www.ibm.com/developerworks/webservices/library/w-ovr/ (2000)
Do tej pory nie ma w literaturze jasnej i precyzyjnej definicji, czym jest usługa, a zwłaszcza usługa biznesowa. Zazwyczaj podawane są typowe cechy aplikacji, którą można nazwać usługą, a wśród nich można wymienić następujące: loose coupling, service contract, abstraction, reusability, composability, autonomy, discoverability, etc. Wydaje się, że główną tego przyczyną jest, z jednej strony, nieuwzględnianie faktu, że usługa (zwłaszcza biznesowa) to nie tylko aplikacja przetwarzająca dane. Zazwyczaj za przetwarzaniem danych kryją się skutki w tzw. świecie realnym. Z drugiej strony, jest ścisłe wymaganie w stosunku do klienta, korzystającego z usługi, że musi on z góry znać wszystkie parametry potrzebne do wywołania tej usługi. Uszczegółowienie pojęcia usługi biznesowej Typowy tradycyjny (nie automatyczny) proces korzystania z usługi biznesowej składa się z następujących czterech faz: 1. Zapytanie i oferta (request, quote). 2. Wysłanie zamówienia i otrzymanie umowy (order, contract). 3. Wykonanie zasadniczej usługi (performance). 4. Rachunek, faktura i płatność (invoice, payment). Problem jest jak zautomatyzować powyższe fazy i czy jest to możliwe? Każda z powyższych faz polega na przepływie odpowiednich dokumentów dla tej fazy. Dokumenty te mogą być w formacie XML-owym. Tak, więc taka usługa biznesowa, powinna się składać z następujących wzajemnie powiązanych ze sobą operacji: 1. Pierwsza operacja odpowiada, w formie oferty, na zapytanie klienta. 2. Druga operacja przetwarza dokumenty związane z kontraktem (zawarciem umowy) na wykonanie zasadniczej funkcji usługi. 3. Trzecia operacja odpowiada za realizację kontraktu (umowy) zawartej w wykonaniu drugiej operacji, i jest związana z zasadniczą funkcjonalnością usługi. Realizacja ta jest zazwyczaj w postaci protokołu odbioru, lub innego dokumentu stwierdzającego wykonanie usługi. 4. Czwarta operacja obsługuje wysłanie rachunku (faktury) i płatność. Przykład prostego procesu biznesowego polegającego na skorzystaniu z serwisu AGD zilustruje nam problem. Jest to złożona usługa polegająca na przeprowadzeniu ekspertyzy (pierwsza usługa prosta) zepsutego sprzętu dostarczonego do serwisu, a następnie jego ewentualnej naprawy (druga usługa prosta), zgodnie z ekspertyzą. Ekspertyza musi być zwrócona do klienta (właściciela sprzętu), który na tej podstawie zdecyduje, czy naprawiać sprzęt, czy też zabrać go z powrotem do domu, albo też zlecić wykonanie ekspertyzy innemu serwisowi. Przyjmijmy, że zepsuty sprzęt AGD musi być dostarczony do serwisu, a więc musi być dodatkowa usługa transportowa (trzecia usługa prosta) dostarczająca sprzęt do serwisu i odwożąca sprzęt z powrotem do właściciela. Tak, więc klient (właściciel zepsutego sprzętu) żeby otrzymać ekspertyzę (skorzystać z pierwszej prostej usługi) powinien: 1. Najpierw zapytać usługę (serwis AGD) czy może ona przeprowadzić ekspertyzę i dostać od niej ofertę. 2. Zawrzeć umowę z serwisem AGD na wykonanie ekspertyzy. 3. Otrzymać ekspertyzę. 4. Zapłacić rachunek za jej wykonanie. Następnie w zależności od wyniku ekspertyzy, zawrzeć umowę na naprawę (osobna usługa) albo też zlecić usłudze transportowej przewiezienie sprzętu z powrotem do domu. Żeby zautomatyzować ten, wydawałoby się prosty, proces korzystania z usługi, należy założyć, że każda faza usługi jest realizowana przez osobną operacje wykonywana w ramach tej usługi. W ten sposób usługa składa się z czterech wzajemnie ze sobą powiązanych
operacji. W procesie korzystania z tej usługi realizowane są cztery wzajemnie powiązane przebiegi dokumentów odpowiadające czterem fazom, jako realizacje kolejnych operacji. Schematy XSD dla tych dokumentów muszą również być zdefiniowane. Dotyczy to zarówno fazy pierwszej, a więc schemat XSD dla zapytania oraz schemat XSD dla oferty, jak i schematy XSD dla następnych faz. Powyższe powiązania pomiędzy fazami (operacjami) są kluczowe do automatyzacji procesów biznesowych. Muszą one być formalnie wyspecyfikowane tak, żeby można je było automatycznie przetwarzać. W tym celu proponowane jest wprowadzenie następujących pojęć: 1. Środowisko wykonania usługi biznesowej reprezentowane przez schematy XSD dla dokumentów XML-owych przetwarzanych w fazach drugiej, trzeciej i czwartej. 2. Formalny język opisu środowiska wykonania usługi czyli język opisujący powyższe dokumenty XML-owe. 3. Aranżacja wykonania usługi biznesowej - na którą składają się zapytanie i oferta wyrażone uniwersalnie w powyższym języku opisu a nie w formie dokumentów XML-wych generowanych na podstawie schematów XSD dedykowanych dla każdej usługi osobno. Należy podkreślić, że proponowany język opisu, nie opisuje samych usług ale opisuje środowisko wykonania tych usług. Na ten opis składa się warunek wstępny (precondition) opisujący lokalną (dla tej usługi) sytuację w środowisku, żeby usługa mogła zostać uruchomiona, oraz warunek końcowy (effect) opisujący jaki jest skutek wykonania tej usługi w środowisku. Tak więc wnętrze usługi traktowane jest jako czarna skrzynka (black box).. Opisywane jest (jako precondition) jedynie zewnętrze usługi, a więc środowisko wykonania usługi (czyli odpowiednie dokumenty XML-owe), które powodują uruchomienie usługi. Oraz opisywane są (jako effect) dokumenty XML-owe (wytwarzane przez usługę), przez które te środowisko jest zmienione. Innymi słowy, opisywane są tylko zmiany w środowisku (reprezentowane przez dokumenty XML-owe przetwarzane przez tę usługę), będące przyczyną i skutkiem wykonania tej usługi. Jeszcze raz należy podkreślić, że te środowisko wykonana reprezentowane jest poprzez schematy XSD dokumentów XML-owych przetwarzanych przez usługi. Ta reprezentacja daje ugruntowanie (konkretną a nie abstrakcyjna semantykę) dla języka opisu usług wykorzystanego do automatyzacji fazy 1 (zapytanie-oferta). Powiązania pomiędzy fazami są specyfikowane w pierwszej fazie w formalnym języku opisu środowiska wykonania usług i mogą być w następnych fazach przetwarzane automatycznie. Przy takim podejściu, w fazie aranżacji usługi przez klienta (faza pierwsza) ustalane będą (w tym języku opisu) wszystkie parametry niezbędne do zawarcia umów (dokumenty w fazie drugiej), takie jak np. czas wykonania ekspertyzy, jej zakres, oraz wiele innych, których klient nie może z góry znać. Konieczne jest, zatem odpytanie usługi przez klienta, żeby uzyskać wszystkie parametry niezbędnie do wysłania zamówienia i zawarcia umowy na wykonanie usługi (w przykładzie jest to uzyskanie ekspertyzy). Przy powyższych założeniach fazę pierwszą można zautomatyzować, i powierzyć jej realizację odpowiedniej aplikacji nazwanej agentem. Zapytania i odpowiedzi w tym języku, dokonywane w pierwszej fazie, mają dotyczyć zarówno fazy drugiej, jak i trzeciej i czwartej, a więc przepływu dokumentów w tych fazach. W powyższym przykładzie, język ten powinien pozwalać na opis dokumentów (zamówienia i umowy na wykonanie ekspertyzy), opis samej ekspertyzy jako wyniku wykonania usługi, oraz dokumentów związanych z płatnością. Kluczem do automatyzacji fazy pierwszej jest pojęcie środowiska wykonania usługi, jego formalnej reprezentacji, oraz języka opisu tej reprezentacji, który ma służyć do komunikacji pomiędzy klientem a usługa. Takim językiem opisu jest Entish (patrz [2], [3], [4] i [5]).
2.2.2. Krótki opis Słownika (EntishDictionary), protokołów i platformy ELA-enT Przedstawiony niżej opis jest na potrzeby tego raportu. Pełne opisy zostały przedstawione w dołączonych osobnych technicznych opracowaniach: ELA-enT: Specyfikacja języka i protokołów oraz Opis Dokumentacji Technicznej platformy ELA-enT. Niżej przedstawione zostały komponenty technologii zrealizowanej w ramach projektu, w tym: 1. Słownik i ontologia usług 2. Protokoły komunikacyjne 3. Jądro platformy ELA-enT 4. Menadżer Wykonawców usług 5. Menadżer Zadań 2.2.2.1. Słownik i związana z nim ontologia opisująca usługi Język Entish stanowi podstawę opracowanej technologii do rozwoju ERU. W założeniu jest on otwarty i rozproszony, tzn., każdy użytkownik może dodawać do niego własne definicje nowych pojęć. Definicje te są potrzebne po to, aby nowo publikowane usługi mogły być podłączone do systemu. Usługi podłączane do systemu operują na dokumentach, których format powinien być odpowiednio zdefiniowany. Aby umożliwić wprowadzanie do języka nowych pojęć, a co za tym idzie dodawanie do systemu nowych formatów dla dokumentów, została utworzona specjalna struktura, nazywana słownikiem (EntishDictionary). W słowniku można definiować następujące rodzaje pojęć: Atrybuty - są to proste funkcje, które opisują pojedyncze własności jakiegoś dokumentu, takie jak np. nazwisko kupującego, czy cena za usługę. Typy pośrednie. Dotyczą one pewnego niewielkiego pojęcia np. dane sprzedawcy są definiowane jako typ pośredni. Typy dokumentów. Kilka typów pośrednich stanowi typ dokumentu. Określa on strukturę dla konkretnego dokumentu np. dokument umowy o dzieło może się składać z pięciu typów pośrednich takich jak: informacje o dokumencie, dane kupującego, dane sprzedającego, informacje o przedmiocie umowy oraz informacje o usługodawcy. Funkcje. Definiują one na pewnym poziomie abstrakcji typ operacji usługi. Dla każdej funkcji w słowniku związane są typy dokumentów wchodzących oraz typ dokumentu wychodzącego. Na przykład funkcja implementująca operację udzielania korepetycji o nazwie Make_lessons posiada, jako dokument wejściowy, umowę o dzieło nauczyciela korepetytora, a jako dokument wyjściowy rachunek za korepetycje. Kategorie. Klasyfikują one zdefiniowane funkcje (a więc rodzaje usług) w formie drzewa różnych dziedzin. Kategoria jest zdefiniowane poprzez swoją nazwę oraz powiązanie z kategoriami podrzędnymi oraz kategorią nadrzędną, np., kategoria usługi muzyczne może posiadać jako swoją kategorię nadrzędną kategorię Usługi kulturalno-artystyczne, a jako kategorię podrzędną kategorię zespół muzyczny. EnTish Dictionary został zaimplementowany zgodnie z architekturą składającą się z odpowiedniej bazy danych oraz specjalnego edytora umożliwiającego przeglądanie i modyfikowanie gromadzonych w nim pojęć.
Obiekty przechowywane w słowniku są przetwarzane i przesyłane w formie dokumentów XML o odpowiedniej strukturze. Każdy dokument jest instancją odpowiadającego mu schematu XSD. Dokumenty te są uporządkowane w postaci hierarchii, która przypisuje je do odpowiednich kategorii w zależności od rodzaju usługi, w jakiej mają być one używane. Edytor słownika został utworzony po to, aby nie było konieczne manualne modyfikowanie wielu dokumentów XML, których struktury są czasem bardzo złożone. Operuje on na atrybutach, typach, funkcjach oraz typach dokumentów zapisanych w słowniku a działa jako witryna WWW. Umożliwia ona przeglądanie i modyfikowanie struktur słownika. Uporządkowanie pojęć w słowniku jest realizowane poprzez tworzenie kategorii oraz ich pod-kategorii. Oprócz gromadzenia pojęć potrzebnych do opisania usług, słownik posiada funkcje umożliwiające automatyczne tworzenie interfejsów dla nowo definiowanych usług. Słownik wspomaga również tworzenie nowych typów zadań w Menadżerze Zadań dla nowo definiowanych usług. W sumie, można powiedzieć, że słownik jest ogólnym interfejsem, który pozwala dostawcy usługi (programiście implementującemu Menadżer wykonawcy usługi)na podłączenie jej do platformy ELA-enT. Użytkownik (programista) nie musi znać ani XML, ani języka Entish, ponieważ graficzny interfejs słownika umożliwia prawidłowe zdefiniowanie nowych pojęć. 2.2.2.2. Protokoły komunikacyjne Działanie platformy ELA-enT jet oparte na trzech prostych protokołów: protokole do rejestracji usług, protokole do wyszukiwania odpowiednich zarejestrowanych usług, oraz protokole do aranżowania wyszukanych usług w celu uzyskania od nich ofert. Protokoły te specyfikują, jakie wiadomości mają być wymieniane pomiędzy komponentami systemu uczestniczącymi w realizacji zadania użytkownika oraz to, w jaki sposób ta wymiana wpływa na zmiany stanów jej uczestników. Uczestnikami wymiany wiadomości są usługi, agenci i rejestr usług. Stany agenta, usługi oraz rejestru usług wyrażone są w strukturach XMLowych, podobnie jak każda wiadomość w tych protokołach. Dokładna specyfikacja tych protokołów znajduje się w [2], ale jest także szerzej opisana w dodatkowych opracowaniach dołączonych do tego raportu. Pierwszy z protokołów służy do rejestracji usługi w systemie. Usługa publikuje opis swojego interfejsu w rejestrze usług zwanym też InfoSerice. Protokół ten jest realizowany przez konwersację, którą rozpoczyna usługa wysyłając do rejestru wiadomość typu register-request, tzn., pole order w nagłówku wiadomości określające jej typ, ma wartość register-request. Wiadomość ta zawiera formułę, która opisuje typ operacji wykonywanej przez usługę. W odpowiedzi usługa informacyjna wysyła potwierdzenie rejestracji, wraz z ograniczeniem czasowym, które dotyczy jej ważności. Drugi protokół służy do wyszukiwania przez agenta usług zarejestrowanych w systemie. Odbywa się to poprzez wysłanie przez agenta do rejestru usług wiadomości typu "info-request". Wewnątrz wiadomości umieszczona jest formuła opisująca aktualną intencję agenta. Taka wiadomość jest traktowana przez rejestr usług jako zapytanie. W odpowiedzi agent otrzymuje wiadomość, której zawartość stanowią (opatrzone znacznikami czasowymi) formuły opisujące typ operacji wykonywanej przez usługi spełniające kryteria podane w zapytaniu. W~wiadomości umieszczone są też adresy tych usług. Typ operacji każdej z tych usług odpowiada dokładnie intencji agenta.
Trzeci protokół służy do aranżacji usług w celu wykonania zadania użytkownika. Usługi odszukane przez agenta są przez niego aranżowane. Po otrzymaniu adresów usług wraz z typami operacji, jakie one wykonują, agent kieruje do każdej z nich takie samo zapytanie, jakie skierował do rejestru usług. W odpowiedzi otrzymuje zobowiązanie danej usługi, w którym usługa podejmuje się zrealizować intencję agenta, jednak pod warunkiem dostarczenia jej pewnych dokumentów. Zobowiązanie może także zawierać ograniczenia dotyczące tych dokumentów potrzebnych usłudze do zrealizowania intencji agenta. Na podstawie tych zobowiązań tworzone są oferty, które są przedstawiane użytkownikowi. Potrzebne dokumenty są tworzone przez interfejs użytkownika, czyli Menadżer zadań. Zaaranżowane w ten sposób usługi oczekują na dokumenty, które mają być im przysłane przez interfejs użytkownika. Ponieważ użytkownik dokonał wyboru tylko jednej usługi, więc dokumenty zostaną wysłane tylko do jednej z nich. Pozostałe muszą być "zwolnione" ze swoich zobowiązań. Takie odwołanie zobowiązań jest realizowane przez wysłanie wiadomości typu "service-request" z formułą false do wszystkich usług, których oferty nie zostały wybrane przez użytkownika. Jak można zauważyć, realizacja pierwszych dwóch protokołów dokonuje się w dosyć prosty sposób. Każdy z nich jest wykonywany poprzez jednorazową wymianę wiadomości pomiędzy odpowiednimi dwoma komponentami systemu. Realizacja protokołu rejestracji odbywa się poprzez wymianę wiadomości, która zachodzi pomiędzy usługą a rejestrem usług. Realizacja protokołu odkrywania odbywa się poprzez jednorazową wymianę wiadomości pomiędzy agentem, a rejestrem usług. Realizacja protokołu aranżacji jest również prosta. Odbywa się ona poprzez wiele wymian wiadomości pomiędzy agentem a odnalezionymi usługami. Dodatkowo, pomiędzy agentem a każdą usługą, której oferta nie została wybrana przez użytkownika następuje jednostronna komunikacja polegająca na wysłaniu przez agenta wiadomości odwołującej jej zobowiązanie. 2.2.2.3. Jądro platformy ELA-enT Jądro platformy ELA-enT składa się z następujących komponentów: Serwer agentów, rejestr usług, czyli InfoService, oraz Serwer usług. Komponenty te są omówione niżej. Serwer Agentów Serwer agentów jest jednym z najważniejszych wewnętrznych komponentów systemu ELA-enT. Został on zaimplementowany przy użyciu technologii Java Api For XML Processing oraz Java Servlets. Jest to aplikacja odpowiedzialna za tworzenie, uruchamianie i zarządzanie działaniem procesów agentów. Procesy te są odpowiedzialne za aranżowanie i wykonywanie zadań (zleceń) użytkowników. W chwili, kiedy interfejs użytkownika (Menadżer zadań) utworzy zadanie, jest ono przekazywane do serwera agentów, który powołuje dla niego niezależny proces agenta. Agent ten poprzez wysyłanie i odbieranie komunikatów w języku Entish, zgodnie z protokołem entish 1.01, realizuje wyszukiwanie i~ aranżację usług do wykonania tego zadania. Agent ten musi odbierać i wysyłać wiadomości oraz analizować ich zawartości, którą są formułami języka Entish wyrażonymi w XML. Ponieważ jest to komponent wewnętrzny, nie posiada on interfejsu użytkownika. Aby mógł on jednak współpracować z interfejsem użytkownika (Menadżerem zadań) zostały w nim
zaprogramowane klasy, które są wykorzystywane przez strony JSP tworzące Menadżera zadań, oraz Menadżery usług na serwerach usług. Dzięki takiemu rozwiązaniu programiści implementujący Menadżer zadań oraz serwery usług otrzymali gotowe klasy interfejsu do komunikacji w języku Entish. Rejestr usług - InfoService Rejestr usług jest jednym z wewnętrznych komponentów systemu ELA-enT. Został on zaimplementowany przy użyciu technologii Java Api For XML Processing oraz Java Servlets. Rejestr usług jest aplikacją odpowiedzialną za publikowanie informacji o usługach, które zostały podłączone do platformy. Dlatego realizuje on protokół pozwalający na zarejestrowanie usługi oraz protokół umożliwiający jej wyszukanie przez agenta. W największym skrócie można powiedzieć, że działanie Infoservice polega na odbieraniu następujących trzech rodzajów zapytań i odpowiadaniu na te zapytania zgodnie z protokołem entish 1.1 (patrz [2] i ELA-enT: Specyfikacja języka i protokołów dołączone do sprawozdania). Pierwszy rodzaj zapytania jest prośbą usługi o zarejestrowanie jej typu operacji. Jest ona sformułowana w postaci odpowiedniej wiadomości zawierającej formułę języka Entish. Rejestr usług zapamiętuje informacje dotyczące rejestrującej się usługi i odpowiada usłudze wiadomością, w której znajduje się czas ważności jej rejestracji. Drugi rodzaj zapytania, kierowane do InfoService jest to zapytanie agenta, który chce się dowiedzieć o typ operacji oraz adres usługi. Informacje te są potrzebne agentowi do zrealizowania części jego zadania. Zapytanie to jest również wysyłane do InfoService w formie wiadomości, której struktura i zawartość jest zgodna z protokołem entish. Wiadomość ta zawiera odpowiednią formułę języka Entish. W odpowiedzi na takie zapytanie InfoService zwraca agentowi w jednej wiadomości informacje dotyczące wszystkich usług, które odpowiadają wyszczególnionym kryteriom. Trzeci rodzaj zapytania do InfoService to zapytanie zawierające prośbę o wyrejestrowanie usługi. Jest to zapytanie kontrolne, które może być wysłane przez administratora zarządzającego InfoService w celu oczyszczenia jej bazy danych ze zbędnych lub błędnie zarejestrowanych usług. Serwery usług Jednym z ważniejszych elementów systemu Ela-enT są serwery usług. Są one niezależnymi, zewnętrznymi komponentami, które mogą być zaimplementowane przy użyciu dowolnych technologii. Jedynym wymaganiem jest to, aby poprawnie komunikowały się one z rejestrem usług oraz Menadżerem zadań. Taka komunikacja została zapewniona dzięki użyciu języka Entish oraz protokołów do rejestracji i aranżacji usług. Do zrealizowania tej komunikacji, od strony implementacyjnej, serwery usług wykorzystują klasy umożliwiające operowanie na formułach języka Entish oraz przetwarzania dokumentów umów i rachunków. W prototypowej implementacji platformy ELA-enT zostało zaprogramowanych 45 serwerów usług, na których jest zarejestrowanych 75 usług. Pierwszy serwer usług został zaimplementowany przy użyciu technologii JSP wraz z jej bibliotekami (np. JSTL), Spring oraz Hibernate. Dostęp do bazy danych, wykorzystywanej przez serwer usług, został zrealizowany przy pomocy interfejsu DAO (Data Access Object). Warstwa widoku serwera usług została zaprogramowana jako zbiór stron JSP. Warstwa kontroli (logiki działania) została zaimplementowana w postaci specjalnych klas tzw. kontrolerów.
2.2.2.4. Menadżer Wykonawców Menadżer Wykonawcy usługi jest interfejsem (dla wykonawcy usługi danego typu) na jednym z serwerów usług i jest widoczny jako dynamiczna witryna WWW. Aby skorzystać z jej funkcjonalności, użytkownik musi się zalogować przy pomocy formularza, który jest wyświetlany na głównej stronie serwera usług. Menadżer ten posiada główne menu, z którego użytkownik może wybrać takie polecenia jak: "Strona główna", "Wyloguj", "Zarejestruj", "Oferta", "Kontrakty" oraz "Terminarz". Trzy ostatnie z wymienionych poleceń służą do umieszczania oferty usługi na serwerze. Oprócz tego, na witrynie serwera jest także dostępne menu, z którego usługodawca może wybrać rodzaj usługi, dla jakiej chce założyć swoją ofertę. Może on wybrać usługi "Korepetytorskie", "Muzyczne" lub "Programistyczne". W celu dodania nowej oferty, niezależnie od tego, jaką usługę wybrał użytkownik na początku korzystania z serwera, musi on wprowadzić dane podstawowe. Są one zależne od rodzaju usługi wybranej przez użytkownika. Dodawanie swojej oferty usługodawca powinien kontynuować wprowadzając bardziej szczegółowe dane dotyczące swojej usługi. W wypadku usługi zespołu muzycznego powinien on podać informacje dotyczące ceny za koncert, nazwy usługi, wymagań logistycznych oraz ewentualnych dodatków takich jak np. efekty świetlne czy pokaz taneczny. Kolejnym krokiem publikowania oferty jest podanie dodatkowych danych potrzebnych do utworzenia umowy i rachunku takich jak: sposób i termin płatności czy rodzaj zawieranej umowy. Do zrealizowania wymienionych wyżej czynności służy odpowiedni interfejs. Każdą dodaną ofertę dostawca usługi powinien umiejscowić w konkretnym czasie. Do zrealizowania tej funkcjonalności służy osobny niezależny komponent zaimplementowany w serwerze usług, jakim jest terminarz. W tym terminarzu użytkownik powinien określić dni oraz godziny, w których może wykonywać swoją usługę. Ważnym elementem Menadżera Wykonawcy jest także interfejs służący do zarządzania kontraktami otrzymanymi przez usługodawcę od klientów. Pozwala on na oglądanie, drukowanie oraz akceptowanie bądź odrzucanie tych kontraktów. Po wyszukaniu usługi i wypełnieniu przez klienta wszystkich niezbędnych danych, interfejs Menadżer zadań przesyła wytworzony kontrakt do odpowiedniego serwera usług. Kontrakt ten jest dostępny w interfejsie usługodawcy służącym do zatwierdzania kontraktów, który został zaimplementowany na serwerze usług. Każdy z kontraktów, który został przysłany w imieniu klienta przez Menadżera zadań musi być wyświetlony a następnie zaakceptowany lub odrzucony przez usługodawcę. Jeśli usługodawca zaakceptuje kontrakt, ma możliwość wysłania rachunku za wykonaną przez siebie usługę z powrotem do klienta. Wszystkie te operacje usługodawca może wykonywać w interfejsie do zatwierdzania kontraktów zaprogramowanym na serwerze usług. 2.2.2.5. Menadżer Zadań Menadżer zadań jest jednym z zewnętrznych komponentów systemu ELA-enT. Jest on interfejsem, który oprócz zwykłej funkcjonalności, jaką powinien posiadać portal systemu, jest odpowiedzialny za tworzenie zadań użytkowników oraz za przedstawianie użytkownikowi wyników ich wykonania.
Został on zaimplementowany w języku Java przy użyciu technologii JSP oraz Java Servlets. Wykorzystano także język HTML, Java Script oraz arkusze stylów (CSS). Za jego pomocą użytkownik może zarejestrować się w systemie, wyszukać oferty usługodawców, oraz wykonać zadanie polegające na podpisaniu umowy z wyszukanym usługodawca. Od swojej zewnętrznej strony menadżer zadań został zaimplementowany, jako witryna WWW. Jednym z ważniejszych elementów menadżera zadań jest interfejs do rejestracji użytkowników. Został on zaimplementowany jako formularz, w którym użytkownik jest proszony o wpisanie wszystkich swoich danych takich jak imię, nazwisko, adres zamieszkania, numer i seria dokumentu tożsamości, numer NIP, itd.. W tym formularzu, zostały zaimplementowane mechanizmy sprawdzające poprawność wpisywanych danych oraz funkcje pomagające w prawidłowym i sprawnym ich wypełnianiu. Na przykład, kiedy użytkownik wprowadzi numer swojego konta bankowego w przeznaczonym do tego polu edycyjnym, w liście wyboru znajdującej się obok tego pola zostanie wyświetlona nazwa banku użytkownika. Jest ona wyznaczana na podstawie wprowadzonego numeru konta. Podobna sytuacja ma miejsce wtedy, gdy użytkownik wprowadzi swój numer NIP. Dane wprowadzone przez użytkownika w formularzu rejestracyjnym są później wykorzystywane do formułowania umów elektronicznych, które będzie on podpisywał z usługodawcami. Jeśli użytkownik zarejestruje usługę na jednym z serwerów usług, dane podane przez niego podczas rejestracji zostaną wykorzystane do formułowania umów oraz rachunków wystawianych klientom. Drugim głównym elementem menadżera zadań jest interfejs, który pomaga użytkownikowi odszukać usługę i utworzyć nowe zadanie. Został on zaprojektowany jako formularz, w którym użytkownik może wpisać lub wybrać parametry wyszukiwanej usługi, a następnie wysłać zapytanie do systemu. W pierwszym kroku użytkownik może wybrać na głównej stronie systemu kategorię usługi, jaką zamierza wyszukać. Następnie w tej kategorii wybiera dostępną usługę. Po dokonaniu tych czynności na stronie jest wyświetlany formularz, w którym użytkownik będzie mógł wybrać lub wpisać różne parametry swojego zapytania. Sposób wyświetlenia tych parametrów, ich ilość, rodzaj kontrolek, przez jakie są one reprezentowane, są zależne od rodzaju usługi, jaką wybrał użytkownik. Formularze do wyszukiwania usług są generowane osobno dla każdej usługi na podstawie słownika typów usług, a ich zaprojektowanie jest zadaniem dostawcy usług. Po wybraniu lub wpisaniu wartości parametrów i naciśnięciu przycisku Szukaj, użytkownik otrzymuje ofertę wyszukanej usługi. Jeśli usługa spełniająca podane kryteria nie została znaleziona w interfejsie użytkownika, zostaje wyświetlony odpowiedni komunikat. Wśród dostępnych typów usług wyróżnia się dwa ich rodzaje są to usługi pojedyncze gdzie zawierana jest jedna umowa pomiędzy zamawiającym a wykonawcą. Drugim rodzajem są usługi złożone, (w których zawieranych jest kilka umów). Usługi złożone składają się z kilku pojedynczych usług. Przykładowo możemy mieć typ usługi Przyjęcie, na którą składają się typy usług: Wynajem sal na imprezy, Obsługa kulinarna imprez oraz Zespół muzyczny. Użytkownik za pomocą dostępnego interfejsu w łatwy sposób może skomponować usługi niezbędne do zrealizowania bardziej zaawansowanej usługi (np. przyjęcie ). Menadżer zadań udostępnia interfejs, który pozwala wprowadzić parametry i wyszukać jednocześnie usługi kilku typów wzajemnie ze sobą skorelowane tzn. przykładowo, jeśli będziemy chcieli skorzystać z usługi Przyjęcie, czyli tak naprawdę z trzech usług ( Wynajem sal, Obsługa kulinarna, Zespół muzyczny ) to pożądane jest aby obsługa kulinarna odbywała się w godzinach wynajęcia sali, podobnie aby zespół muzyczny świadczył usługę w godzinach trwania przyjęcia. Widzimy, że w tym przypadku muszą być skorelowane godziny świadczenia usług. Opisany powyżej rodzaj złożenia usług nazywany jest Kompozycją równoległą typów usług. W systemie ELA-enT dostępny jest także mechanizm nazwany
Kompozycją szeregową. Daje on użytkownikowi możliwość szybkiego wyszukania usługi i zawarcia umowy z jej wykonawcą, na podstawie wyniku wykonania innej usługi. Jako przykład mogą posłużyć takie typy usług jak Ekspertyza (np. sprzętu rtv) oraz Naprawa (np. sprzętu rtv). Użytkownik chcący skorzystać z usługi Naprawa musi wpierw skorzystać z usługi Ekspertyza, gdyż usługa Naprawa musi automatycznie poinformować użytkownika o całkowitym koszcie wykonania naprawy, co nie jest możliwe bez ekspertyzy. Dzięki dostępnemu w menadżerze zadań interfejsowi użytkownik, który skorzystał z usługi ekspertyza (i otrzymał ekspertyzę na swój sprzęt) może bezpośrednio zlecić wykonanie naprawy na podstawie posiadanej ekspertyzy. Kolejnym elementem menadżera zadań jest interfejs służący do sformułowania umowy pomiędzy usługodawcą i klientem. Jego zadaniem jest przedstawienie użytkownikowi ofert wyszukanych usług oraz pomoc w doprecyzowaniu szczegółów umowy, jaka będzie zawarta pomiędzy usługodawcą a klientem. Interfejs ten został również zaprogramowany jako kilka formularzy, w których część danych użytkownika jest już wypełniona natomiast pewne elementy muszą być przez niego uzupełnione. Wygląd tych formularzy jest również zależny od typu usługi, jaką wyszukał klient. Formularze te zawierają opcje do wyboru różnych parametrów usługi, pola wyboru do zaznaczenia dodatkowych opcji oraz pola tekstowe przeznaczone do wpisania brakujących danych. Na końcu procesu uzupełniania danych tworzony jest dokument umowy, który może być następnie podpisany cyfrowo i wysłany do odnalezionego usługodawcy. Jeśli użytkownik nie posiada urządzenia do składania kwalifikowanego podpisu elektronicznego, umowa może być wysłana bez podpisu. Umowa jest przesyłana w postaci dokumentu XML o odpowiedniej strukturze. W przypadku, gdy usługa jest usługą złożoną (jak np. Przyjęcie) i składa się z kilku usług prostych wówczas kreator zawierania umowy jest powtarzany dla każdej z usług. Kolejnym elementem menadżera zadań jest interfejs prezentujący użytkownikowi rachunek za wykonaną usługę. Po wysłaniu do usługi umowy sformułowanej w interfejsie użytkownika usługa przetwarza ją i produkuje dokument XML będący rachunkiem. Ten rachunek jest przysyłany do menadżera zadań, który następnie prezentuje go użytkownikowi. 2.2.2.6. Testowanie Wszystkie zrealizowane, na platformie ELA-enT, typy usług (jako Menadżery Wykonawców) w liczbie 75, zostały przetestowane w fazie implementacji. Dodatkowo 40 spośród nich zostało przetestowanych przez odpowiednio przeszkolonych testerów. Osiem z tych typów usług zostało przetestowanych in vivo, tzn., usługi te zostały rzeczywiście wykonane w ramach platformy ELA-enT, tj., zostały dla nich wygenerowane oferty, zamówienia, umowy i rachunki. Raporty z tego testowania są przedstawione na końcu tego raportu jako załączniki A i B. 3. Podsumowanie rezultatów Protokoły komunikacyjne, na których opiera się działanie opracowanej technologii informacyjnej do rozwoju elektronicznych rynków usług, zostały wszechstronnie zweryfikowane i przetestowane, do czego przyczyniły się też osobne implementacje tych protokołow przez zespół dr Józefa Wojcieszenko z Uniwersytetu Białoruskiego w Mińsku. Wnioski na podstawie doświadczeń przy realizacji, weryfikacji i testowania prototypowej wersji platformy ELA-enT:
Słownik służy zasadniczo do opisu dokumentów przetwarzanych przez usługi. Ponieważ dokumenty te są w formacie XML-owym, więc warto używać standardów zaproponowanych w Web Services, a mianowicie WSDL, SOAP i być może UDDI. Słownik można realizować niezależnie od języka opisu usług, którym był Entish. Stąd też wniosek, że można użyć innych języków do opisu usług. OWL (Web Ontology Language ( http://www.w3.org/tr/owl2-profiles/ ) może być użyty do opisu usług, co więcej może on też być użyty do realizacji fazy aranżacji i może tym samym z powodzeniem zastąpić Entish. Pokazanie, że możliwa jest realizacja fazy aranżacji w OWL należy uważać za nowy, ważny i kluczowy wynik naukowy osiągnięty w ramach zrealizowanego projektu. Manuskrypt książki Manuskrypt książki pt. Elektroniczne rynki usług: technologie i ich realizacje. (ponad 200 stron, zostanie zgłoszony w ciągu najbliższych tygodni do recenzji wydawniczej Akademicka Oficyna Wydawnicza EXIT, Warszawa) Autorzy: S. Ambroszkiewicz, M. Barański, W. Bartyna, M. Faderewski, D. Mikułowski, E. Pleszczyńska, i G. Terlikowski. Publikacja w EXIT będzie dobrze przygotowana, tak żeby znalazła szerokie grono czytelników. W związku z tym dotyczy ona szeroko pojętych elektronicznych rynków, a dopiero w szczególności ERU i naszych propozycji technologii do rozwoju ERU. Obecnie jest realizowana wersja wdrożeniowa technologii do realizacji ERU przez zespół projektowy pod kierownictwem S. Ambroszkiewicza. Ta wdrożeniowa wersja jest już w zupełności oparta na standardach WSDL, SOAP i OWL. W najbliższym czasie przeprowadzone zostania rozmowy z firmami, które realizują podobne technologie, tj., oferia.pl na Allegro, Panorama Firm (pf.pl ), Polskie Książki Telefoniczne (pkt.pl), w celu zainteresowania ich realizacja wersji wdrożeniowej platformy ELA-enT. Firma ACSYS BSC Sp. zo.o. oraz mgr inż. Sylwester Grzebień, Dyrektor Handlowy Fujitsu Technology Solutions sp. z o.o., są zainteresowani realizacja wersja wdrożeniową ELA-enT. 4. Opis załączonej dokumentacji technicznej zrealizowanej technologii W skład dokumentacji, która będzie udostępniana zainteresowanym stronom, wchodzą: Techniczne opracowania: ELA-enT: Specyfikacja języka i protokołów oraz Opis Dokumentacji Technicznej platformy ELA-enT. W tych opracowaniach została też opisana sama platforma ELA-enT. Dokumentacja techniczna dotyczy: EntishDictionary i ontologii w nim zawartej, komponentow jądra systemu z Menadżerem Zadań, 75 Menadżerów Wykonawców implementujących różne typy usług, instrukcja instalacji platformy ELA-enT, opisy klas w postaci javadoc i kody źródłowe. Ta dokumentacja techniczna pozwala na zrozumienie działania technologii opracowanej w ramach projektu, oraz na zainstalowanie i używanie osobnych własnych wersji platformy ELA-enT, jak również na jej rozbudowę, zwłaszcza o dodatkowe typy usług i związane z nimi Menadżery Wykonawców, ale również jej modyfikację według uznania potencjalnych użytkowników. Konsultacji w sprawach instalacji i uruchamiania osobnych wersji platformy ELA-enT udziela mgr Marek Faderewski mailto: marekf@ipipan.waw.pl, faderewski@gmail.com
5. Uwagi końcowe Zasadniczy cel projektu był natury ściśle technologicznej, tj., chodziło o opracowane i zweryfikowanie technologii to rozwoju ERU. Ważnym aspektem tego projektu były osoby zagrożone wykluczeniem z rynku pracy (w większości osoby dotknięte różnorodnym rodzajem i stopniem niesprawności), które w ramach tego projektu występowały jako wykonawcy prostych usług. Obszerne opracowania, o tym jak te osoby uczestniczyły w projekcie, znajdują się w 2 dodatkach w tym raporcie. Pierwsze opracowanie jest autorstwa Prof. Dr hab. Elżbiety Pleszczyńskiej, za której przyczyną osoby niepełnosprawne zostały włączone do projektu. Drugie opracowanie, autorstwa dr D. Mikułowskiego i mgr M. Faderewskiego, dotyczy wprowadzania (w większości przez osoby niepełnosprawne) opisów usług do systemu oraz ich testowania. BIBLIOGRAFIA 1. IBM Services Architecture Team, Web Services architecture overview: The next stage of evolution for e-business, http://www.ibm.com/developerworks/webservices/library/w-ovr/ (2000) 2. S. Ambroszkiewicz: entish an Approach to Service Description and Composition. IPI PAN, Warszawa 2003 3. S. Ambroszkiewicz, D. Mikułowski: Web Serwisy i Semantic Web, idee i technologie. Akademicka Oficyna Wydawnicza EXIT, Warszawa 2006 4. S. Ambroszkiewicz: Entish: A Language for Describing Data Processing in Open Distributed Systems. Fundamenta Informaticae. Volume 60, Number 1-4, April 2004, ISO Press, pp.41-66 5. entish Project WWW-site: http://www.ipipan.waw.pl/mas/ 6. OWL-S: Semantic Markup for Web Services, W3C Member Submission 22 November 2004, http://www.w3.org/submission/owl-s