Gateway [Brama]

Wzorce dotyczące architektury aplikacji biznesowych
Wzorce podstawowe - Gateway [Brama]

Obiekt, który hermetyzuje dostęp do zewnętrznych systemów lub zasobów.

Rzeczywiste oprogramowanie rzadko "żyje" w izolacji. Nawet w przypadku, gdy oprogramowanie zostało przygotowane w postaci czystego zorientowanego obiektowo systemu, często zachodzi konieczność jego współdziałania z elementami, które nie są obiektami np. tabele relacyjnej bazy danych, struktury danych XML itp.

W celu dostępu do zasobów zewnętrznych, zwykle używane jest specjalnie przygotowane w tym celu API dla tych zasobów. Jednakże API tego typu, biorąc pod uwagę charakter tych zasobów, w naturalny sposób jest czymś skomplikowanym. Każdy kto chciałby zrozumieć zasób musi zrozumieć jego API: czy jest to JDBC i SQL dla relacyjnych baz danych, czy API W3C lub JDOM dla XML-a. Powoduje to nie tylko trudności w zrozumieniu oprogramowania, ale również powoduje, że jest ono o wiele trudniejsze do zmiany, gdy w przyszłości wymagane będzie przesłanie danych pochodzących z relacyjnej bazy danych do XML-a.

Rozwiązaniem jest opakowanie całości specjalizowanego kodu API klasą, której interfejs wygląda jak regularny obiekt. Inne obiekty dostają się do zasobu poprzez tak stworzoną bramę [GATEWAY] a obiekt bramy transformuje proste wywołania metod na stosowne wywołania specjalizowanego API.

JAK TO DZIAŁA ?
W rzeczywistości Gateway jest prostym wzorcem typu wrapper. Wykorzystanie wzorca polega na przeglądnięciu API dla określonego zasobu / systemu zewnętrznego, stwierdzeniu co jest wymagane z punktu widzenia projektowanego systemu oraz utworzeniu jak najprostszego API spełniającego rolę bramy dla skomplikowanego niejednokrotnie API systemu zewnętrznego.

Należy pamiętać, aby starać się utrzymać bramę tak prostą jak to tylko możliwe. Należy skupić się na zasadniczych zadaniach adaptacji serwisu zewnętrznego oraz dostarczenia dobrego punktu do stubbingu (przygotowanie stub-ów czyli elementów po stronie klienta zajmujących się tworzeniem i wysyłaniem zleceń). Należy starać się minimalizować zakres odpowiedzialności bramy tak by wykonywała jedynie wymienione zadania. Całość bardziej skomplikowanej logiki powinna być umieszczana w elementach stanowiących warstwę kliencką dla bramy.

Często dobrym pomysłem jest użycie mechanizmu generacji kodu w celu utworzenia klasy bramy na podstawie definicji struktury zasobu zewnętrznego. W tym celu można użyć zarówno meta danych dla tabel bazodanowych jak również schematu DTD w przypadku XML-a. Będąca rezultatem brama jest "głupia" jednak spełnia swoją rolę, inne obiekty przeprowadzają bardziej skomplikowane manipulacje.

Czasem dobrą strategią jest zbudowanie bramy składającej się z więcej niż jednego obiektu. Oczywistą formą jest użycie dwóch obiektów: back-end i front-end. Back-end działa jak minimalna nakładka dla zasobu zewnętrznego i nie upraszcza w ogóle API zasobu zewnętrznego. Front-end następnie transformuje niewygodne API na takie które jest dogodne do użycia przez projektowaną aplikację. To podejście stosuje się w przypadku, gdy zarówno opakowanie zewnętrznego serwisu jak również adaptacja do określonych wymagań są widocznie skomplikowane. W tym podejściu każda odpowiedzialność jest obsługiwana przez pojedynczą klasę.

Przygotowano na podstawie:
Martin Fowler: Patterns Of Enterprise Application Architecture