SOA Design Patterns: Service Facade
Postanowiłem robić notatki z
książki. Może kogoś zachęcą lub zniechęcą do czytania.
Celem wzorca
Service Facade jest zmniejszenie powiązania między kontraktem usługi, a jej logiką. Oczywiście logiczne powiązanie logiki do kontraktu jest zjawiskiem jak najbardziej pozytywnym (powiązanie odwrotne jest negatywne, skutkuje zwykle wyciekiem technicznych szczegółów logiki do kontraktu i często jest wynikiem automagicznego generowania WSDL-a z kodu). Czasami jednak zmniejszenie stopnia powiązania logiki do kontraktu bywa pożądane. Sytuacje, kiedy tak jest obejmują między innymi:
- współdzielenie logiki między wiele równoległych kontraktów (inny wzorzec - Concurrent Contracts)
- wersjonowanie kontraktu. W klasycznym podejściu utrzymujemy równolegle nową i starą wersję kontraktu i logiki. W podejściu z fasadą mamy jedną (nową) wersję logiki oraz dwie fasady: dla starego i nowego kontraktu.
Wzorzec Service Facade może także być rozumiany jako sposób na uniezależnienie logiki usługi od wymaganej infrastruktury. W takim scenariuszu fasada zlokalizowana jest za (poniżej) logiką i np. przykrywa jakiś odziedziczony system, który w późniejszym czasie może być, bez zmiany w logice usługi, zastąpiony innym.
Powiadamianie o komentarzach
Jeżeli chciałbyś otrzymywać email gdy ta wypowiedź zostanie zaktualizowana, to zarejestruj się tutaj
Subskrybuj komentarze za pomocą