Zasada komponowania usług
W informatyce komponowalność usług jest zasadą projektową stosowaną w ramach paradygmatu projektowania zorientowanego na usługi , która zachęca do projektowania usług , które można ponownie wykorzystać w wielu rozwiązaniach, które same składają się z usług złożonych. Możliwość rekompozycji usługi jest idealnie niezależna od wielkości i złożoności składu usługi.
Ta zasada jest bezpośrednio odpowiedzialna za zwinność obiecaną przez SOA, ponieważ promuje komponowanie nowych rozwiązań poprzez ponowne wykorzystanie istniejących usług.
Zamiar
Koncepcja tworzenia oprogramowania z niezależnie istniejących komponentów zachęca do koncepcji kompozycji. Jest to podstawowa koncepcja zorientowania obiektowego, w której produkt końcowy składa się z kilku powiązanych ze sobą obiektów, które mogą stać się częścią wielu rozwiązań programowych, bez względu na to, jak złożone jest rozwiązanie. Ta sama koncepcja kompozycji jest dziedziczona przez zorientowanie na usługi, w którym proces biznesowy jest automatyzowany poprzez łączenie wielu usług. Jednak w ramach zorientowania na usługi jeszcze większy nacisk kładzie się na budowanie usług, które można komponować i ponownie komponować w ramach wielu rozwiązań, aby zapewnić elastyczność obiecane przez SOA. W wyniku tego nacisku wymagane są pewne wytyczne, aby opracować usługi, które można skutecznie połączyć w wiele rozwiązań.
Zasada możliwości komponowania usług zapewnia kwestie projektowe, które pomagają w projektowaniu usług nadających się do komponowania w celu zachęcenia do ponownego wykorzystania usług w jak największym stopniu. Wytyczne zawarte w tej zasadzie przygotowują serwis tak, aby był gotowy do udziału w składach serwisowych bez konieczności dalszych zmian projektowych.
Aplikacja
Stosowanie zasady komponowalności usług wymaga zaprojektowania usług w taki sposób, aby mogły być wykorzystywane w kompozycji usług albo jako usługa kontrolująca inne usługi, tj. usługa kontrolera, albo jako usługa zapewniająca funkcjonalność innym usługom w kompozycji bez dalszego komponowania inne usługi, tj. członek składu.
Aby usługa zapewniała tę podwójną funkcjonalność, umowa o świadczenie usług musi być zaprojektowana w taki sposób, aby przedstawiała funkcjonalność w oparciu o różne poziomy danych wejściowych i wyjściowych. W przypadku, gdy wymagany jest udział jako członek składu, to zazwyczaj parametry wejściowe do usługi byłyby bardziej szczegółowe w porównaniu z sytuacją, gdy wymagany jest udział jako kontroler składu. Często używana usługa musi być jak najbardziej bezstanowa ( zasada bezstanowości usług ), aby zapewnić optymalną wydajność, gdy jest złożona w ramach wielu kompozycji usług.
Skuteczność tej zasady zależy od stopnia, w jakim pozostałe zasady projektowe zostały pomyślnie zastosowane. Zastosowanie standardowej umowy serwisowej sprawia, że usługi są interoperacyjne z innymi i pomaga uprościć projekt składu, unikając konieczności przeprowadzania transformacji modelu danych w czasie wykonywania. Stosując zasadę luźnego powiązania usługi, można by zmienić skład usługi z pewnością, że nie stworzy to żadnej formy ujemnego sprzężenia z inną usługą w kompozycji. Zastosowanie autonomii usług i bezstanowości usługi zwiększają niezawodność i dostępność usługi, dzięki czemu można ją ponownie wykorzystać w wielu składach usług z większą pewnością.
Rozważania
Aby usługa była wydajnym kontrolerem usługi, a także członkiem usługi, podstawowa architektura technologiczna musi zapewniać środowisko wykonawcze, które jest skalowalne i może obsługiwać bezstanowość wymaganą przez usługę. Podobnie jak kompozycje usług zwiększają rozmiar, przechowywanie i pobieranie danych kontekstowych, związanych z interakcją usług w czasie wykonywania, może wymagać delegowania do środowiska wykonawczego zamiast do usług zarządzających tymi danymi kontekstowymi, aby kompozycja usług była bardziej wydajny.
Ponieważ tworzonych jest coraz więcej kompozycji usług, istnieje tendencja do uzależnienia od usługi, która jest często ponownie wykorzystywana. Wymaga to starannej analizy podczas projektowania kompozycji usług i rozważenia alternatywnych usług rezerwowych dla krytycznych funkcji. Z drugiej strony rozwój usługi, która obecnie staje się częścią wielu kompozycji usług, może być trudny. Można temu zaradzić, stosując wzorzec projektowy Concurrent Contracts, który opowiada się za utrzymywaniem wielu równoległych kontraktów na usługę. W ten sposób usługa może ewoluować, zapewniając jednocześnie kompatybilność wsteczną.
Niektóre z czynników, które określają potencjał komponowalności usługi, obejmują:
- Możliwość zapewnienia funkcjonalności na różnych poziomach w ramach procesu biznesowego.
- Wzór wymiany komunikatów
- Czy usługa obsługuje transakcje i funkcje wycofywania/kompensacji.
- Wsparcie dla obsługi wyjątków.
- Dostępność metadanych dotyczących możliwości i zachowania usługi.
Zobacz też
- Kjell-Sverre Jerijærvi. Model zapadalności kontraktu SOA [online]. Data dostępu: 21 kwietnia 2010 r.
- Mauro. i in. Integracja urządzeń zorientowana na usługi - analiza wzorców projektowych SOA . [Online], s. 1–10, 2010 43. Hawaii International Conference on System Sciences, 2010. Data dostępu: 8 kwietnia 2010 r.
- Dino Esposito. Wzorzec wiadomości HTML [online]. Data dostępu: 21 kwietnia 2010 r.
- Zasady zorientowania na usługi
- Anny Thomas Manes. Manifest SOA [online]. Data dostępu: 21 kwietnia 2010 r.
- Wojciech Cellary, Sergiusz Strykowski. E-Government Based on Cloud Computing and Service-Oriented Architecture [Online]. Data dostępu: 22 kwietnia 2010 r.
- Sun, L., Dong, H., Hussain, FK, Hussain, OK, Chang, E.: Wybór usług w chmurze: najnowocześniejsze i przyszłe kierunki badań. Journal of Network and Computer Applications [Online] 45 (październik 2014), s. 134-150. Data dostępu: 16 czerwca 2015 r.