Abstrakcja usługi

Abstrakcja usług jest zasadą projektową stosowaną w ramach paradygmatu projektowania zorientowanego na usługi , dzięki czemu informacje publikowane w umowie o świadczenie usług są ograniczone do tego, co jest wymagane do efektywnego korzystania z usługi. Umowa o świadczenie usług nie powinna zawierać żadnych zbędnych informacji, które nie są wymagane do jego wezwanie. Ponadto informacje powinny ograniczać się wyłącznie do umowy serwisowej (umowa techniczna i umowa o poziomie usług ), żaden inny dokument ani nośnik powinny być udostępniane konsumentom usług inne niż umowa o świadczenie usług, które zawierają dodatkowe informacje dotyczące usług.

Zamiar

Umowa o świadczenie usług, która zawiera szczegółowe informacje o tym, co zawiera (np. logikę, implementację i technologię wykorzystaną do zbudowania usługi) może zostać wykorzystana w określony sposób, zapewniając konsumentowi usługi większą wiedzę na temat działania usługi. W przypadku orientacji na usługi większa wiedza niekoniecznie oznacza lepszą. Istnieje prawdopodobieństwo, że dodatkowe informacje mogą utrudnić ponowne wykorzystanie usługi, ponieważ projektant usług konsumenckich może usprawnić swój projekt w oparciu o tę wiedzę. Wpłynęłoby to jednak na ewolucję umowy o świadczenie usług, ponieważ obecnie usługobiorca jest pośrednio powiązany z realizacją usługi, która może wymagać wymiany w przyszłości. Zwiększa to powiązanie między konsumentem a umową, które jest dodatnim typem sprzężenia. Jednak mając za dużo zależność może negatywnie wpłynąć na ewolucję zarówno usługodawcy, jak i usługobiorcy.

Ukrywanie informacji pozostaje jedną z kluczowych zasad paradygmatu zorientowanego obiektowo, który promuje abstrakcję od wewnętrznego działania programu . Klasycznym przykładem byłoby użycie klas abstrakcyjnych do ukrycia rzeczywistej logiki metody. Ta sama koncepcja jest stosowana przez zasadę abstrakcji usług w celu ukrycia zbędnych szczegółów dotyczących działania usługi w celu ułatwienia ewolucji usługi.

Aplikacja

Zastosowanie tej zasady projektowania wymaga przyjrzenia się czterem różnym typom abstrakcji, które można zastosować do usługi.

Abstrakcja funkcjonalna

Ta forma abstrakcji zależy od tego, jaka część logiki usługi jest udostępniana jako możliwości usługi. Przykładem może być klasa, w której niektóre metody są prywatne, a inne publiczne. Klasa ujawniłaby tylko te metody jako publiczne, które uzna za ważne dla swoich obiektów, wszelkie metody pomocnicze, które nie są istotne dla obiektów, są ukryte.

Kontrakt serwisowy, który nie podlega tej zasadzie, można nazwać „kontraktem szczegółowym”, który ujawnia wiele reguł biznesowych i logiki walidacji. Po zastosowaniu tej zasady w odpowiednim stopniu, umowę można nazwać „umową zwięzłą”. Dalsze stosowanie tej zasady projektowej skutkowałoby „zoptymalizowanym kontraktem”, który maksymalizuje potencjał usługi w zakresie ponownego wykorzystania.

Abstrakcja informacji o technologii

Wszelkie informacje o podstawowej technologii wykorzystywanej w ramach usługi skutkowałyby abstrakcją informacji o niskim poziomie technologii, ponieważ umowa o świadczenie usług wyraźnie mówi konsumentom usługi, w jaki sposób zaprojektowano logikę usługi i jej implementację. Te dodatkowe informacje mogą spowodować, że konsumenci usług zostaną zaprojektowani w sposób, który jest specjalnie ukierunkowany na tę konkretną implementację, rozwijając w ten sposób sprzężenie między konsumentem a implementacją.

Abstrakcja logiczna

Programowe szczegóły dotyczące logiki usługi muszą zostać wyabstrahowane, ponieważ wiedza o tym, jak usługa faktycznie wykonuje swoją funkcjonalność, może spowodować, że konsumenci usług uwzględnią te informacje i w konsekwencji zostaną zaprojektowani zgodnie z tymi założeniami. Może to poważnie utrudnić wysiłki związane z refaktoryzacją logiki usług i może być uważane za anty-wzorzec w kierunku zastosowania wzorca refaktoryzacji usług .

Abstrakcja jakości

Abstrakcja jakości odnosi się do szczegółów zawartych w towarzyszącej usłudze umowie o gwarantowanym poziomie usług. Ważne jest, aby skoncentrować się tylko na tego rodzaju informacjach, które rzeczywiście pomogłyby w określeniu niezawodności i dostępności usługi, nie należy uwzględniać żadnych innych informacji, które ujawniają niepotrzebne szczegóły, np. inne usługi, z których korzysta w celu realizacji swoich funkcji.

Poziom kontroli dostępu zastosowany do usługi decydowałby o tym, ile abstrakcji technologii, logiki i jakości usług jest na miejscu. „Otwarty dostęp” zapewniłby swobodny dostęp wszystkim, którzy są zainteresowani poznaniem specyfikacji projektu usługi. W przypadku „dostępu kontrolowanego” tylko upoważnione osoby mają dostęp, a polityka „zakaz dostępu” całkowicie uniemożliwiłaby dostęp do dokumentów projektowych.

Rozważania

Chociaż ukrywanie informacji jest uważane za zdrową praktykę, ukrywanie zbyt dużej ilości informacji może przynieść efekt przeciwny do zamierzonego, ponieważ może ograniczyć poziom możliwości ponownego wykorzystania usługi. Może to również skutkować redundantnymi usługami, ponieważ projektanci usług nie mają wystarczających informacji o możliwościach usługi. W tym celu każda umowa serwisowa musi być zaprojektowana w zwięzły, ale kompleksowy sposób, aby możliwości usługi mogły być skutecznie wykrywane i interpretowane zgodnie z zasadą wykrywalności usługi .

Rodzaj informacji ujawnianych w umowie o świadczenie usług może również powodować pewne obawy związane z bezpieczeństwem. na przykład usługa, która propaguje szczegółowe informacje o bazie danych w wyniku błędu wewnętrznego, może paść ofiarą ataku, w którym atakujący wykorzystuje zgłoszone szczegóły błędu i próbuje połączyć się z bazą danych. Można temu zaradzić, stosując wzorce projektowe kontroli komunikatów i ochrony przed wyjątkami .

Dalsza lektura

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Service_abstraction&oldid=929399549 ”