Integracja czy inny sposób konstruowania aplikacji?

Adaptery nie zawsze proste

Podstawowym mechanizmem, na którym opiera się serwer BizTalk, są adaptery. Są to obiekty, które z jednej strony komunikują się z macierzystym systemem, z drugiej, udostępniają odpowiednie interfejsy do BizTalk Orchestration. Obecnie dostępnych jest ponad 300 adapterów, tworzonych przez różne firmy. Są m.in. dostępne interfejsy do SAP R/3, uniwersalne mechanizmy, pozwalające komuniko-wać się z kolejkami MQSeries czy z serwerem MS SQL 2000 (w wersji beta).

Warto dodać, że także część polskich producentów systemów wspomagających zarządzanie rozpoczęło prace nad stworzeniem adapterów do BizTalk, które pozwoliłyby wykorzystać w procesach definiowanych w Orchestration dane i mechanizmy udostępniane przez te systemy.

Z jednej strony pisanie adap-tera nie jest skomplikowane - to tak naprawdę jedna funkcja z kilkoma parametrami. Należy jednak założyć, że tego typu komponent będzie bardzo intensywnie używany; musi dobrze się skalować i poprawnie działać w przypadku, gdy wykorzystywany jest jednocześnie przez wiele wątków.

BizTalk 2002 zawiera dwa mechanizmy ułatwiające konfigurację. Dostępne są narzędzia branżowe BizTalk Accelerator, które przyspieszają implementację serwera w określonych typach przedsiębiorstw. Przedsiębiorstwo może również zdefiniować własne pakiety wzorcowe dla kooperantów (pakiety SEED), które zawierają gotową do użycia mat-rycę pozwalającą połączyć ze sobą dwa różne serwery.

Śledzić, ale jak?

W przypadku tradycyjnych aplikacji można było śledzić instrukcję po instrukcji, definiować warunki pułapek czy też podglądać zawartość zmiennej. W rozwiązaniach wykorzystujących mechanizmy Orchestration tego typu podejście byłoby trudne do zrealizowania.

O ile podstawowe komponenty mogą być przetestowane za pomocą tradycyjnych metod, o tyle w przypadku całego procesu można śledzić tylko poszczególne etapy otrzymywania czy wysyłania dokumentu - wtedy zwykle uruchamiany jest pewien proces (np. komponent realizujący daną funkcję). Dołączając debugger do takiego procesu, można prześledzić, co dzieje się z przetwarzanym komunikatem. Można też wykorzystać bazowy proces motoru XLang i podglądać zdarzenia rejestrowane w tym komponencie COM+. Jednak są to półśrodki - trudno nawet wyobrazić sobie, jak powinien wyglądać debugger wspomagający śledzenie rozwiązania, w którym część aplikacji jest po prostu diagramem przepływów.

Procedury obsługi błędów można realizować dokładnie w taki sam sposób, jak planuje się przepływ informacji w obrębie BizTalk. Dotyczy to zarówno błędów krytycznych (przerwanie połączenia, błędny komponent między składnikami), jak i normalnych "sytuacji wyjątkowych", przewidywanych przy projektowaniu aplikacji.

BizTalk 2002 może być zintegrowany z serwerem MOM (Microsoft Operation Manager Server), co pozwala, by część błędów zostawić do obsługi administratorowi. MOM równocześnie może np. poinformować programistę, że jego komponent zawiódł, i dodatkowo przesłać ostatnio przetwarzane komunikaty w celu łatwiejszego zdiagnozowania błędu.

Poza wygodą istnieje jeszcze jedna zaleta, związana ze stosowaniem rozwiązania typu BizTalk. Przy łączeniu funkcjonalności poszczególnych modułów trudno jest objąć cały schemat przepływów. Tworzenie szczegółowej dokumentacji jest czasochłonne i w rzeczywistości niezmiernie rzadko dokumentacja odpowiada bieżącemu stanowi systemu. BizTalk wymusza dokumentowanie procesu. Sam "program- diagram" jest równocześnie dokumentacją, którą może zrozumieć nawet osoba, nie zaj-mująca się na co dzień kodem aplikacji.