Koniec integracji
-
- Tomasz Kopacz,
- 01.08.2005
Trzy rynki, trzy rozwiązania
Po intensywnych zakupach systemów ERP Microsoft postanowił zaprezentować deweloperom możliwości tych pakietów. Firma dysponuje obecnie przynajmniej trzema liniami aplikacji tego typu, przeznaczonymi dla różnych odbiorców. Great Plains jest rozwiązaniem oferującym największą funkcjonalność "z pudełka". W wielu przypadkach wdrożenie sprowadza się do wgrania aplikacji i jej konfiguracji. Navision z oferowanymi wraz z nim pakietami ISST (Industry Specific Solution Tools) jest uważany za narzędzie do tworzenia rozwiązań branżowych.
ISST zawiera m.in. plan projektu, kwestionariusz pozwalający określić, jakie elementy mają być dostosowane (z którego potem wynika jak to ma być zrobione), oraz dane specyficzne dla danej gałęzi przemysłu. W konsekwencji wdrożenie ma się sprowadzać do postępowania wg sprawdzonego scenariusza i trwać nie dłużej niż 9 dni. Dodatkowo pakiet oferuje narzędzia do mapowania funkcjonalności, pozwalające przenieść istniejące dane do systemu Navision.
Oprócz tego Microsoft opracował zestaw narzędzi pozwalających na integrację systemu Navision (opartego o COM) ze światem .Net.
Służy do tego specjalna biblioteka C/FRONT, która generuje obiekt przypominający DataAdapter w .Net - choć bez modelu bezpołączeniowego. Pozwala także wywołać logikę biznesową, umieszczając żądanie w kolejce i czekając na wynik zwracany przez serwer aplikacyjny. Równocześnie dostępnych jest wiele przykładów pokazujących jak z interfejsu użytkownika Navision można wywołać kod .Net, który będzie "współuczestniczył" w realizacji procesu biznesowego.
Microsoft Axapta to produkt z "górnej półki" - przeznaczony głownie dla przedsiębiorstw zajmujących się szeroko pojętą produkcją, nawet w firmach wielonarodowych. Interfejs obecnie jest zlokalizowany dla 21 języków. Może działać jako rozwiązania 2-warstwowe (tańsze, ale wymagające niezawodnej sieci) i 3- warstwowe, z wydzielonymi serwerami aplikacyjnymi - serwerem-pojemnikiem na formatki i obiekty oraz serwerem Application Object Server, który dany obiekt "uruchamia". Oprócz tego można skonfigurować dodatkowy serwer do wykonywania operacji w trybie "wsadowym".
Axapta 4.0 jest silnie zintegrowana ze środowiskiem Windows. Wykorzystuje normalne wywołania RPC do komunikacji (zamiast używanego w systemie Axapta protokołu AOCP). AOS jest normalną usługą Windows. Można wykorzystać mechanizmy wyrównywania obciążeń Windows 2003. Komunikacja może być kompresowana, a dodatkowo metadane nie są przesyłane wraz z każdym obiektem, ale buforowane tam, gdzie są wykorzystywane. Axapta 4.0 obsługuje także metki radiowe (RFID). Na razie nie jest tam wykorzystywany nowy produkt Microsoft RFID Server, o którym tak przy okazji, wiadomo na razie bardzo mało. Kolejna, 5 wersja Axapta jest spodziewana w 2007 r.
Niestandardowe rozwiązania dla Axapty tworzy się za pomocą języka X++ oraz środowiska MorphX, w którym połączono model obiektowy oraz model bazy danych (np. zapis to tak naprawdę modyfikacja właściwości obiektu - która dodatkowo może być zamknięta w transakcji). X++ może też na podstawie obiektów automatycznie wygenerować interfejs użytkownika - i to w wielu językach (na podstawie informacji o lokalizacji powiązanych z metadanymi, które są używane w aktualnie tworzonym obiekcie).
Język X++ powstał jako połączenie języka obiektowego (u podstaw leżała Java) oraz SQL - do łatwej modyfikacji danych. Nie jest to język uniwersalny - ma ściśle określone zadanie - pisanie aplikacji biznesowych. Środowisko zaś to wyspecjalizowane IDE i debugger dostosowany do "potrzeb biznesowych" - np. można śledzić obiekt czysto biznesowy - konto - a nie skupiać się na tym, w jaki sposób tak naprawdę przechowywany jest stan "gotówki".
Warto też dodać, że z poziomu IDE bez problemów można śledzić nawet aplikację rozproszoną i obserwować np. działanie serwera AOS. Aplikacja kliencka IntelliMorph potrafi automatycznie dostosować się do wybranego języka - i jest narzędziem, w którym "renderują się" formatki generowane przez język X++ i obiekty AOS.
Do łatwiejszej rozbudowy Axapta wyróżnione zostały 4 główne warstwy funkcjonalności - standardowych developerów aplikacji, funkcjonalności specyficznej dla danego kraju, partnerów biznesowych i "ostatecznych użytkowników" (a raczej administratorów systemów Axapta). Co ważniejsze, każda z warstw nakłada pewne ograniczenia i izoluje zmiany, np. administrator nie uszkodzi logiki opracowanej przez partnera biznesowego, ponieważ to realizuje inna warstwa niż ta, do której ma dostęp.
Częścią Axapta jest także Enterprise Portal Framework, który w najnowszej wersji opiera się na SharePoint Portal. Business Connector to rozwiązanie integracyjne, które pozwala na połączenie systemu Axapta z dowolną inną aplikacją używającą technologii COM. Nie zabrakło także interfejsu Web, który pozwala zintegrować ten produkt z innymi systemami (z użyciem np. BizTalk Server). Warto dodać, że X++ generuje także UI dla EPF.
Microsoft nie ukrywa, że te narzędzia oferują wzajemnie konkurencyjne propozycje technologiczne i że z biegiem czasu zostaną one w jakiś sposób ujednolicone. Wydaje się, że pierwszym etapem będzie wykorzystanie możliwości, jakie daje DSL i "projektanci" w Visual Studio .Net 2005. Z różnych zapowiedzi można wnioskować, że taki proces zakończy się znacznie później niż w 2008 r.
BizTalk Server 2006
Microsoft pokazał na TechEd wersję beta BizTalk Server 2006. Nie wnosi on dużych zmian, jak to miało miejsce w przypadku wersji 2004. Runtime uaktualniono do .Net 2.0, pakietem do projektowania diagramów i generalnie - pisania rozwiązań jest Visual Studio .Net 2005. Wiadomo też, że może działać na 64-bitowej platformie Windows. Ale kilka interesujących rozszerzeń się znalazło.
Mechanizm BAM (Business Activity Monitoring) pozwala w czasie rzeczywistym monitorować stan procesu czy też wybrane wskaźniki. Wskaźnikiem może być np. dowolne wyrażenie MDX pobierające dane z kostki OLAP, liczbę błędów w transmisji itp. W zależności od konfiguracji i subskrypcji konkretny użytkownik może otrzymać informację o "przekroczeniu" wartości krytycznych.
Równocześnie wprowadzone zostały komponenty pozwalające "osadzić" specjalne kontrolki w Windows SharePoint Services, co pozwala zbudować portal do monitorowania BizTalk. Równocześnie pojawiło się API do wysyłania danych do komponentów BAM z dowolnej aplikacji, co pozwala wykorzystać ten mechanizm do sygnalizowania zdarzeń zachodzących w różnych systemach - nie tylko tych spiętych przez BizTalk Server.
Dodane zostały nowe adaptery, w tym do POP3, dzięki czemu proces BizTalk może być inicjowany na podstawie wiadomości e-mail wysłanej na specjalny adres. Równocześnie adapter SMTP pozwala elastycznie sformatować wiadomość. Pojawił się też adapter do SharePoint, co pozwala jako źródło komunikatów wskazać np. listę opublikowaną na WWW - bez konieczności uciekania się do parsowania HTML przy wykorzystaniu oddzielnego adaptera HTTP.
Można też prościej: zmapować płaski plik na strukturę XSD, i przez to znacznie rzadziej uciekać się do własnych skryptów. Pojawił się również kreator pozwalający automatycznie importować pliki tego typu.
W orkiestracji można definiować komunikaty ze zmienną ilością części - ta opcja jest przydatna w sytuacji, gdy przewidujemy, że w kolejnych wersjach komunikat będzie rozszerzony. Zwiększono liczbę identyfikatorów zdarzeń, tak by z jednej strony BizTalk lepiej współpracował z MOM, a z drugiej - by bez konieczności śledzenia można było podejrzeć co się dzieje w procesie przetwarzania dokumentów.
Zmienił się także sposób obsługi częściowo "nieprawidłowych" komunikatów. W wersji 2004 jeżeli w płaskim pliku z wieloma komunikatami jakiś fragment był uszkodzony, to cały plik był odrzucany. W 2006 można określić, że to co się uda, zostanie przetworzone, a reszta zostanie przekazana do specjalnej kolejki. Dodatkowo - w przypadku błędnego komunikatu można zainicjować specjalny routing (do specjalnego portu przeznaczonego na błędy) z logowaniem szczegółowych informacji. Wprowadzono także mechanizm wznawiania transmisji w "trybie hurtowym".
Na konferencji występował David Vaskevitch - jeden z trzech dyrektorów technicznych Microsoftu. Jego prezentacja dotyczyła przyszłości oprogramowania, ale nie tej "najbliższej", a raczej wizji tego, w jakim kierunku oprogramowanie będzie się rozwijać. To właśnie Vaskevitch w 1998 r. przedstawił w Los Angeles podstawową wizję Windows DNA, która z biegiem czasu przekształciła się w .Net. Do pełnej realizacji tej wizji brakuje jeszcze elementu Storage+. Wiadomo już jednak, że WinFS - rewolucyjny "system plików realizujący postulaty Storage+ będzie dostępny jako dodatkowa biblioteka, a nie tylko jako część systemu operacyjnego.
David Vaskevitch podkreślał, że potrzeby ludzi są tak naprawdę niezmienne, a komputery pojawiają się w coraz mniej oczekiwanych miejscach. W 1975 r. hasło Microsoft brzmiało: "Komputer na każdym biurku i w każdym domu". Ta wizja spełniła się jak na razie tylko w odniesieniu do Stanów Zjednoczonych. Teraz według Vaskevitcha przyszedł czas, by uczynić komputery bliższe ludziom - bringing computers and people together. Ta przenośnia podkreśla, że komputer ma przestać być "czymś dziwnym" - zabawką dla wprawnych techników, z którą zwykli ludzie sobie nie radzą. Ma stać się tak przyjazny i prosty w obsłudze, jak telefon komórkowy czy aparat cyfrowy, w których "technologii nie widać".
Głównym zastosowaniem komputerów jest obecnie komunikacja - samych maszyn w procesach B2B, ludzi wymieniających różne osobiste informacje, wspomnienia itp. Ten proces wymaga jeszcze wielu usprawnień technicznych, by komunikacja naprawdę była bezproblemowa. Odnosząc to do "biznesu", celem Microsoftu jest przekształcenie istniejących mechanizmów komunikacji i integracji, by integracja przestała być sprawą godną uwagi - aby działa się sama. To oczywiście wymaga sporych zmian w oprogramowaniu, a dokładniej tego, aby stało się ono samonaprawiające się i by nie wymagało nadzoru ze strony człowieka.
Główny problem na najbliższe lata dotyczy tworzenia aplikacji. Vaskevitch podkreśla, że tak naprawdę od czasów Fortrana czy nawet Cobola sposób programowania niewiele się zmienił. Obiekty, nowe języki - to raczej inny sposób wyrażania tego samego paradygmatu. Wniosek, według niego, jest taki, że nikt nie chce zmieniać istniejących aplikacji - mimo że w wielu przypadkach utrzymanie systemu to niemal archeologia, która ma na celu odkrycie "co też autor (który już np. odszedł na emeryturę) chciał w tym fragmencie kodu zrealizować".
Przyszłe aplikacje będą wykorzystywały "zintegrowany mechanizm przechowywania", w którym różnica między bazą danych a systemem plików ulegnie zatarciu. Z kolei warstwa prezentacyjna będzie modelem abstrakcyjnym, który będzie można zrealizować na różne sposoby - albo jako aplikację w stylu WWW, albo też jako bogatego klienta.
Co ważniejsze, ponieważ już niedługo "end-user" będzie dysponował pojemnościami rzędu terabajta - to bardzo istotnym elementem będzie stworzenie "prywatnych" obszarów przechowywania synchronizowanych z głównymi bankami danych. Jednak sercem rozwiązania będzie Business Process Server, który oddzieli całą logikę od pozostałych elementów aplikacji. Będzie on odpowiadać np. za mapowanie obiektowo-relacyjne, z którym będą współpracować komponenty metadanych po stronie repozytorium danych i interfejsu użytkownika, propagację transakcji, a także będzie mieć własny deklaratywny motor reguł itp.
Ostatecznym celem Microsoftu jest bowiem to, aby aplikacje można było łatwo konserwować i by były świadome swoich możliwości i ograniczeń.
Jednak, o ile na PDC w Los Angeles przedstawiona wizja miała od razu sugerowaną "realizację", o tyle obecnie w zasadzie jest przedstawiony kierunek zmian - konkretów brak. Na pewno krokiem w tym kierunku jest cała koncepcja Software Factories, który to mechanizm pozwala przenieść "programowanie" na wyższy stopień abstrakcji. Ale to jest tylko pierwszy krok ku głębszym zmianom.
