Integracja danych z procesami

Coraz trudniej rozdzielić fazę integracji procesów i dostępu od danych zawartych w aplikacji. Dlatego też rośnie znaczenie technologii wykorzystujących operacje na zbiorach oraz języków obiektowo-funkcyjnych.

Coraz trudniej rozdzielić fazę integracji procesów i dostępu od danych zawartych w aplikacji. Dlatego też rośnie znaczenie technologii wykorzystujących operacje na zbiorach oraz języków obiektowo-funkcyjnych.

Problemy z dostępem do danych już dawno wykroczyły poza rozważania na temat konstrukcji optymalnej warstwy dostępowej do danych. Obecnie coraz trudniej rozdzielić fazę integracji procesów i dostępu do zewnętrznych systemów od danych podstawowych dla aplikacji. Wiąże się z tym zupełnie inne spojrzenie na DAL (Data Access Layer). To nie tylko klasy opakowujące komunikację z bazą czy narzędzia ORM (Object Relational Mapping), które definiują model obiektowy, odpowiadający strukturze relacyjnej. DAL staje się warstwą API, która z jednej strony komunikuje się z bazą, pozwalając zadawać zapytania, ale z drugiej, równocześnie porozumiewa się z zewnętrznymi usługami czy interfejsami do procesów biznesowych.

Coraz częściej DAL zawiera też warstwę cache lub lokalny pojemnik aplikacyjny, ponieważ system musi pracować nawet wtedy, gdy niektóre ze źródeł danych nie będą dostępne. W takim świecie dosyć istotne jest zapewnienie w miarę wygodnych sposobów pracy z danymi. Większość aplikacji powstaje w językach obiektowych, które ułatwiają realizację logiki aplikacyjnej i tworzenie interfejsu użytkownika. W efekcie, w środku aplikacji mamy połączonych kilka światów - język SQL, usługi Web dostarczające dane, a także zwykłe tablice w danym języku programowania.

Języki obiektowo-funkcyjne

W technologii .Net pojawiła się ciekawa koncepcja LINQ (Language Integrated Query). Jest to zbiór operatorów i rozszerzeń pozwalających wykonywać operacje na zbiorach bezpośrednio z kodu C# 3.0 lub VB.Net 9.0. Można zadawać zapytania, wykorzystując składnię przypominającą SQL albo tzw. wyrażenia lambda. Technicznie stosowane są nowe mechanizmy C# - tzw. metody rozszerzeń. Zależą one od pojemnika, którego zapytanie dotyczy. Jeżeli pojemnikiem jest baza, do której istnieje provider LINQ, to takie wyrażenie będzie przełożone na język SQL, a jeżeli XML - to będzie to wyrażenie XPath. Zapytania mogą także dotyczyć kolekcji (np. tablic, list itp.) czy zestawów DataSet. Co ciekawsze, w niektórych przypadkach można łączyć różne pojemniki. Zależy to od implementacji providerów, ale można np. dodać zapytanie do kolekcji z zapytaniem do baz danych. Wtedy taką operację wykona serwer bazodanowy. Dzięki tej technologii operacje na zbiorach stały się normalną składową języka obiektowego, który w tym przypadku można określić jako język obiektowo-funkcyjny.

Oprócz mechanizmu LINQ do komunikacji z zewnętrznymi pojemnikami, w połowie 2008 r. ma być dostępny EDM - Entity Data Modelling. Jest to mechanizm, w którym niezależnie definiuje się pojemnik aplikacyjny (to, z czym pracuje aplikacja) oraz pojemnik fizyczny (baza lub inne źródło). Sposób odwzorowania ma być niemal dowolny. Dzięki temu system może być niezależny od zmian w schemacie bazy danych, a dodatkowo mechanizm ten pozwoli określić własne sposoby zasilania pojemnika aplikacyjnego. Można zdefiniować strukturę obiektową, z którą pracuje aplikacja, a potem częściowo wypełnić ją na podstawie bazy danych, a częściowo pobrać informacje z usług Web lub innych zewnętrznych systemów. Projekt ADO.Net Data Services ma pozwolić w jednej linijce kodu określić, że klasy EDM wygenerują obiekty WCF dostępne przy wykorzystaniu protokołu SOAP lub nawet POX (usługi Web). W ten sposób będzie można łatwo zdefiniować warstwę DAL w aplikacji wielowarstwowej, wykorzystując dodatkowo np. warstwę cache serwera WWW.

W świecie Javy powstaje klon LINQ o nazwie Quaere. Nie rozszerza on jednak języka Java, a dodaje zbiór funkcji i klas, które pozwalają zadawać zapytania w stylu LINQ. Jest to projekt open source, a kod ma być dostępny na licencji Apache 2. Pojawiły się też informacje, że Sun i IBM pracują nad podobnym rozwiązaniem, ale nie są jeszcze znane bliższe szczegóły.

Brak standardu metadanych

W przypadku danych nierelacyjnych, sytuacja jest bardziej skomplikowana. Większość pojemników "hierarchicznych" zapisuje informacje w jakiejś postaci XML/SGML. Stąd dosyć łatwo można zadawać zapytania (języki typu XQuery). W przypadku technologii LINQ jest specjalna odmiana LINQtoXML, pozwalająca generować zapytania do plików XML. Ale metody (czyli zapytania) dostępne dla tego pojemnika są nieco inne niż standardowe.

Jeszcze więcej problemów pojawia się w przypadku danych niestrukturalizowanych. Chyba każda poważna baza danych ma jakiś mechanizm wyszukiwania pełnotekstowego. Niestety, taka metoda, by była skuteczna, zakłada, że wiemy czego szukać. Dodatkowo mechanizmy indeksowania są w pewnym stopniu związane z językiem, w jakim powstał dokument, co jeszcze bardziej komplikuje sprawę w przypadku języka polskiego.

Tradycyjny rekord w bazie relacyjnej niezbyt dobrze nadaje się do przechowywania danych binarnych (a tym są np. dokumenty biurowe). W związku z tym pojawiają się różne koncepcje. Przykładowo, w SQL Server 2008 istnieje możliwość włączenia przechowywania danych binarnych w systemie plików (transakcyjnym NTFS). W ten sposób, z punktu widzenia systemu operacyjnego, jest to plik, ale równocześnie jest to tzw. BLOB (struktura bazodanowa). Innym pomysłem jest zdefiniowanie specjalnej warstwy w aplikacji/bibliotekach dostępowych do bazy, które przekierowują operacje na BLOB-ach do specjalnego pojemnika (np. EMC Centera lub Fujitsu Nearline). Co prawda nie jest to wtedy integralna część bazy, ale za to można dość łatwo przechować olbrzymie ilości informacji w sposób niemal przezroczysty z punktu widzenia kodu aplikacji.

Wciąż jednak pozostaje problem z wyszukiwaniem, który głównie dotyczy metadanych, opisujących co zawiera dokument. Nadal nie ma bowiem naturalnych elementów łączących różne informacje, bo w dokumentach nie przyjął się standard odpowiadający koncepcyjnie "hyperlinkom". Takim elementem wspólnym może być czasem np. numer zamówienia, ale ze względu na to, iż nie jest to element standardowy, raz będzie to numer, a innym razem jakieś hasło lub temat w e-mailu zrozumiałe tylko dla nadawcy i odbiorcy, którzy - analizując korespondencję - są w stanie zrozumieć, czego dana treść dotyczy.

Jedynym sposobem na rozwiązanie tego problemu jest zmuszenie człowieka do ręcznej kategoryzacji. Ale by to zrealizować, niezbędne jest wygodne narzędzie do przypisania słów kluczowych lub definiowania szablonu zamówienia, w którym specjalny znacznik będzie określał, gdzie przechowywany jest numer, co umożliwia wprowadzenie dodatkowej informacji w OpenXML wygodnym do parsowania przez systemy bazodanowe.

Innym pomysłem jest po prostu zintegrowanie UI do aplikacji biznesowych z pakietem biurowym. Przykładem może tu być SAP i Duet, lub SharePoint 2007, w których proces biznesowy może narzucać, by dokumenty miały wypełnione określone pola, zanim zostaną przyjęte przez system. Innym przykładem jest Dynamics CRM, którego jeden z interfejsów jest tak naprawdę "nakładką" na Outlooka.

Transakcje i integracjadanych z procesami

Kolejny problem dotyczy transakcji, a raczej integralności danych. Gdy wykorzystywana jest jedna baza danych, w zasadzie wystarczą mechanizmy ACID (Atomic Consistent Isolated Durable) zapewniające trwałość zmian. Ale jeśli w operacji bierze udział wiele różnych systemów zarządzanych przez niezależne podmioty, to mechanizmy bazodanowe nie wystarczają, a replikacja jest zawodna. Co prawda można zdefiniować rozproszoną transakcję w Internecie (np. wykorzystując WS-Transaction), ale taki mechanizm zakłada, że obie strony rozumieją ten protokół.

Dodatkowo, pojawia się problem, co zrobić, jeśli dane są integrowane z procesem biznesowym, który musi być ręcznie potwierdzony przez pracownika? Prosty przykład to system sprzedaży online, w którym obsługująca go firma korzysta z magazynu lub hurtowni zarządzanej przez inną firmę. Zlecenia są oczywiście przekazywane elektronicznie, ale np. transakcja obejmująca koszyk i wydanie z magazynu nie ma sensu, bo towar zostanie wydany dopiero po dokonaniu przedpłaty itp. W tym momencie trudno mówić nawet o "stanie magazynowym".

W takim wypadku lepiej ustawić procesy biznesowe tak, by prawdopodobieństwo wystąpienia braku towaru było minimalne i zamiast tworzenia niezawodnego systemu transakcyjnego, rozbudować mechanizm wycofywania zatwierdzonych operacji i generacji "przeprosin", gdy okazuje się, że sklep nie ma jednak na stanie towaru, który sprzedał.

Podobna sytuacja jest w przypadku pozornie prostego pytania - jaką ilość gotówki posiada w danym momencie duże przedsiębiorstwo? Część operacji trwa, część jest wycofywanych, ktoś wpłaca pieniądze, równocześnie inny departament dokonuje płatności itp. Skutek jest taki, że dostępnych jest kilka wersji "prawdy". Dokładna synchronizacja, mimo że technicznie możliwa, najczęściej nie ma sensu biznesowego. Lepiej ustalić przedziały czasowe, gdy wszystkie wydatki są rejestrowane.

Tomasz Kopacz jest wieloletnim publicystą Computerworld, obecnie pracuje jako Senior Architect Evangelist w polskim oddziale Microsoftu.


TOP 200