Politechnika Wrocławska

Wydziałowy Zakład Informatyki, Wydział Informatyki i Zarządzania

Wybrzeże Wyspiańskiego 27, 50-370 Wrocław

Dyplomowa praca magisterska

Integracja systemów biznesowych przy pomocy BizTalk i XML

Sebastian Zakłada

Promotor:	dr inż. Elżbieta Kosmulska-Bochenek
Ocena:

Wrocław, wrzesień 2001

Streszczenie

Praca przedstawia różne aspekty integracji systemów biznesowych na przykładzie inicjatywy BizTalk oraz serwera Micosoft BizTalk Server 2000. W części teoretycznej przybliża język XML, jako podstawowy nośnik informacji w nowoczesnych systemach integrujących aplikacje i procesy biznesowe, oraz przedstawia integrację systemów biznesowych od biznesowej i informatycznej, prezentując dotychczasowe osiągnięcia na tym polu, jak i najnowsze rozwiązanie w postaci serwerów BizTalk. Część praktyczna pracy jest realizacją przykładowego systemu opartego o serwer BizTalk - Otwartego Internetowego Rynku Transakcyjnego. Projekt polega na stworzeniu koncentratora biznesowego, który pośredniczyłby w transakcjach pomiędzy dużymi i małymi partnerami, udostępniając Małym i Średnim Przedsiębiorstwom odpowiedni interferjs poprzez przeglądarkę stron WWW. System pracuje na systemie Windows 2000 Advanced Server. Realizacja obejmuje analizę wizji i funkcjonalności w formie projektu funkcjonalnego, oraz projekt systemu i dokumentację wykonawczą pod postacią projektu wykonawczego w postaci modelu UML oraz dokumentów opisowych. Zbudowany system umożliwia przeprowadzenie transakcji zlecenia zakupu.

Podziękowania

Pragnę przede wszystkim podziękować moim kochanym Rodzicom za trud, jaki włożyli w moje wychowanie i wykształcenie. To dzięki Wam jestem tym, kim jestem. Dziękuję mojemu Dziadkowi za to, że zawsze wspierał mój zapał do informatyki i zapewnił mi wspaniały start w dorosłe życie. Specjalne podziękowania kieruję do Narcyza Adamusa z firmy Microsoft Polska za to, że we mnie uwierzył i pozwolił rozwinąć skrzydła, a także do Zarządu firmy GETIN Service Provider S.A. za wsparcie w ciągłym rozwoju i wyrozumiałość w trakcie trwania studiów. Dziękuję wszystkim, których nie wymienię tutaj z powodu, że jest Was tak dużo. Jesteście wspaniali.

• Spis treści

Wstęp

Integracja systemów biznesowych to jeden z dynamiczniej rozwijających się segmentów biznesu elektronicznego (ang. e-commerce). Potrzeba rozwijania tego typu rozwiązań wynika bezpośrednio z konieczności szybkiego dostosowywania modeli biznesowych wewnątrz firm do zmian zachodzących na rynku, jak również wzrostu konkurencyjności przy spadku kosztów własnych. Najpopularniejszym obecnie standardem systemów integracji biznesowej jest EDI - standard Elektronicznej Wymiany Danych (ang. Electronic Data Interchange), jednak rozwiązania na nim oparte są obarczone wieloma wadami, stawiając różne ograniczenia co do systemów podlegających integracji. Te ograniczenia oraz brak elastyczności powstałych rozwiązań implikowało narodziny standardu BizTalk, którego przedstawienie jest głównym celem pracy.

Systemami zbudowanymi w oparciu o wytyczne BizTalk zainteresowałem się po raz pierwszy w 1998 roku, kiedy to korporacja Microsoft przedstawiła na zamkniętym seminarium w Warszawie wersję roboczą standardów BizTalk oraz wstępne założenia produktu zgodnego z tym standardem. Zafascynowałem się potencjalnymi możliwościami i korzyściami, zarówno technicznymi, jak i biznesowymi, jakie otwierała inicjatywa BizTalk i od tamtego czasu bacznie się przyglądam rozwojowi standardu i aplikacji go wspierających.

Cel pracy

Duża bariera dostępu do nowoczesnych technologii dla małych i średnich przedsiębiorstw (w skrócie MŚP) jest faktem. Jednym z elementów zbyt drogich do wykorzystania jednostkowo przez większość MŚP jest integracja procesów biznesowych. Nie stać ich na wdrożenie i utrzymanie systemów klasy EDI, BizTalk czy też innych rozwiązań o podobnych możliwościach.

Dzięki upowszechnieniu się taniego dostępu do Internetu możliwe staje się udostępnienie tego typu usług w modelu hostingu ASP (ang. Application Services Providing, zdalne udostępnianie aplikacji). Projekt realizowany w ramach pracy polega na stworzeniu przykładowego koncentratora biznesowego, który pośredniczyłby w transakcjach pomiędzy dużymi i małymi partnerami, udostępniając MŚP, poprzez przeglądarkę stron WWW, odpowiedni interfejs do systemów informatycznych zaimplementowanych w dużych firmach.

Część teoretyczna stanowi wprowadzenie do nowoczesnych metod integracji systemów biznesowych przy pomocy serwerów BizTalk i języka XML, stanowiąc dobrą podstawę teoretyczną do zrozumienia stworzonego w ramach pracy projektu.

Rezultat pracy

W rezultacie przeprowadzonego wywiadu, analizy wielu pozycji książkowych, artykułów, stron internetowych, jak również uczestnictwa w wielu seminariach i konferencjach poświęconych BizTalk (m.in. „Konferencja TechEd 2001, 3.08 - 6.08, Barcelona”, „Seminarium BizTalk, grudzień 1998, Warszawa”, „DevDays, jesień 2000, Warszawa”) powstało opracowanie, będące wstępem do zapoznania się z pasjonującą tematyką związaną z szeroko rozumianą integracją systemów biznesowych, w szczególności, ale nie wyłącznie, w aspekcie BizTalk Server 2000.

Przedstawione w części praktycznej rozwiązanie Otwartego Internetowego Rynku Transakcyjnego udowodniło ogromną elastyczność serwera BizTalk Server 2000, który umożliwił powstanie ogólnego szkieletu rozwiązania integrującego dowolne organizacje przy wykorzystaniu platformy pośredniczącej z interfejsem opartym na stronach WWW. Analiza stworzonej szczegółowej dokumentacji systemu ilustruje bogate możliwości konfiguracyjne i implementacyjne serwera BizTalk Server 2000. System w postaci zaimplementowanej dla potrzeb niniejszej pracy umożliwia przeprowadzenie pełnej interakcji typu „zlecenie kupna” pomiędzy dwoma organizacjami, demonstrując funkcjonalność Komunikacji BizTalk (ang. BizTalk Messaging), Aranżacji BizTalk (ang. BizTalk Orchestration), oraz narzędzi wspomagających tworzenie dokumentów (BizTalk Editor, BizTalk Mapper) i administrację systemem (BizTalk Server Administration).

Część I: XML - Rozszerzalny Język Znaczników

• Wprowadzenie do języków znaczników

W dzisiejszym, zdominowanym przez komputery świecie, gdzie co dzień na naszych oczach dokonuje się niesamowity postęp w dziedzinie komputeryzacji życia nie pamiętamy już tego, jak wyglądała „nowoczesność” kilkanaście lat temu. Jeszcze całkiem niedawno dzisiejsze szybkie i niezawodne maszyny były ogromnymi i wolnymi szafami, przechowującymi dane na kartach i taśmach dziurkowanych, a w najlepszym razie na tysiącach kilometrów taśm magnetycznych. Tak naprawdę miały niewiele wspólnego z tym, co dzisiaj nazywamy komputerem.

We wczesnych latach siedemdziesiątych infrastruktura informatyczna większości organizacji była oparta na scentralizowanych centrach komputerowych, pomiędzy którymi informacje były przenoszone przy pomocy starannie konstruowanych procedur wsadowych. Sieci połączonych ze sobą komputerów pojawiały się powoli w bardzo dużych organizacjach, ale miały zupełnie odmienne od dzisiejszego zastosowanie. Za wyjątkiem eksperymentalnych projektów jak ARPANET, który położył podwaliny pod późniejszy Internet, sieci te były wyłącznie pomocą w stosowaniu sprawdzonych wówczas metod przetwarzania wsadowego, nie stanowiąc same w sobie znacznego przełomu. Nie praktykowano łączenia komputerów należących do różnych organizacji, a stosowane systemy stawały się coraz bardziej zamknięte. [4]

Boom komputerowy lat osiemdziesiątych spowodował, iż dotychczas luksusowy i bardzo drogi sprzęt komputerowy stał się powszechnie dostępny i najpierw zadomowił się w mniejszych organizacjach i firmach, a później trafił do użytkowników prywatnych. Zmienił się sposób myślenia, a jeszcze bardziej zmienił się rynek. Szybkość reakcji na zmiany na nim zachodzące, oraz potrzeba przeprowadzania coraz większej ilości transakcji wymusiła zmiany w sposobie tworzenia systemów komputerowych. Wtedy też powstała idea systemów otwartych. Nazywamy tak system komputerowy zorganizowany w sposób umożliwiający proste podłączenie go poprzez łącza telekomunikacyjne do innych, niezależnie zorganizowanych i umożliwiający wymianę danych na ogólnie przyjętych zasadach systemów komputerowych. [4]

1. Historia języków znaczników

1. Języki znaczników dla dokumentów

Od momentu, gdy komputery opuściły sale ośrodków obliczeniowych, rozpoczyna się historia elektronicznych dokumentów. Dużą część tej historii tworzą języki formatowania, a przede wszystkim języki znaczników (ang. markup languages), które uprościły i umożliwiły powszechną migrację dokumentów do postaci elektronicznej.

Przetwarzana informacja wymaga uporządkowania zarówno treści (struktura logiczna, znaczenie informacji itp.) jak i formy prezentacji (określenie wyglądu dokumentu, np. poprzez podział na paragrafy, określenie czcionek, marginesów itp.) w celu umożliwienia późniejszego wykorzystania takiego dokumentu czy to przez maszynę, czy opublikowanie go w formie papierowej lub też strony w Internecie. Oznakowanie (ang. markup) składa się ze znaczników, które dodane w odpowiedni sposób do tekstu pozwalają na zmianę jego znaczenia lub pewnych określonych przez definicję samego znacznika właściwości. Przykładem takiej właściwości jest na przykład sposób formatowania tekstu. Wykorzystanie oznakowania w tym celu jest jego najbardziej rozpowszechnionym zastosowaniem. Przykładami standaryzowanych języków znaczników ,służących do formatowania informacji w celu przekazania jej w atrakcyjnej i zrozumiałej dla człowieka formie są:

• RTF (ang. Rich Text Format, czyli formatowanie „czystego” tekstu), wykorzystywany m.in. przez program Microsoft Word, przy pomocy którego została napisana ta praca,

• znany i powszechnie stosowany w świecie profesjonalnej poligrafii TEX

• oraz drugi po angielskim najczęściej stosowany język Świata, czyli HTML, język oznakowania hipertekstowego (ang. Hypertext Markup Language).

Każdy z nich ma swoją własną specyfikę i obszar zastosowania. W celu przedstawienia podstawowych idei oznakowania wykorzystany zostanie format RTF. Przykład prostego dokumentu w tym formacie znajduje się na wydruku 1.

{\rtf1\ansi\ansicpg1250\deff0\deflang1045{\fonttbl

{\f0\fnil\fcharset238{\*\fname Times New Roman;}Times New Roman CE;}}

\viewkind4\uc1\pard\f0\fs20 Praca magisterska\par

\b Autor:\b0 Sebastian Zak\'b3ada\par

Rozdzia\'b3 1\par

\par

}

Wydruk 1 Przykład dokumentu sformatowanego przy użyciu RTF

Na pierwszy rzut oka wydaje się, że nie ma on większego sensu. Zbitek słów i znaków jest mało przejrzysty i niezrozumiały. Jednak już po krótkiej chwili łatwo można wyodrębnić elementy, z jakich się składa - w dużej części są to poprzedzone znakiem ukośnika \ (ang. backslash) elementy oznakowania, czyli znaczniki. Na przykład na samym początku dokumentu znajduje się znacznik \rtf1 informujący, że dokument został zakodowany przy wykorzystaniu formatu RTF, oraz zawierający wersję formatu RTF, jaka została użyta (w tym przypadku jest to RFT w wersji 1.0). Każdy następny znacznik określa, w jaki sposób tekst powinien zostać sformatowany. Warto zwrócić uwagę, że nie przekazujemy żadnej informacji co do znaczenia zawartości, a jedynie określamy jej pożądany wygląd po przetworzeniu przez odpowiednie oprogramowanie. Fakt ten stanie się bardzo istotny przy opisywaniu języka XML (ang. eXtensible Markup Language).

Dokument RTF z wydruku wczytany do programu WordPad wygląda jak na rysunku 1.

Rysunek 1 Dokument w formacie RTF wczytany do programu WordPad.

Znaczniki RTF w nim zawarte, po zinterpretowaniu przez program spowodowały odpowiednie wyświetlenie właściwej treści dokumentu, sformatowanej przy pomocy czcionki i styli takich, jak pogrubienie tekstu. Wszystkie elementy oznakowania zostały wykorzystane do sformatowania tekstu. Żaden z nich nie został wyświetlony na ekranie, ponieważ znaczniki nie stanowią informacji same w sobie, jedynie służą do jej opisania.

Ciekawszym z punktu widzenia tematu pracy przykładem języka znaczników jest stosowany do opisu stron internetowych język HTML. Jest to najszerzej stosowany język świata wykorzystujący znaczniki. Nie sposób zliczyć stron WWW, do których opisu został on wykorzystany.

HTML, czyli Język Oznakowania Hipertekstowego (ang. Hypertext Markup Language) to jak wskazuje jego nazwa język opierający się na znacznikach, wykorzystujący ideę hipertekstu. Jej istotą jest wprowadzenie odnośników, dzięki którym można zdefiniować połączenie pomiędzy dwoma dokumentami. Oznaczając fragment strony jako odnośnik tworzymy aktywne elementy, które umożliwiają określanie połączeń pomiędzy dokumentami. To właśnie ta właściwość HTMLa oraz fakt, że jest to bardzo prosty do nauczenia język spowodowały jego wielką popularność. Zapoczątkowało to erę Internetu i skierowało rozwój komputerów na zupełnie nowy tor.

Aby sformatować przy pomocy języka HTML ten sam tekst, co poprzednio, musimy stworzyć następujący dokument (wydruk 2).

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 3.2 Final//EN”>

<HTML>

<HEAD>

<META HTTP-EQUIV=”content-type” CONTENT=”text/html; CHARSET=iso-8859-2”>

</HEAD>

<BODY>

<DIV>Praca magisterska</DIV>

<DIV><B>Autor: </B>Sebastian Zakłada</DIV>

<DIV>Rozdział 1</DIV>

</BODY>

</HTML>

Wydruk 2 Dokument sformatowany w języku HTML.

Nie sposób nie zauważyć, jak bardzo różni się on od dokumentu w formacie RTF zaprezentowanego na wydruku 1. Przede wszystkim dokument został wyraźnie podzielony na dwie sekcje - nagłówka (<HEAD>), oraz właściwej zawartości dokumentu (<BODY>). Dzięki wprowadzeniu takiej struktury wewnętrznej jest on przejrzysty i łatwy do zrozumienia przez człowieka. Do sformatowania dokumentu wykorzystano odpowiednie elementy zdefiniowane w standardzie języka HTML. Elementy można spotkać w językach znaczników bardzo często, są to pary znaczników, pomiędzy którymi znajduje się zawartość dokumentu. Na przykład do oznaczenia wytłuszczenia tekstu w języku HTML wykorzystuje się element <B></B>.

Rzut oka na rysunek 2 dowodzi, że dokument w formacie HTML, wyświetlony przy użyciu odpowiedniego interpretera (w tym przypadku przeglądarki internetowej), wygląda bardzo podobnie do swojego zinterpretowanego RTFowego odpowiednika.

Rysunek 2 Dokument w formacie HTML wczytany do przeglądarki internetowej Internet Explorer.

Oczywiście przykład przedstawiony powyżej jest bardzo prosty, a większość dokumentów HTMLowych jest dużo bardziej złożona, jednak mimo to dużo prościej edytować ręcznie, wyłącznie przy pomocy edytora tekstu dokument przygotowany w HTMLu, niż na przykład jego odpowiednik w formacie RTF. Powód jest bardzo prosty - znaczniki stosowane w tym języku są wystarczająco czytelne dla człowieka, by mógł on wyobrazić sobie, jak będzie po zinterpretowaniu wyglądał edytowany przez niego dokument. Dowodem na to jest obecność na rynku wielkiej ilości różnych, często bardzo rozbudowanych edytorów kodu HTML. Natomiast trudno sobie nawet wyobrazić próbę ogarnięcia przez człowieka dużego dokumentu sformatowanego w RTFie. Jest to przykład języka znaczników, w którym zrozumiałość i czytelność kodu dla człowieka nie była celem samym w sobie. Dlatego dokumenty RTF tworzone i interpretowane są wyłącznie przy wykorzystaniu odpowiednich aplikacji, a prosty dokument w języku HTML można stworzyć w dowolnym edytorze tekstów, i co bardzo istotne, w podobny sposób zinterpretować na dowolnej platformie sprzętowej i programowej, albowiem HTML jest językiem niezależnym od platformy (ang. platform-independent).

1. GML i SGML

HTML jest bardzo podobny, a często bywa wręcz mylony z głównym bohaterem pierwszej części pracy, jakim jest XML - Rozszerzalny Język Znakowania (ang. Extensible Markup Language). Zanim jednak powiem więcej na temat tego fascynującego języka, bo XML jest niewątpliwie bardzo ciekawy i ma bardzo różnorodny obszar zastosowań, chciałbym powiedzieć parę słów na temat jego historii i wyjaśnić, skąd się wziął pomysł na jego stworzenie.

W chwili obecnej wyróżnia się dwa typy języków znaczników. Są to języki ukierunkowane (ang. specific) oraz generalizowane (ang. generalized). Ukierunkowanym językiem znaczników nazywamy taki język, który został stworzony dla potrzeb określonego urządzenia lub aplikacji, w wyniku powstania określonej potrzeby i wyłącznie dla jej celów. Języki generalizowane to języki, które opisując wyłącznie strukturę i znaczenie tekstu zawartego w dokumencie są na tyle ogólne, że mogą zostać użyte w wielu różnych aplikacjach.

Przykładem języków ukierunkowanych są wspominane wcześniej RTF i HTML. Obydwa zostały stworzone w ściśle określonym celu. HTML jest językiem opisu zawartości stron internetowych, a RTF językiem formatowania tekstu. Jednak języki tego typu mają dwie główne wady, które znacznie ograniczają obszar ich zastosowań.

• nie są rozszerzalne - wykorzystując je jest się ograniczonym do zestawu znaczników zdefiniowanych w specyfikacji, nie można tworzyć własnych elementów języka dopasowując go zmieniających się potrzeb

• dokumenty nie są samoopisujące się i z tego powodu trudno wykorzystać dane w nich zawarte do innych celów, niż zostało to założone podczas tworzenia dokumentu

Aby nie być narażonym na tego typu ograniczenia zaproponowano inne podejście do tworzenia języków znaczników. Jak to miało bardzo często miejsce w historii rozwoju komputeryzacji, sprawą zajęła się firma IBM i w latach 70tych dr C. F. Goldfarb wraz z dwoma współpracownikami zaproponował metodę definiowania języków generalizowanych, na którą składały się dwa główne postulaty:

• oznakowanie powinno opisywać strukturę dokumentu, a nie jego wygląd

• składnia powinna być wystarczająco ścisła, aby kod mógł być łatwo zrozumiały zarówno przez człowieka, jak i przez komputer.

Propozycja złożona przez IBM zaowocowała powstaniem specyfikacji Document Composition Facility Generalized Markup Language (DCF GML, w skrócie GML).

Kolejny krok w kierunku standaryzacji generalizowanych języków znaczników został spowodowany przez kolejną wielką lokomotywę postępu w wielu dziedzinach nauki, czyli Amerykański Departament Obrony Narodowej (w skrócie DoD, od ang. Department Of Defense). DoD poszukiwał sposobu na ograniczenie ilości papierowych dokumentów, jakie znajdowały się wówczas w jego obiegu wewnętrznym poprzez wprowadzenie ich elektronicznego odpowiednika, jak również sposobu na wprowadzenie standardowego mechanizmu komunikacji pomiędzy swoimi kontrahentami. Odpowiednim rozwiązaniem okazał się ustandaryzowany przez ISO (International Organization for Standardization) w roku 1986 język SGML (Standard Generalized Markup Language, ISO 8879).

SGML to bardzo rozbudowany GML. Rozszerzona specyfikacja wprowadziła istotne usprawnienia, między innymi:

• określiła dokładnie, jakie znaki mogły się znaleźć w dokumencie, umożliwiając jawne zadeklarowanie ich używanego zestawu (np. ISO8859)

• udostępniła metodę definicji obiektów używanych w dokumencie, wprowadzając pojęcie encji (ang. entity)

• umożliwiła włączanie do dokumentu danych zewnętrznych (np. pochodzących z osobnego pliku)

• wprowadziła DTD (ang. Document Type Definition), słownik określający strukturę dokumentu

Dokument przedstawiony w poprzednich przykładach opisany w sposób zgodny ze specyfikacją SGML mógłby wyglądać następująco (patrz wydruk 3):

<!DOCTYPE BOOK PUBLIC “-//BJP//DTD MEMO//EN”>

<BOOK>

<TITLE>Praca magisterska

<AUTHOR>Sebastian Zakłada

<CHAPTER>Rozdział 1

</BOOK>

Wydruk 3 Przykładowy dokument SGML.

Uważna osoba łatwo dostrzeże podobieństwa w stosunku do wersji tego dokumentu opisanego w języku HTML (wydruk 2). Nie ma w tym nic dziwnego, ponieważ HTML jest jedną z wielu aplikacji języka SGML. Oznacza to, że został on wyspecyfikowany przy wykorzystaniu standardu SGML. Ta cecha SGMLa, czyli zdolność tworzenia innych języków na swojej podstawie powoduje, że należy on do grupy metajęzyków. Metajęzykiem nazywamy język, który może służyć do opisu innego języka. Mają one zastosowanie przede wszystkim w formalnym opisie języków programowania. Przykładem metajęzyków są BNF (Backus-Naur-Form), SGML czy też XML. [5]

Widać jednak również istotne różnice w stosunku do wersji HTMLowej. Dokument widoczny na wydruku 3 wyraźnie opisuje strukturę informacji. „Praca magisterska” jest tytułem całego opracowania, „Sebastian Zakłada” - autorem, a „Rozdział pierwszy” rozdziałem książki. Wykorzystując zaproponowany zestaw czterech znaczników <BOOK>, <TITLE>, <AUTHOR> i <CHAPTER> można opisać prostą strukturę dowolnej publikacji. HTML nie pozwala na określenie znaczenia poszczególnych elementów dokumentu. Wykorzystywany w nim zestaw znaczników ma ściśle określone zastosowanie - opis wyglądu dokumentu. Jest on językiem ukierunkowanym, językiem prezentacji informacji. Został stworzony w celu opisu stron WWW. Inną istotną różnicą w stosunku do języka SGML jest to, że HTML nie jest rozszerzalny. Jego specyfikacja nie pozwala na dodawanie nowych znaczników i budowanie nowych języków, ponieważ, jak już wspomniałem wcześniej, nie jest on metajęzykiem.

Teraz, kiedy przedstawiona już została krótka historia powstania i rozwoju języków znaczników, czas przejść do głównego tematu pierwszej części pracy, jakim jest język XML.

1. XML - nowy pomysł na stary standard

Nic na tym świecie nie jest wolne od wad i SGML nie jest wyjątkiem od tej reguły. Procedury standaryzacyjne ISO sprawdzają się od dawna w branży przemysłowej, gdzie raz ustanowiony standard technologiczny nie zmienia się przez długi okres czasu. Na przykład określenie standardowego składu betonu pewnej klasy jest dość stabilną decyzją, ponieważ metody budowy domów nie zmieniają się kilka razy w roku. Dobrze jednak wiadomo, że zmiany w branży informatycznej dokonują się w zastraszającym tempie. Dość powiedzieć, że wyrafinowany technologicznie sprzęt sprzed 10 lat dzisiaj można wykorzystać wyłącznie w celach muzealnych. Niedługi w kontekście branży przemysłowej okres czasu tutaj stanowi całą epokę. Dlatego już w momencie ogłoszenia SGML standardem ISO 8879 był on nieco przestarzały. Co więcej, ponieważ znajduje się on w posiadaniu środowiska czysto akademickiego, bardziej zainteresowanego w czystości formalnej specyfikacji niż w jej faktycznej użyteczności, SGML okazał się być niesamowicie skomplikowany. Dlatego, mimo prób zastosowania praktycznego (nie bez powodzenia, przykładem jest język HTML) uzyskał on miano technologii obiecującej, jednak wyjątkowo trudnej w użyciu. Powstało nawet alternatywne rozwinięcie akronimu SGML : „Sounds Good, Maybe Later”, czyli „Brzmi Nieźle, Może Później...”. W erze Internetu technologia taka, jak SGML okazała się być zbyt mało czytelna i przeładowana, a w efekcie nieużyteczna w masowych zastosowaniach internetowych.

W roku 1996 do światowej organizacji World Wide Web Consortium (W3C) składającej się z firm zainteresowanych tworzeniem standardów w Internecie i utrzymującej większość standardów sieciowych (m.in. HTML, CSS) zgłosiła się grupa najlepszych specjalistów języka SGML z całego świata i zaproponowała utworzenie grupy, której celem było by przygotowanie standardu opartego na SGML języka dostosowanego do zastosowań internetowych. Efektem jej prac było powstanie w lutym 1998 roku dokumentu „XML 1.0 W3C Recommendation” opisującego nowo powstały, rewolucyjny standard metajęzyka.

W efekcie prac powstał prosty, a mimo to wyjątkowo użyteczny i elastyczny język. Pozbyto się nadmiernej złożoności, będącej jedną z głównych wad SGML, a dzięki wyeliminowaniu jego wszystkich opcjonalnych właściwości spowodowano, że XML jest bardzo szybki i w pełni przenośny. Pozostawiono jedynie niezbędne elementy metajęzyka SGML i rozszerzono jego specyfikację w celu uczynienia z niego narzędzia dostosowanego do wymagań Internetu. Powstał język prosty szybki i wyjątkowo elegancki.

• XML - elementy języka

XML jest bezpośrednim spadkobiercą języka SGML, a dokładniej jego podzbiorem. Wynika to z przyjęcia przez grupę roboczą W3C SGMLa jako bazy dla nowego standardu. Z tego powodu każdy dokument XML jest jednocześnie dokumentem SGML. Było to jedno z głównych założeń, jakie postawiła sobie grupa przygotowująca standard. Założenia te brzmią następująco [3]:

1. XML powinien być bezpośrednio przystosowany do wykorzystania w Internecie.

2. XML powinien wspierać szeroki wachlarz aplikacji.

3. XML powinien być kompatybilny z SGML.

4. Pisanie programów przetwarzających XML powinno być proste.

Programy analizujące tekst napisany w języku XML nazywamy parserami lub procesorami. Przetworzenie dokumentu polega na rozbiciu go na elementy i zrozumieniu jego struktury oraz zależności pomiędzy nimi. XML jest przetwarzalny (ang. parseable), ponieważ podlega określonym zasadom określonym w specyfikacji języka, oraz zawartych w DTD (lub tzw. schema).

5. Ilość opcjonalnych właściwości języka powinna być minimalna, najlepiej zerowa.

Poprzez rezygnację ze zdefiniowania opcjonalnych części języka, autorzy specyfikacji XML zlikwidowali jedną z podstawowych wad SGMLa, którą była niekompatybilność dokumentów stworzonych przez różne osoby. Mnogość dodatkowych opcji dopuszczanych przez specyfikację języka powodowała, że programy wykorzystujące SGML nie potrafiły przetworzyć dokumentu stworzonego przez inny program.

6. Dokumenty XMLowe powinny być zrozumiałe dla człowieka i przejrzyste.

7. Specyfikacja języka XML powinna zostać przygotowana szybko.

Ten wymóg staje się zrozumiały, gdy przypomnimy sobie, ile trwało ukonstytuowanie się standardu SGML i jakie były negatywne skutki opóźnień (patrz rozdział 2.1.3).

8. Specyfikacja języka powinna być formalna i zwięzła.

9. Tworzenie dokumentów w XML powinno być proste.

10. Zwięzłość dokumentów nie jest istotna.

Trzy ostatnie postulaty wynikają bezpośrednio z chęci zapewnienia językowi jak największej popularności. Dzięki wyspecyfikowaniu języka przy użyciu EBNF (Extended Backus-Naur Form) specyfikacja stała się zrozumiała dla wszystkich zainteresowanych i jednoznaczna. Ostatni punkt był spowodowany chęcią uniemożliwienia autorom dokumentów opisywanych z wykorzystaniem XML różnych dróg “na skróty”, które możliwe w SGML czy też w HTML powodowały bałagan w wytworzonym kodzie oraz znacznie utrudniało tworzenie efektywnych procesorów języka.

1. Dokumenty XML

Jednym z podstawowych kryteriów, jakie stosujemy przy określaniu właściwości dokumentów XML jest ich poprawność. Dokument XML musi poprawny składniowo (ang. well-formed). Dokument, który jest poprawny składniowo może (ale nie musi) być również poprawny strukturalnie (ang. valid) [3]. Dokument XML składa się z jednego lub więcej elementów.

1. Poprawność dokumentu XML

Aby dokument XML mógł być przetwarzany przez parser, musi być poprawny składniowo. W przeciwnym razie zostanie zwrócony błąd i przetwarzanie dokumentu nie będzie możliwe.

Dokument jest poprawny składniowo (ang. well-formed), jeśli spełnia wszystkie zasady zawarte w specyfikacji oraz każda encja przetwarzalna (ang. parsed entity) do której się odnosi jest również poprawna składniowo. [3]

Poprawność składniowa to spełnienie wszystkich zasad zawartych w specyfikacji, jednak wyróżnia się pewne jej elementy, które są najistotniejsze z punktu widzenia poprawności dokumentu XML. [7]

1. Każdy element musi mieć znacznik początkowy i końcowy.

2. Dokument musi mieć jeden, unikatowy element główny (ang. root element).

3. W nazwach elementów i atrybutów rozróżniane są duże i małe litery (ang. case-sensitive).

4. Elementy muszą być poprawnie zagnieżdżone.

5. Do pewnych znaków odwoływać się można tylko poprzez odpowiednie encje (ang. must be escaped).

6. Nazwy atrybutów muszą znajdować się w cudzysłowach.

7. Puste elementy są znakowane w odpowiedni, zgodny ze specyfikacją sposób.

Oprócz poprawności składniowej dokument może także być poprawny strukturalnie.

Dokument jest poprawny strukturalnie (ang. valid), jeśli jest z nim związana deklaracja typu dokumentu (DTD) oraz jeśli dokument spełnia ograniczenia w niej zawarte. [3]

1. Struktura dokumentu XML

Możliwość zdefiniowania zarówno logicznej, jak i fizycznej struktury dokumentu jest jedną z największych zalet języka XML. Struktura logiczna opisuje szablon, na podstawie którego tworzony jest dokument, oraz mówi jakie dane się na niego składają. Struktura fizyczna określa fizyczne dane zawarte w dokumencie.[7]

1. Struktura logiczna

Dokument XML składa się z deklaracji, instrukcji przetwarzania i komentarzy, oraz zawiera jeden, lub mniej elementów. Granice elementu dokumentu XML określa para znaczników: początkowy i końcowy (np. <ELEM></ELEM>), lub w przypadku elementu pustego - znacznik elementu pustego (np. <ELEM/>). Każdy element może mieć wyspecyfikowany zbiór atrybutów, które reprezentowane są w notacji przez parę: nazwa, wartość (np. <ELEM ATR=”1” ATR2=”100”/>). Na szczególną uwagę zasługuje element pusty. Ponieważ w języku XML każdy element musi zawierać znacznik końcowy, a para znaczników <ELEMENT></ELEMENT> wygląda nienaturalnie, pusty element można zapisać w sposób skrócony jako <ELEMENT/>.

Struktura typowego dokumentu XML została przedstawiona na rysunku 3.

Rysunek 3 Struktura dokumentu XML

Każdy dokument XML zaczyna się od prologu, w skład którego wchodzą dwa opcjonalne elementy

1. Deklaracja XML (ang. XML Declaration). [7],[3]

Składa się ona z elementu określającego wersję specyfikacji XML, przy użyciu której został stworzony dokument, oraz informacji na temat strony kodowej wraz z deklaracją niezależności dokumentu (ang. stand-alone document declaration). Deklaracja niezależności informuje, czy dokument zawiera zewnętrzną deklarację DTD i musi być napisana małymi literami.

Przykładowa deklaracja XML znajduje się na wydruku 4.

<?xml version=”1.0” encoding=”UTF-8” standalone=”yes” ?>

Wydruk 4 Przykładowa deklaracja XML.

Mimo, iż deklaracja XML jest opcjonalna (specyfikacja języka jej nie wymaga), powinna być umieszczana na początku każdego dokumentu.

2. Deklaracja typu dokumentu DTD [7],[3]

Deklaracja Typu Dokumentu (ang. Document Type Declaration) zawiera lub wskazuje na deklarację znaczników które określają gramatykę dla określonej klasy dokumentów. Gramatyka ta znana jest jako definicja typu dokumentu, w skrócie DTD. Deklaracja typu dokumentu może wskazywać na zewnętrzny podzbiór zawierający deklarację znaczników i/lub może zawierać deklarację bezpośrednio w wewnętrznym podzbiorze. DTD dla dokumentu składa się z obu połączonych wcześniej wymienionych podzbiorów. [3]

Przykładowa deklaracja typu dokumentu znajduje się na wydruku 5. Określa ona, że dokument należy do klasy dokumentów BookSpecification i podporządkowuje się regułom określonym w DTD zawartym w pliku BookSpec.dtd.

<!DOCTYPE BookSpecification SYSTEM “BookSpec.dtd”>

Wydruk 5 Przykładowa deklaracja typu dokumentu.

Po zakończeniu prologu rozpoczyna się główny element dokumentu (ang. document element), obudowujący wszystkie dane. Składa się on z zagnieżdżonych elementów oraz encji zewnętrznych, które tworzą hierarchiczną strukturę drzewa opisującą logiczną oraz fizyczną strukturę danych. Używając relacji dziecko/rodzic - zgodnie z zasadami poprawności składniowej (ang. well-formedness) każdy zagnieżdżany element (dziecko) zawiera się w całości w elemencie rodzica.

Przykładowa zawartość głównego elementu dokumentu wraz z nim samym znajduje się na wydruku 6.

<BOOK>

<TITLE>Praca magisterska</TITLE>

<AUTHOR>Sebastian Zakłada</AUTHOR>

<CHAPTER>Rozdział 1</CHAPTER>

</BOOK>

Wydruk 6 Główny element dokumentu i zagnieżdżone w nim elementy.

Po połączeniu prologu i głównego elementu dokumentu otrzymujemy dokument XML, który w całości zobaczyć można na wydruku 7.

<?xml version=”1.0” encoding=”UTF-8” standalone=”yes” ?>

<!DOCTYPE BookSpecification SYSTEM “BookSpec.dtd”>

<BOOK>

<TITLE>Praca magisterska</TITLE>

<AUTHOR>Sebastian Zakłada</AUTHOR>

<CHAPTER>Rozdział 1</CHAPTER>

</BOOK>

Wydruk 7 Przykładowy dokument XML.

1. Struktura fizyczna

Dokument XML może składać się z jednej lub więcej jednostek przechowywania (ang. storage units). Jednostki te są inaczej zwane encjami (ang. entities). Wszystkie encje, z wyjątkiem głównej oraz zewnętrznych podzbiorów DTD, mają zawartość oraz nazwę. Każdy dokument XML zawiera jedną encję główną (ang. document entity), która stanowi punkt startowy dla procesora XML i może zawierać cały dokument [3]. Encje mogą być przetwarzane (ang. parsed entity) lub nieprzetwarzane (ang. unparsed entity).

Encja przetwarzana zawiera dane tekstowe, które stają się częścią dokumentu XML zaraz po jego przetworzeniu. Encja nieprzetwarzana jest kontenerem, którego zawartością może, lecz nie musi być tekst. Encja tego typu nie jest bezpośrednio przetwarzana przez procesor języka XML.[8]

Przykładowa deklaracja encji znajduje się na wydruku 8.

<!ENTITY CH1 „rozdział 1”>

Wydruk 8 Przykładowa deklaracja encji.

Do encji odwołujemy się podając jej nazwę poprzedzoną znakiem „&” (ang. ampersand) oraz zakańczając ją średnikiem, np.

<TRESC>Po wstępie do pracy następuje &CH1;</TRESC>

Wydruk 9 Przykład odwołania do encji.

Encja nieprzetwarzana najczęściej zawiera dane binarne i dlatego nie jest przetwarzana przez procesor języka XML.

Ponieważ znaki <> oraz / są zarezerwowane dla potrzeb języka, w celu ich wyświetlenia wykorzystuje się encje predefiniowane. Czynność tą nazywa się z języka angielskiego escape. Encje predefiniowane w języku XML zebrane są w tabeli 1.

encja predefiniowana	zastępuje
&lt;	<
&gt;	>
&amp;	&
&apos;	`
&quot;	“

Tabela 1 Encje predefiniowane w języku XML.

Encja może być wewnętrzna (ang. internal entity) lub zewnętrzna (ang. external entity). Typy te różnią się sposobem deklaracji oraz tym, że w przypadku encji wewnętrznej zarówno deklaracja, jak i treść znajdują się w całości w dokumencie XML, a deklaracja encji zewnętrznej wymaga od procesora języka XML załadowania zawartości encji z zewnętrznej lokacji, podanej na przykład w formie URI (ang. Uniform Resource Identifier). URI jest ogólnym określeniem na zasoby sieciowe sformalizowanym przez IETF (Internet Engineering Task Force) w dokumencie RFC 2936 [14],[8],[12]. Przykładami URI są URN (ang. Unified Resource Name) i URL (ang. Unified Resource Locator).

Przykładem encji wewnętrznej jest encja zadeklarowana na wydruku 8. Ilustracja encji zewnętrznej znajduje się na wydruku 10.

<!ENTITY OkladkaKsiazki

SYSTEM „http://sebekz.getin.pl/xml/gfx/xmlcover.gif„

NDATA GIF>

Wydruk 10 Ilustracja encji zewnętrznej.

1. Opisywanie struktury dokumentu

Jeden z głównych postulatów jaki przedstawiła grupa pracująca nad specyfikacją języka XML brzmi: „Dokumenty XMLowe powinny być zrozumiałe dla człowieka i przejrzyste”. Dzięki przejrzystej, hierarchicznej strukturze dokument XML jest samoopisujący dla człowieka. Jednak aby umożliwić „zrozumienie” treści zawartej w takim dokumencie komputerom, należy do niego dołączyć formalną specyfikację struktury dokumentu. Taką specyfikację struktury nazywamy schematem (ang. schema). Innym słowem schematem nazywamy opis struktury zbioru informacji.

1. DTD

Specyfikacja języka XML 1.0 wskazuje jako język opisu struktury dokumentu składnię schematu znaną jeszcze z SGML, a mianowicie wspominaną przy okazji opisu struktury logicznej dokumentu XML Definicję Typu Dokumentu (DTD) (patrz rozdział 3.1.2.1). W tej części pracy zostało też pokrótce opisane, jak można w istniejącym dokumencie XML zadeklarować wcześniej stworzone DTD. Teraz zostanie przedstawiony przykład prostej definicji typu dokumentu, zostaną również opisane elementy na nią się składające.

Rozszerzony dokument XML z poprzednich przykładów posłuży teraz jako przykład do opisania za pomocą DTD.

<?xml version=”1.0” encoding=”UTF-8” standalone=”yes” ?>

<!DOCTYPE BookSpecification SYSTEM “BookSpec.dtd”>

<BOOK>

<TITLE>Praca magisterska</TITLE>

<AUTHOR>Sebastian Zakłada</AUTHOR>

<CHAPTER PAGES=”20”>Rozdział 1</CHAPTER>

<TOTALPAGES>240</TOTALPAGES>

</BOOK>

Wydruk 11 Przykładowy dokument XML

DTD stworzone dla tego dokumentu i zapisane w pliku BookSpec.dtd mogło by wyglądać następująco:

1. <!DOCTYPE BookSpecification [

2. <!ELEMENT BOOK (TITLE, AUTHOR, CHAPTER+, TOTALPAGES?)>

3. <!ELEMENT TITLE (#PCDATA)>

4. <!ELEMENT AUTHOR (#PCDATA)>

5. <!ELEMENT CHAPTER (#PCDATA)>

6. <!ATTLIST CHAPTER

7. PAGES CDATA #IMPLIED>

8.

9. <!ELEMENT PAGES (#PCDATA)>

10. ]>

Wydruk 12 Deklaracja typu dokumentu BookSpec.dtd

Dzięki zastosowaniu odpowiednich wcięć w kodzie łatwo można dostrzec hierarchię dokumentu z wydruku 11 zdefiniowaną przy pomocy przedstawionego DTD. Poniższa tabela objaśnia powstałą definicję typu dokumentu.

Numer linii	Opis
2	Linia druga zawiera deklarację <!ELEMENT> głównego elementu dokumentu <BOOK>. W nawiasie znajduje się lista oddzielonych przecinkami pozostałych elementów, z których może się składać dokument - są to dzieci elementu <BOOK>. Elementy te muszą się pojawić dokładnie w takiej kolejności, w jakiej zostały wymienione w liście. Elementy <TITLE> i <AUTHOR> muszą się pojawić w dokumencie raz, element <CHAPTER> raz lub więcej razy, a element <TOTALPAGES> jest opcjonalny. Dokładny opis znaczenia poszczególnych symboli takich, jak przecinek czy znak zapytania znajduje się między innymi w specyfikacji języka XML [3].
3-9	Pozostałe elementy dokumentu XML są opisane podobnie z tą różnicą, iż jako elementy nie posiadające dzieci mają w nawiasie określony typ danych. Słowo kluczowe #PCDATA oznacza, iż dane zawarte pomiędzy znacznikami elementu są przetwarzanymi danymi znakowymi. Drugim dopuszczalnym, oznaczanym słowem kluczowym CDATA typem są nieprzetwarzane dane znakowe.
6-7	Wyjątkowym z punktu widzenia przykładu elementem jest <CHAPTER>, który pozwala na podanie atrybutu PAGES. Listę atrybutów definiujemy w DTD za pomocą słowa kluczowego <!ATTLIST>. Pozwala ona na wyspecyfikowanie, oprócz nazw elementu oraz samego atrybutu, typu danych jaki jest dlań dopuszczalny oraz wartości domyślnej, która w naszym przypadku oznaczona słowem kluczowym #IMPLIED odznacza, iż parametr ten jest opcjonalny. Dokładny opis specyfikacji atrybutu przy pomocy DTD znajduje się między innymi w specyfikacji języka XML [3].

Tabela 2 Opis DTD z wydruku 12

Specyfikacja DTD została zaprojektowana 15 lat temu i jako język opisujący strukturę dokumentów SGML spisała się znakomicie. Jednak w dobie biznesu elektronicznego nie spełnia wymagań jakie stawiają przed nią dzisiejsze standardy wymiany danych oparte na XML. Przede wszystkim DTD nie wykorzystuje do opisu struktury dokumentów składni XML i jako taki nie spełnia szóstego postulatu XML, który mówi, iż „Dokumenty XML powinny być zrozumiałe dla człowieka i przejrzyste”. Drugim, bardzo istotnym mankamentem jest fakt, iż nie pozwala on na wykorzystanie innego typu danych niż tekst, co bardzo ogranicza jego użyteczność w przypadku konieczności wyspecyfikowania na przykład pola opisującego kwotę transakcji, czyli pola numerycznego. Uniemożliwia to całkowite rozdzielenie danych od aplikacji je przetwarzających, ponieważ każda z nich musiała by w taki sam sposób sprawdzać poprawność pewnych pól. Jednak chyba największą i zupełnie niemożliwą do ominięcia wadą DTD jest fakt niemożności wykorzystania więcej niż jednej definicji typu dokumentu w dokumencie XML. Specyfikacja ogranicza bowiem ilość DTD w dokumencie XML do jednego. Tymczasem często zachodzi konieczność dostosowania fragmentu specyfikacji dokumentu XML w taki sposób, aby była zgodna z pewnymi założeniami. Dobrym przykładem jest tutaj zamieszczona na rysunku faktura.

Rysunek 4 Faktura składająca się z elementów różnych typów - źródło [7]

Sprzedając towary na całym świecie wysyłamy faktury do wielu krajów. Część dokumentu będzie niezmienna bez względu na kraj adresata - numer faktury, data i miejsce wystawienia. Jednak pola adresu będą się różniły w zależności od kraju przeznaczenia. Na przykład Polska i Stany Zjednoczone stosują zupełnie różną strukturę określającą adres pocztowy. Jeśli chcielibyśmy stworzyć odpowiednie DTD przewidujące każdą taką kombinację, dokument XML opisujący fakturę stałby się bardzo skomplikowany [7].

Rozwiązaniem tej i innych niedoskonałości DTD są nowy język opisu struktury dokumentu - XML Schema i przestrzenie nazw (ang. namespaces).

2. Schemat XML i XDR

Prace nad specyfikacją Schematu XML (ang. XML Schema) były prowadzone przez W3C od lutego 1998 roku. W chwili obecnej są one na ukończeniu i formalny dokument doczekał się statusu kandydata do rekomendacji (ang. Candidate Recommendation) [17][18][19]. Grupa robocza skupiła się na trzech aspektach mających na celu poprawę w stosunku do DTD: [7]

• Schematy mają być pisane z wykorzystaniem składni języka XML.

• Nowy standard ma wspierać zarówno wszystkie elementarne typy danych takie, jak liczby, czas i data, typy złożone, jak i typy definiowane przez użytkownika.

• Schemat XML ma być oparty o otwarty model zawartości dokumentu, tzn. ma umożliwiać wprowadzanie wielu definicji schematu dla jednego dokumentu XML, co pozwoli na bezproblemową realizację scenariusza z fakturą z poprzedniego przykładu.

Ponieważ jednak organizacja W3C nie ogłosiła jeszcze formatu Schematu XML formalną rekomendacją, a będący jednym z głównych tematów pracy BizTalk wykorzystuje schematy oparte o wcześniejszą specyfikację, w dalszej części będę się opierał o specyfikację znaną jako XML Data Reduced (XDR) [20][16].

XDR został oparty o przesłany do W3C przez firmy Microsft, DataChannel, ArborText oraz Inso dokument opisujący składnię schematów zwaną XML-Data [21]. XML-Data został później przyjęty jako jeden z elementów, na których bazuje specyfikacja Schematu XML. Obydwie specyfikacje, mimo, że różniące się składniowo, spełniają te same cele i mają zbieżną funkcjonalność. Microsoft zobowiązał się do zaimplementowania Schematu XML w BizTalk, kiedy tylko stanie się on formalną rekomendacją.

Przykładową specyfikację stworzoną w XDR oprzemy o dokument z poprzednich przykładów (patrz wydruk).

<?xml version=”1.0” encoding=”UTF-8” standalone=”yes” ?>

<BOOK>

<TITLE>Praca magisterska</TITLE>

<AUTHOR>Sebastian Zakłada</AUTHOR>

<CHAPTER PAGES=”20”>Rozdział 1</CHAPTER>

<TOTALPAGES>240</TOTALPAGES>

</BOOK>

Wydruk 13 Przykładowy dokument XML

Oto przykładowy schemat XDR opisujący powyższy dokument XML.

1. <?xml version="1.0"?>

2. <Schema name="BOOK"

3. xmlns="urn:schemas-microsoft-com:xml-data"

4. xmlns:d="urn:schemas-microsoft-com:datatypes">

5. <ElementType name="TOTALPAGES" content="textOnly" model="closed" d:type="int"></ElementType>

6. <ElementType name="TITLE" content="textOnly" model="closed" d:type="string"></ElementType>

7. <ElementType name="CHAPTER" content="textOnly" model="closed">

8. <AttributeType name="PAGES" d:type="int"></AttributeType>

9. <attribute type="PAGES" required="no"/>

10. </ElementType>

11. <ElementType name="BOOK" content="eltOnly" model="closed">

12. <element type="TITLE" maxOccurs="1" minOccurs="1"/>

13. <element type="AUTHOR" maxOccurs="1" minOccurs="1"/>

14. <element type="CHAPTER" maxOccurs="*" minOccurs="1"/>

15. <element type="TOTALPAGES" maxOccurs="*" minOccurs="0"/>

16. </ElementType>

17. <ElementType name="AUTHOR" content="textOnly" model="closed"

d:type="string"></ElementType>

18. </Schema>

Wydruk 14 Schemat XDR opisujący przykładowy dokument XML

Poniższa tabela zawiera opis tego schematu.

Numer linii	Opis
2	<Schema> jest elementem głównym dokumentu. Atrybut name określa nazwę schematu.
3-4	Specyfikacja XDR określa dwie przestrzenie nazw. Pierwsza opisuje strukturę dokumentu (schemas-microsoft-com:xml-data), a druga definiuje typy danych używane w schemacie (schemas-microsoft-com:datatypes).
5-17	Znacznik <ElementType> deklaruje element i określa jego zawartość.
5	Element <TOTALPAGES> jest znacznikiem mogącym zawierać tylko zawartość tekstową (content="textOnly") typu liczbowego int (d:type="int").
8-9	Element <CHAPTER> ma zadeklarowany jeden atrybut PAGES typu liczbowego int. Jest to atrybut opcjonalny (required="no").
11	<BOOK> jest znacznikiem mogącym zawierać tylko elementy (content="eltOnly"). Nie może zawierać innych elementów niż te zadeklarowane w liście elementów poniżej (model="closed").
12-15	Deklaracja elementów dozwolonych dla <BOOK>. Każdy element ma określoną wymaganą liczebność (maxOccurs, minOccurs). Część elementów została już dokładnie wyspecyfikowana powyżej (linie 5-10), część poniżej (w linii 17). Kolejność deklaracji elementów wewnątrz dokumentu XDR nie gra roli.

Tabela 3 Opis schematu XDR z wydruku 14

Dokładniejsze informacje na temat specyfikacji standardu XML Data Reduced zawierają publikacje [20][16].

Warto jeszcze krótko wspomnieć o narzędziach stworzonych w celu ułatwienia pracy ze schematami XML. Mimo spełnienia postulatu zrozumiałości dla człowieka i przejrzystości, duże schematy mogą być dość skomplikowane i trudne do ogarnięcia. Szczególnie osoby nie mające wyobraźni przestrzennej mogą mieć problemy z wyobrażeniem sobie hierarchicznej struktury dokumentu opisywanej przez schemat. Dlatego powstało i wciąż powstaje wiele narzędzi ułatwiających i znacznie przyspieszających pracę nad schematami. Nie będę ich opisywał funkcji, a jedynie wspomnę dwa z nich.

Pierwszym narzędziem jest stworzona przez firmę Extensibility, Inc. aplikacja XML Authority [22]. Umożliwia ona tworzenie schematów XML w sposób graficzny. Wykorzystując przyjazny dla użytkownika interfejs można dzięki temu narzędziu szybko zdefiniować hierarchiczną strukturę dokumentu, ustalić wszystkie niezbędne szczegóły i stworzyć plik XML zawierający pełen kod schematu. Umożliwia ono także zaimportowanie istniejącego schematu XML. [7]

Rysunek 5 XML Authority

Drugie narzędzie przedstawię dokładniej w dalszej części pracy [10.4.1.1]. Jest to będąca częścią produktu Microsoft BizTalk Server 2000 aplikacja o nazwie BizTalk Editor. Umożliwia ona między innymi tworzenie zwykłych schematów XDR jak i specyfikacji opartych na XDR, a przeznaczonych specjalnie dla BizTalk Server. Na rysunku przedstawiony jest zaimportowany do aplikacji dokument XDR, którego treść zawiera wydruk 14.

Rysunek 6 BizTalk Editor, część pakietu Microsoft BizTalk Server 2000

1. Transformacja dokumentów XML

XML został zaprojektowany do zastosowań w Internecie. Umożliwił opisanie zarówno logicznej (znaczeniowej) jak i fizycznej (dane) struktury dokumentu. Kolejnym aspektem było rozdzielenie danych od prezentacji. Dokumenty HTML zawierają mnóstwo często bardzo użytecznych danych. Jednak nie jest możliwe określenie ich znaczenia bez ingerencji człowieka. Dla komputera tekst opisujący prognozę pogody i np. faktura, sformatowane przy pomocy HTML nie różnią się znaczeniowo niczym, ponieważ za danymi nie podąża informacja o ich znaczeniu. XML umożliwia dokładne opisanie znaczenia danych przy jego pomocy opisanych. Jednak aby zaprezentować te dane w atrakcyjnej graficznie formie (na przykład na stronie WWW) niezbędny jest duży nakład programistyczny. Stworzenie aplikacji prezentującej dane pobierane z plików XML niewiele różni się od prezentacji danych pobieranych z baz danych takich, jak na przykład SQL Server czy DB2. Mimo, iż XML nie został stworzony jako następca HTML, to jednak umożliwienie prostej prezentacji danych opisanych przy jego pomocy było logiczną koniecznością. W tym celu w ramach W3C zawiązała się w 1998 roku grupa robocza, która stworzyła standard XSL - Rozszerzalny Język Arkuszy Styli (ang. Extensible Stylesheet Language) [24].

1. XSL

XSL - Rozszerzalny Język Arkuszy Styli to specyfikacja mająca na celu zdefiniować język służący do formatowania dokumentów XML do prezentacji. Jest to swoisty odpowiednik Kaskadowych Arkuszy Styli CSS (ang. Cascading Style Sheets). W chwili pisania tej pracy specyfikacja XSL miała status kandydata do rekomendacji [24].

Aby spełnić swoją rolę XSL przeprowadza dwie operacje: formatowanie i transformację dokumentów XML. Proces ten ilustruje rysunek:

Rysunek 7 Prezentacja dokumentu XML za pomocą XSL [7]

Formatowanie dokumentu XML przy pomocy XSL rozpoczyna się od odczytania dokumentu XML, czyli stworzenia drzewa źródłowego (1). Następnie drzewo jest poddawane transformacji z wykorzystaniem przygotowanego wcześniej arkusza styli XSL (2) tworząc w rezultacie kolejny dokument XML zwany drzewem wynikowym (3). Drzewo to zawiera wszystkie informacje niezbędne do opisania prezentacji dokumentu XML. W przykładzie elementowi zostało przypisane pogrubienie (ang. bold) i kolor czarny. Wciąż jednak mamy do czynienia ze składnią XML. Przetworzenie do konkretnego typu formatowania następuje dopiero na następnym etapie. Zaaplikowanie formatowania A powoduje powstanie dokumentu RTF (4), formatowanie B wygeneruje dokument HTML, a formatowanie C - książkę elektroniczną. Widać, jak bardzo elastycznym mechanizmem jest XSL. Stworzenie odpowiedniego dokumentu formatującego pozwala na wygenerowanie dokumentu w praktycznie dowolnym formacie. Zastosowany w przykładzie dokument XSL znajduje się na wydruku.

<xsl:template match=”CHAPTER”>

<fo:block font-style=”bold” color=”black”>

<xsl:apply-templates/>

</fo:block>

</xsl:template>

Wydruk 15 Przykładowy dokument XSL

Arkusz styli XSL składa się z jednego lub więcej szablonów (ang. template), które zawierają wzorce (ang. patterns). Szablon określa strukturę dokumentu wynikowego powstałego w efekcie przetworzenia wzorcowego dokumentu XML. Wzorce specyfikują elementy XML, do których zostanie przyłożone formatowanie określone w arkuszu XSL. W tym celu wykorzystywana jest technika dopasowywania wzorców (ang. pattern-matching), co czyni z XSL język deklaratywny.

Rozszerzalny Język Arkuszy Styli XSL ma ogromne możliwości formatowania dokumentów XML, szczegóły i pełna specyfikacja języka znajduje się w dokumentacji udostępnianej przez organizację W3C [24].

2. XSLT

Możliwość transformacji dokumentów XML do różnych postaci udostępniana przez XSL okazała się być bardzo przydatnym i potężnym narzędziem. Jego użyteczność okazała się tak duża, że grupa robocza W3C XSL wyodrębniła ze specyfikacji języka część odpowiedzialną za transformację i stworzyła rekomendację XSLT - Rozszerzalnego Języka Arkuszy Styli do Transformacji (ang. Extensible Stylesheet Language for Transformations) [23]. W czasie pisania tej pracy W3C ogłosiła również dwa dokumenty będące zwiastunem kolejnych wersji i dowodzące dynamicznego rozwoju standardu: „XSLT 1.1 Working Draft” oraz „XSLT 2.0 Requirements Working Draft”.

XSLT jest opartym na regułach (ang. rules-based) zorientowanym na zdarzenia (ang. event-driven) językiem programowania umożliwiającym dowolne przekształcanie dokumentów XML [7]. Możliwości jakie ze sobą niesie są wyjątkowo ważne podczas tworzenia systemów realizujących funkcjonalność systemów typu Biznes-Do-Biznesu (ang. Business-To-Business, w skrócie B2B). Łatwo można sobie wyobrazić sytuację, w której dwie duże firmy pragną usprawnić swoje kontakty handlowe tworząc system informatyczny umożliwiający automatyczną wymianę dokumentów księgowych takich, jak faktury. Obydwie firmy posiadają własny komputerowy system księgowy, obydwa potrafią stworzyć fakturę w formacie XML, jednak struktura logiczna tych dokumentów znacznie się różni między sobą. W takim przypadku z pomocą przychodzi XSLT, umożliwiając automatyczną konwersję pomiędzy niezgodnymi formatami dokumentów XML. O transformacjach tego typu zostanie powiedziane dużo więcej, w sekcji opisującej inicjatywę BizTalk (patrz rozdział 6).

Przedstawienie całej specyfikacji języka XSLT jest bezcelowe, ponieważ dużo lepiej zadanie to realizuje oficjalna rekomendacja W3C [23]. Aby jednak przybliżyć mechanizm transformacji przedstawię krótki przykład.

Przypuśćmy, że mamy dwa dokumenty XML o strukturze przedstawionej na rysunkach.

Rysunek 8 Struktura dokumentu źródłowego

Rysunek 9 Struktura dokumentu docelowego

Dokument źródłowy składa się z elementu głównego <BOOK> zawierającego element <CHAPTER>, który z kolei dopuszcza istnienie atrybutu liczbowego PAGES. Dokument docelowy różni się od niego w dwóch miejscach. Atrybut PAGES staje w nim się elementem <PAGES>, oraz dodany jest element numeryczny <TOTALPAGES> zawierający sumę wszystkich elementów <PAGES> w dokumencie. Oczywiście zaproponowane nazwy elementów mogły zostać równie dobrze zdefiniowane w języku polskim jako <KSIAZKA> czy <ROZDZIAL>, jednak ponieważ sama specyfikacja Schematu XML, przy pomocy której jest definiowana struktura dokumentu, opiera się na języku angielskim, taki język został również dla jednolitości przyjęty w nazewnictwie elementów.

Schematy opisujące dokładniej te dokumenty przedstawione są na wydrukach.

<?xml version="1.0"?>

<Schema name="BOOK" xmlns="urn:schemas-microsoft-com:xml-data" xmlns:d="urn:schemas-microsoft-com:datatypes">

<ElementType name="CHAPTER" content="textOnly" model="closed">

<AttributeType name="PAGES" d:type="int"></AttributeType>

<attribute type="PAGES" required="no"/>

</ElementType>

<ElementType name="BOOK" content="eltOnly" model="closed">

<element type="CHAPTER" maxOccurs="*" minOccurs="1"/>

</ElementType>

</Schema>

Wydruk 16 Schemat XDR dokumentu źródłowego

<?xml version="1.0"?>

<Schema name="BOOK" xmlns="urn:schemas-microsoft-com:xml-data" xmlns:d="urn:schemas-microsoft-com:datatypes">

<ElementType name="TOTALPAGES" content="textOnly" model="closed" d:type="int">

</ElementType>

<ElementType name="PAGES" content="textOnly" model="closed" d:type="int">

</ElementType>

<ElementType name="CHAPTER" content="eltOnly" model="closed">

<element type="PAGES" maxOccurs="1" minOccurs="0"/>

</ElementType>

<ElementType name="BOOK" content="eltOnly" model="closed">

<element type="CHAPTER" maxOccurs="*" minOccurs="1"/>

<element type="TOTALPAGES" maxOccurs="*" minOccurs="0"/>

</ElementType>

</Schema>

Wydruk 17 Schemat XDR dokumentu docelowego.

Przekształcenie dokumentów opisuje tabela:

Element źródłowy	Element docelowy
<CHAPTER>	<CHAPTER>
PAGES	<PAGES>
∑ PAGES	<TOTALPAGES>

Tabela 4 Przekształcenia pomiędzy elementami dokumentów

Kod XSLT dokonujący przekształcenia został wygenerowany przy pomocy programu Microsoft BizTalk Mapper, wchodzącego w skład pakietu Microsoft BizTalk 2000 (patrz rozdział 10).

1. <xsl:stylesheet xmlns:xsl='http://www.w3.org/1999/XSL/Transform' xmlns:msxsl='urn:schemas-microsoft-com:xslt' xmlns:var='urn:var' xmlns:user='urn:user' exclude-result-prefixes='msxsl var user' version='1.0'>

2. <xsl:output method='xml' omit-xml-declaration='yes' />

3. <xsl:template match='/'>

4. <xsl:apply-templates select='BOOK'/>

5. </xsl:template>

6. <xsl:template match='BOOK'>

7. <BOOK>

8. <TITLE><xsl:value-of select='TITLE/text()'/></TITLE>

9. <AUTHOR><xsl:value-of select='AUTHOR/text()'/></AUTHOR>

10. <xsl:for-each select='CHAPTER'>

11. <CHAPTER>

12. <PAGES><xsl:value-of select='@PAGES'/></PAGES>

13. </CHAPTER>

14. </xsl:for-each>

15. <xsl:variable name='var:v1' select='user:FctInitCumulativeSum(0)'/>

16. <xsl:for-each select='/BOOK/CHAPTER'>

17. <xsl:variable name='var:v2' select='user:FctAddToCumulativeSum(0,string(@PAGES))'/>

18. </xsl:for-each>

19. <xsl:variable name='var:v3' select='user:FctGetCumulativeSum(0)'/>

20. <TOTALPAGES><xsl:value-of select='$var:v3'/></TOTALPAGES>

21. </BOOK>

22. </xsl:template>

23. <msxsl:script language='VBScript' implements-prefix='user'>

24. <![CDATA[

25. Dim ArrCumulativeSum()

26. Dim CumSumArrayLength

27.

28. CumSumArrayLength = 0

30.

31. Function FctGetCumulativeSum( Index )

32. FctGetCumulativeSum = ArrCumulativeSum( Index )

33. End Function

34.

35. Function FctInitCumulativeSum( Index )

36. If CumSumArrayLength <= Index Then

37. CumSumArrayLength = CumSumArrayLength + 1

38. Redim Preserve ArrCumulativeSum( CumSumArrayLength )

39. End If

40. ArrCumulativeSum( Index ) = ""

41. FctInitCumulativeSum = ""

42. End Function

43.

44. Function FctAddToCumulativeSum( Index, Value )

45. If IsNumeric( Value ) Then

46. If ArrCumulativeSum( Index ) = "" Then

47. ArrCumulativeSum( Index ) = CDbl( Value )

48. Else

49. ArrCumulativeSum( Index ) = ArrCumulativeSum( Index ) + 50.CDbl( Value )

51. End If

52. End If

53. FctAddToCumulativeSum = ArrCumulativeSum( Index )

54. End Function

55.

56. ]]>

57. </msxsl:script>

58. </xsl:stylesheet>

Wydruk 18 Kod XSLT transformujący dokumenty

Opis kodu zawiera poniższa tabela.

Numer linii	Opis
1	Wykorzystano oficjalną rekomendację W3C z listopada 1999 roku (xmlns:xsl='http://www.w3.org/1999/XSL/Transform'), jak również rozszerzenie XSLT wprowadzone przez firmę Microsoft (urn:schemas-microsoft-com:xslt).
2	Element xsl:output określa typ dokumentu, z jakim ma być zgodny dokument wynikowy. W tym przypadku jest to dokument XML.
3-5	Elementem głównym dokumentu źródłowego jest <BOOK>.
6	Najpierw przetwarzamy element <BOOK>.
8-9	Element xsl:value-of powoduje wstawienie treści określonych przez select. W tym wypadku jest to zawartość odpowiednich znaczników dokumentu źródłowego.
10-14	Element xsl:for-each tworzy i przetwarza kolekcję elementów określonych przez select, w tym wypadku <CHAPTER>.
15-18	Do zdefiniowanej zmiennej var:v2 podstawiany jest wynik wywołania funkcji user:FctGetCumulativeSum zdefiniowanej użytkownika. Sumuje ona zawartość wszystkich elementów <PAGES>.
20	Zawartością znacznika <TOTALPAGES> jest zawartość zmiennej var:v3.
23-57	Jest to skrypt definiujący funkcje użytkownika. Specyfikacja XSLT nie zawiera opisu silnika skryptowego. Implementacja standardu dokonana przez firmę Microsoft zawiera rozszerzenie umożliwiające pisanie skryptów w jednym ze standardowych języków skryptowych takich, jak VBScript czy Microsoft JScript. Zdefiniowane w tym bloku kodu funkcje umożliwiają zsumowanie zawartości wszystkich elementów <PAGES>.

Tabela 5 Opis kodu XSLT linia po linii.

Oto przykład zastosowania transformacji do dokumentu:

<BOOK>

<CHAPTER PAGES=”11”/>

<CHAPTER PAGES=”11”/>

</BOOK>

Wydruk 19 Przykład zastosowania transformacji XSLT - dokument źródłowy

<BOOK>

<CHAPTER>

<PAGES>11</PAGES>

</CHAPTER>

<CHAPTER>

<PAGES>11</PAGES>

</CHAPTER>

<TOTALPAGES>22</TOTALPAGES>

</BOOK>

Wydruk 20 Przykład zastosowania transformacji XSLT - dokument wynikowy

Jak widać, transformacja została przeprowadzona prawidłowo i zgodnie ze zdefiniowanym szablonem.

Oczywiście, podobnie, jak w przypadku schematów XML także w tym przypadku istnieje i wciąż powstaje wiele narzędzi pomocnych w tworzeniu transformacji XSLT. Najlepszym obecnie narzędziem służącym do tego celu jest będąca częścią pakietu Microsoft BizTalk Server 2000 aplikacja Microsoft BizTalk Mapper, która zostanie przedstawiona dokładniej w dalszej części pracy (patrz rozdział 10.4.1.2). Poniższy rysunek przedstawia aplikację ze zdefiniowaną transformacją opisaną we wcześniejszym przykładzie.

Rysunek 10 Microsoft BizTalk Mapper, część pakietu Microsoft BizTalk Server 2000

2. Standardy towarzyszące

W celu jeszcze większego poszerzenia możliwości języka XML jest opracowywanych szereg standardów towarzyszących. Oto te najważniejsze z punktu widzenia wykorzystywania w BizTalk.

1. Przestrzenie nazw

Termin przestrzeni nazw (ang. namespace) jest często spotykanym określeniem informatycznym, określającym obszar, w którym nie mogą istnieć dwa byty o takich samych nazwach. Możemy to porównać z określaniem zakresu (ang. scope) ważności zmiennych w językach programowania takich, jak na przykład C++. Specyfikacja tego języka określa, że w bloku kodu mającym ten sam zakres może się znajdować tylko jedna zmienna o danej nazwie. Jeśli jednak w zewnętrznym bloku kodu została zdefiniowana zmienna globalna o takiej samej nazwie, w zakresie obejmującym ponowną, lokalną deklarację, zmienna globalna jest przez lokalną „zasłaniana”.

W języku XML przestrzenie nazw pełnią dwie główne role: wprowadzają możliwość współdzielenia istniejących schematów i typów danych pomiędzy dokumentami oraz udostępniają środowisko umożliwiające współistnienie wielu schematów w jednym dokumencie [7], bez konieczności martwienia się o wystąpienie ewentualnego konfliktu nazw. Konflikty występują, gdy w jednym dokumencie znajdują się dwa lub więcej znaczniki o takiej samej nazwie, ale innym znaczeniu.

<?xml version=”1.0” encoding=”UTF-8” standalone=”yes” ?>

<BOOK>

<TITLE>Praca magisterska</TITLE>

<AUTHOR>

<TITLE>Mr.</TITLE>

<NAME>Sebastian Zakłada</NAME>

</AUTHOR>

<CHAPTER PAGES=”20”>Rozdział 1</CHAPTER>

<TOTALPAGES>240</TOTALPAGES>

</BOOK>

Wydruk 21 Ilustracja konfliktu nazw w dokumencie XML.

Wydruk przedstawia dokument XML, w którym występuje konflikt w stosunku do elementu <TITLE>. Występuje on dwukrotnie, przy czym raz określa tytuł książki <TITLE>Praca magisterska</TITLE>, a drugi raz tytuł grzecznościowy <TITLE>Mr.</TITLE>. Aby uniknąć takich i innych potencjalnych konfliktów, wystarczy wprowadzić dwie przestrzenie nazw.

<?xml version=”1.0” encoding=”UTF-8” standalone=”yes” ?>

<BOOK xmlns=”http://www.sebekz.getin.pl/schemas/book.xdr”

xmlns:person=”http://www.sebekz.getin.pl/schemas/person.xdr”>

<TITLE>Praca magisterska</TITLE>

<AUTHOR>

<person:TITLE>Mr.</person:TITLE>

<person:NAME>Sebastian Zakłada</person:NAME>

</AUTHOR>

<CHAPTER PAGES=”20”>Rozdział 1</CHAPTER>

<TOTALPAGES>240</TOTALPAGES>

</BOOK>

Wydruk 22 Rozwiązanie konfliktu nazw poprzez wprowadzenie przestrzeni nazw.

Wszystkie elementy dokumentu z wydruku są zdefiniowane w schemacie book.xdr, który jest wymieniony w deklaracji domyślnej przestrzeni nazw dla dokumentu. Jedynie elementy <TITLE> oraz <NAME> opisujące autora są definiowane przez podaną explicite przestrzeń nazw xmlns:person.

Więcej na temat przestrzeni nazw można odnaleźć w oficjalnej rekomendacji W3C [25], ponieważ tak, jak w przypadku specyfikacji języka XML czy też schematów XML, organizacja ta zajmuje się rozwojem tego standardu.

2. XLink, XPointer

Pozostałe rekomendacje związane z językiem XML służą do tworzenia odnośników wewnątrz dokumentu XML. XLink [26] udostępnia funkcjonalność podobną do elementu <A> w języku HTML, jednak z pewnymi ulepszeniami. Oprócz możliwości tworzenia wewnątrz jednego dokumentu XML odnośników do innych dokumentów XML, XLink spełnia funkcję podobną do dyrektywy #include z języka C, pozwalając na dołączanie treści zewnętrznych dokumentów. XPointer [27] rozszerza funkcjonalność standardu XLink jeszcze bardziej, umożliwiając wskazywanie fragmentów zewnętrznych dokumentów. Daje to możliwość odniesienia się, na przykład w przypadku dokumentu zawierającego treść książki, tylko do drugiego paragrafu zawartego wewnątrz określonego rozdziału.

• Procesory języka XML

Analiza składni i przetwarzanie dokumentu XML jest czynnością dosyć złożoną. Gdy dołożymy do tego możliwość skorzystania ze wszystkich standardów uzupełniających możliwości XML takich, jak schematy XML, przestrzenie nazw czy też XSL otrzymujemy całkiem poważne zadanie programistyczne. Na szczęście tak, jak dla innych języków, tak i w tym przypadku istnieją narzędzia, które pomagają nam wykorzystać możliwości, jakie udostępnia nam XML, na dalszy plan spychając problemy implementacji poszczególnych standardów W3C. Procesory języka XML istniejące na rynku różnią się pomiędzy sobą możliwościami i wiernością w implementacji zaleceń konsorcjum W3C, jednak z punktu widzenia tematu pracy idealnym narzędziem, realizującym wszystkie wymagania jest procesor języka XML stworzony przez Microsoft.

1. MSXML 3.0 Parser

Korporacja Microsoft udostępnia bezpłatnie stworzony przez siebie procesor języka XML, który oprócz analizy składni udostępnia szereg innych możliwości, czyniących z niego bardzo użyteczne narzędzie programistyczne. Jedną z ciekawszych jest implementacja mechanizmu komunikacji z serwerami przy pomocy protokołu HTTP. Funkcjonalność ta bardzo upraszcza tworzenie prostych systemów zgodnych ze standardem BizTalk Server. Dzięki temu, że procesor MSXML został stworzony w oparciu o architekturę komponentową COM, w prosty sposób można wykorzystywać poszczególne jego elementy we własnych aplikacjach przetwarzających dane opisywane przy pomocy języka XML. Więcej informacji na temat tego produktu można uzyskać z dokumentacji dostępnej po jego zainstalowaniu, oraz ze stron producenta [29].

MSXML Parser w wersji 3.0 jest w pełni zgodny z obowiązującymi rekomendacjami W3C i jest rekomendowany do tworzenia implementacji opartych o specyfikację BizTalk. BizTalk Server 2000 wykorzystuje parser MSXML 3.0 do wykonywania większości operacji związanych z przetwarzaniem dokumentów XML.

Część II: BizTalk - otwarty standard systemów biznesowych

• Systemy biznesowe dawniej i dzisiaj

Od dawna ludzie prowadzą ze sobą interesy - od handlu wymiennego, przez pojawienie się walut, aż po pełną komercjalizację handlu. W dzisiejszych czasach biznes prowadzi się na wielką skalę. Jednak im większa skala przedsięwzięcia, tym większe komplikacje. Zastanówmy się, jak najczęściej przebiega jeden z podstawowych procesów biznesowych, jakim jest zawieranie i realizacja umowy kupna-sprzedaży.

W przykładzie wezmą udział dwie modelowe instytucje: produkująca instrumenty muzyczne korporacja „Gitary Świata”, oraz zajmująca się pozyskiwaniem i sezonowaniem wysokogatunkowego drewna egzotycznego spółka „Drewniane Marzenia”. Aby wyprodukować nową partię gitar basowych firma „Gitary Świata” musi między innymi mieć dostęp do sezonowanego drewna egzotycznego. Osoba odpowiedzialna za utrzymanie odpowiednich zapasów półproduktów niezbędnych do utrzymania ciągłości produkcji stwierdza, że w celu wyprodukowania partii gitar musi zamówić w oddalonej o 300 kilometrów spółce „Drewniane Marzenia” dwa kontenery drewna wenge. Zgodnie z wewnętrzną, firmową procedurą składania zamówień pracownik wypełnia więc odpowiednie formularze i udaje się z nimi do kierownika działu, gdzie składa je do akceptacji. Ponieważ kierownik jest bardzo zajętym człowiekiem, o dokumentach na biurku przypomina sobie dopiero po pewnym czasie i sprawą zamówienia drewna zajmuje się po trzech dniach od wpłynięcia zapotrzebowania. Opiniuje ją pozytywnie i zamówienie na odpowiednią partię wenge zostaje wysłane pocztą. Po dwóch dniach poczta dociera do „Drewnianych Marzeń”, gdzie po odpowiednim posortowaniu zostaje skierowana do działu sprzedaży. Zajmuje to kolejny dzień. Dział sprzedaży zna już „Gitary Świata”, ponieważ firma ta zamawiała już duże partie drewna, wysyła więc odpowiednie zlecenie przygotowania dostawy do magazynu, a potwierdzenie przyjęcia zamówienia i fakturę pocztą do „Gitar Świata”, gdzie dociera ona po dwóch dniach. Potwierdzenie zamówienia zostaje dostarczone kierownikowi działu, który z kolei przekazuje je zamawiającemu drewno pracownikowi, natomiast faktura trafia do działu finansowego. Tam wydatek oczekuje w kolejce na zatwierdzenie. W momencie zatwierdzenia płatność wysyłana jest na konto „Drewnianych Marzeń”, a potwierdzenie przelewu zostaje przesłane faksem. Odebrane u dostawcy jest wystarczającą podstawą do uruchomienia procedury przesyłki drewna, przy czym termin i sposób dostawy zostaje przekazany do „Gitar Świata” telefonicznie. Transakcja dochodzi do skutku.

Wiele firm, zarówno małych, jak i całkiem dużych posługuje się na co dzień podobnym scenariuszem. Jednak jeden fakt jest jednak uderzający - czas uzgadniania samej transakcji wynosi prawie dwa tygodnie, a sam proces jest bardzo zawodny (przesyłka może zaginąć, pracownik zapomnieć o dokumentach itp.) i absorbujący zasoby ludzkie, jak również wyjątkowo trudny do śledzenia.

1. Integracja aplikacji (A2A)

Kolejny problem pojawia się w momencie, gdy rozumujemy w kontekście dzisiejszych spółek. W znacznej większości są one zinformatyzowane i korzystają z różnych systemów komputerowych, czy to finansowo-księgowych, czy magazynowych, czy nawet służących automatyzacji wewnętrznych procesów biznesowych. W zależności od stażu na rynku, systemy te mogą być wielorakiego typu - możemy spotkać oparte na komputerach klasy mainframe systemy spadkowe (ang. legacy systems), aplikacje zbudowane na różnych platformach (UNIX, OS/2, Windows itp.), czy też instalacje wykorzystujące wiele typów sieci lokalnych (Novell, Microsoft itp.). Wykorzystywane systemy mogą być zbudowane przez wewnętrzny dział informatyki, lub też reprezentować jedną z wielu możliwych opcji rynkowych, jak na przykład systemy finansowo-księgowe SAP, czy też Dynamics firmy Great Planes. Z biegiem czasu wymagania rynkowe się zmieniają, rośnie ilość wykorzystywanych aplikacji i jednocześnie maleje ich zdolność do współpracy. Staje się ona niemożliwa do tego stopnia, że aby zrealizować wymagany przez konkretny proces biznesowy przepływ informacji, dokumenty są przepisywane ręcznie z jednego systemu do drugiego. Komputery zamiast pomagać, stają się coraz większym balastem, przy czym koszt i skala unifikacji całej platformy informatycznej wewnątrz dużego przedsiębiorstwa praktyczne uniemożliwia przeprowadzenie takiego procesu.

Integracja aplikacji, zwana też komunikacją Aplikacja-Aplikacja (ang. Application-To-Application, w skrócie A2A) ma na szczęście optymalne rozwiązanie informatyczne. Tworząc odpowiednie konektory, czyli aplikacje wspomagające, które umożliwiają przetłumaczenie danych wygenerowanych przez jedną aplikację na dane w formacie zrozumiałym dla drugiej aplikacji, jesteśmy w stanie częściowo przywrócić jednorodność wewnętrznego, firmowego systemu informatycznego. Jednak proces tłumaczenia danych - zwany inaczej odwzorowaniem danych (ang. data mapping) - jest często skomplikowany i wymaga dużej wiedzy na temat obydwu łączonych aplikacji oraz platform, na jakich one pracują. Oznacza to przede wszystkim wysokie koszty realizacji i utrzymania takiego rozwiązania, a poza tym wyjątkowo długi czas realizacji. A więc z punktu widzenia biznesu -nie może być ono uznane za perspektywiczne.

Przykład prostej integracji Aplikacja-Aplikacja przedstawia rysunek poniżej.

Rysunek 11 Przykład integracji A2A.

System sprzedaży detalicznej w jednej organizacji wysyła dokument w formacie pliku tekstowego o stałej szerokości do aplikacji opartej na systemie finansowym firmy SAP w drugiej organizacji. Aplikacja B oczekuje danych w zrozumiałym przez siebie formacie SAP IDOC, wobec tego nie może bezpośrednio zaakceptować dokumentu w formacie proponowanym przez aplikację A. W celu umożliwienia interakcji pomiędzy tymi aplikacjami został wprowadzony pośredniczący pomiędzy nimi proces odwzorowania danych, który transformuje dokument w formacie wysyłanym przez aplikację A do formatu zrozumiałego przez aplikację B.

2. Systemy Biznes-Biznes (B2B)

Dążąc do maksymalnej integracji systemów informatycznych, oraz do możliwie największego zautomatyzowania procesów biznesowych pomiędzy instytucjami, dochodzimy do koncepcji bezpośredniej komunikacji aplikacji należących do różnych, całkowicie od siebie niezależnych firm. Proces taki nazywamy komunikacją Biznes-Biznes (ang. Business-To-Business, w skrócie B2B), a rozwiązania informatyczne go realizujące systemami Biznes-Biznes (w skrócie systemami B2B). Realizacja scenariusza takiej komunikacji niesie ze sobą wiele dodatkowych trudności (patrz tabela).

Problem	Integracja A2A	Integracja B2B
Lokalizacja geograficzna	W obrębie jednej lokalizacji, najczęściej w ramach tej samej sieci lokalnej.	Organizacje mogą być oddalone od siebie o tysiące kilometrów, połączone najczęściej poprzez publiczną sieć Internet.
Wdrożone rozwiązania informatyczne	Dobrze znane i sprawdzone.	Rozwiązania drugiej organizacji są bardzo słabo znane i niewiele o nich wiemy.
Możliwość wprowadzania zmian w istniejących systemach	Ograniczona, ale możliwa.	Praktycznie niemożliwe jest uzyskanie porozumienia co do zmian w istniejących systemach - organizacje kooperują najczęściej z wieloma parterami i tego typu zmiany by się wzajemnie wykluczały.
Uniwersalność integracji	Ograniczona - integrujemy znane, konkretne aplikacje.	Kluczowa - nigdy nie można przewidzieć, z jaką organizacją przyjdzie nam w danej chwili współpracować.
Kwestie bezpieczeństwa	Łatwe do uzyskania dzięki komunikacji w ramach sieci lokalnych organizacji.	Trudne do uzyskania i bardzo istotne z powodu wykorzystania publicznej sieci Internet.
Kwestia zaufania	Łatwe do uzyskania wewnątrz organizacji. Komunikacja wewnątrz sieci lokalnych.	Trudne do uzyskania pomiędzy organizacjami. Komunikacja poza sieciami lokalnymi, poprzez systemy zabezpieczeń (np. ściany ogniowe - ang. firewall). Możliwe zastosowanie wirtualnych sieci prywatnych (VPN).
Metody przesyłania danych	Ściśle określone, łatwe do identyfikacji dzięki pełnej wiedzy na temat przedmiotu integracji.	Trzeba przewidzieć możliwie wiele metod transportu biorąc pod uwagę możliwości trasowania i przechodzenia przez systemy zabezpieczeń.
Administracja	Scentralizowana. Rozwiązanie łatwe w zarządzaniu i śledzeniu.	Rozproszona. Trudno zaimplementować rozwiązanie łatwe w zarządzaniu i śledzeniu.

Tabela 6 Różnice pomiędzy implementacjami systemów A2A i B2B.

Trudności te powodują, że koszty rozwiązania Biznes-Biznes rosną jeszcze bardziej, niż w przypadku integracji aplikacji Aplikacja-Aplikacja. Jak widać na rysunku, proces odwzorowania trzeba przeprowadzać co najmniej dwukrotnie - raz przed wysłaniem danych, tłumacząc format Aplikacji A na ogólny format wymiany danych, który jest zrozumiały dla obydwu organizacji, a drugi raz przed przesłaniem odebranego dokumentu do aplikacji B. Jeśli dołożymy do tego konieczność bardzo ścisłej współpracy podczas przygotowywania całego rozwiązania, oraz potrzebę zachowania bezpieczeństwa, łatwości administracji i śledzenia procesu oraz pozostałe przeszkody wymienione w tabeli powyżej, wniosek może być tylko jeden - przygotowanie całego systemu integracji Biznes-Biznes dwóch organizacji przekracza możliwości większości nie tylko średnich, ale przede wszystkim dużych firm i instytucji. Dlatego też powstała konieczność przygotowania standardu, który mógłby znacznie uprościć i zmniejszyć koszty przygotowywania systemów integracji biznesowej. Przykład prostej integracji Biznes-Biznes przedstawia poniższy rysunek:

Rysunek 12 Integracja systemów Biznes-Biznes (B2B).

Przykład ten jest podobny do przedstawionego przy okazji opisywania integracji typu A2A. Różni się jednak kilkoma istotnymi szczegółami. Po pierwsze - współpracujące organizacje są wyraźnie od siebie oddzielone, systemy w nich zainstalowane funkcjonują niezależnie, w osobnych instalacjach sieciowych, być może również w innych lokalizacjach geograficznych. Cała komunikacja pomiędzy nimi odbywa się przy pomocy stworzonej wirtualnej sieci prywatnej VPN (ang. Virtual Private Network), stanowiącej bezpieczny, korzystający z ogólnodostępnej sieci Internet kanał łączący odległe organizacje. Dane wymieniane przy pomocy tego połączenia nie mają formatu specyficznego dla żadnej ze współpracujących organizacji, są odwzorowane do uzgodnionego ogólnego formatu wymiany danych. Transformacja do i z formatu zrozumiałego przez konkretną organizację następuje na styku z zestawionym kanałem transmisyjnym.

3. Wymiana Danych Elektronicznych (EDI)

Wymiana Danych Elektronicznych, czyli EDI (ang. Electronic Data Interchange) to najpopularniejszy obecnie standard elektronicznej wymiany danych biznesowych. Wykorzystując standardowy format danych udostępnia metody wymiany dokumentów pomiędzy organizacjami. Wśród dokumentów możliwych do przesyłania przy pomocy EDI znajdują się między innymi zlecenia sprzedaży, faktury, zapytania ofertowe, potwierdzenia, cenniki, płatności itp. Większość dokumentów biznesowych wymienianych w formie papierowych może być wspierana przez EDI. Podstawowa lista dokumentów EDI znajduje się w [33].

Dwoma podstawowymi standardami opartymi na specyfikacji EDI są

• ANSI X12 - wykorzystywane głównie w Stanach Zjednoczonych

• EDIFACT - (ang. Electronic Data Interchange for Administration, Commerce and Transport - Wymiana Danych Elektronicznych dla Administracji, Handlu i Transportu) wykorzystywane w Europie i Azji, przyjęte w 1987 roku przez ISO jako globalny, uniwersalny standard EDI

Dostępność do rozwiązań opartych o EDI jest szeroka. Mechanizmy translacyjne EDI i oprogramowanie komunikacyjne jest dostępne dla większości typów komputerów, zarówno typu PC, jak i dużych instalacji mainframe. Rola poszczególnych mechanizmów jest prosta - translacja odpowiada za tłumaczenie dokumentów biznesowych do znormalizowanego, zgodnego z X12 lub EDIFACT formatu, a oprogramowanie komunikacyjne za wysyłkę i odbieranie tak przygotowanych dokumentów. Mechanizm jest bardzo podobny do przedstawionego na Rysunek 12, jednak dzięki znormalizowaniu formatu wymienianych dokumentów, oraz dostępności oprogramowania ułatwiającego implementację kompleksowego rozwiązania informatycznego, znacznie skrócono czas realizacji oraz koszty z tym związane.

Jednak EDI ma również wady. Najpoważniejszą z nich jest trudność w dostosowywaniu stworzonych na potrzeby EDI standardowych formatów dokumentów do tych stosowanych w firmie. A ponieważ tworząc je starano się, aby były odpowiednio uniwersalne, stały się one jednocześnie bardzo skomplikowane i trudne w implementacji. Z tego powodu powstały podgrupy tworzące standardy skierowane specjalnie na potrzeby konkretnej branży przemysłu - na przykład bankowości, rynku samochodowego itp. - co z kolei zaowocowało rozrostem dostępnych formatów dokumentów i komunikacja pomiędzy jednostkami spoza grupy branżowej znacznie się skomplikowała. Drugą istotną wadą jest wiekowość rozwiązania - EDI zostało stworzone w późnych latach siedemdziesiątych, zanim jeszcze nadeszła era Internetu, więc nie wykorzystuje w pełni jego możliwości. Oparte o archaiczną Sieć z Wartością Dodaną VAN (ang. Value Added Network) metody transportu generują dodatkowe koszty i problemy implementacyjne. Sieci VAN pełnią rolę „skrzynek pocztowych” dla danych przekazywanych podczas interakcji EDI. Zamiast łączyć się bezpośrednio, współpracujący partnerzy uzgadniają VAN, z którego będą korzystać i przy jego pomocy przekazują dokumenty biorące udział w interakcji. Biorąc dodatkowo pod uwagę fakt, że same serwery EDI są przeważnie bardzo drogie nie dziwi, że mimo iż EDI jest już na rynku od prawie czterdziestu lat, jego obecność nie wywołała masowej eksplozji w integracji systemów biznesowych [15].

Więcej informacji na temat EDI można uzyskać w literaturze oraz w Internecie [30][31][32][33][34][35][36].

• Inicjatywa BizTalk

Prezentowane dotychczas rozwiązania problemu integracji systemów biznesowych były obarczone bagażem wieku. Mimo, iż wprowadzenie EDI było przełomem w globalnej informatyzacji procesów biznesowych, to jednak w szybko zmieniającym się świecie biznesu, potrzeby rosły bardzo szybko i wyeksploatowany, nie pozbawiony wad standard przestał być wystarczający.

W momencie pojawienia się XML zaczęto się zastanawiać nad możliwością stworzenia standardu systemów Biznes-Biznes, który skorzystał by z udostępnianych przez niego ogromnych możliwości. Kilka grup równolegle prowadziło prace nad odpowiednią specyfikacją, jednak w pewnym okresie największe organizacje opinio- oraz standardotwórcze zgromadziły się wokół inicjatywy, która przyjęła nazwę BizTalk (skrót od angielskiego Biznes Talk - rozmowy biznesowe). Praca wykonana przez tą grupę spowodowała, iż wizja prawdziwej integracji i komunikacji pomiędzy systemami biznesowymi stała się realna.

Hasłem przewodnim i jednocześnie misją inicjatywy jest:

Zautomatyzować aranżację procesów biznesowych wykorzystując standardowe protokoły i formaty Internetu, a poprzez łączenie wewnętrznych i zewnętrznych procesów biznesowych spowodować powstanie społeczności biznesowych.

Najistotniejszymi punktami tego hasła są dwa słowa: aranżacja oraz standardowe. Ogromny wachlarz możliwości udostępnianych przez aranżację procesów biznesowych oraz samo pojęcie aranżacji wyjaśniam w dalszej części pracy [9], natomiast istota wykorzystania standardów wymaga rozszerzenia.

W latach siedemdziesiątych informatyzacja przedsiębiorstw nie była jeszcze powszechna. Wprowadzenie i wypromowanie nowego standardu było wtedy dużo prostsze, niż obecnie, ponieważ nowoczesna technologia dopiero się rozwijała i nowe propozycje były przyjmowane „z otwartymi rękoma”. Dzisiaj sytuacja się zmieniła. Wystarczy sobie wyobrazić, że wdrożenie nawet najwspanialszego rozwiązania Biznes-Biznes wymagało by całkowitego przebudowania istniejących struktur wewnątrz firmy, czy to w zakresie procesów biznesowych, czy też rozwiązań informatycznych. Poza tym wykorzystane przez inicjatywę BizTalk standardy istnieją już od pewnego czasu na rynku i zostały przezeń zaakceptowane. Nikt nie zaneguje wykorzystania jako mechanizmu transportowego protokołu HTTP czy też SMTP. Również XML został szeroko zaakceptowany, a ponieważ panuje teraz swoista „moda” na rozwiązania zeń korzystające, oparcie na nim nowego pomysłu na integrację między systemami ma również istotny wymiar marketingowy. Co więcej, dzięki zastosowaniu szeroko wykorzystywanych standardów komunikacja z istniejącymi systemami staje się dużo prostsza. Istnieje bowiem duże prawdopodobieństwo, że można się z nimi porozumieć przy pomocy jednego ze znanych protokołów.

1. BizTalk.org

BizTalk.org [38] jest internetowym portalem informacyjnym, w którym można znaleźć informacje na temat wymiany danych przy pomocy XML, a w szczególności zastosowań opartych na BizTalk. Nadzorowany przez komitet zarządzający BizTalk, w skład którego wchodzą między innymi Microsoft, Ariba, Boeing, Compaq, Dell, SAP, czy też UPS, skupia wokół siebie całą społeczność korzystającą z rozwiązań opartych na BizTalk. Jest to także pierwsza na świecie otwarta, czyli dostępna dla wszystkich biblioteka biznesowych schematów XML opisujących format dokumentów wykorzystywanych przez firmy z różnych działów przemysłu. Istotny jest tutaj fakt, że wszystkie schematy znajdujące się w zasobach biblioteki są wcześniej sprawdzone pod względem formalnej poprawności, jak również poddawane oznaczaniu kolejnych wersji (ang. versioning). Uczestnictwo w społeczności BizTalk.org jest bezpłatne, każdy może skorzystać z jej zasobów. Ponieważ jedną z głównych misji społeczności jest propagowanie wiedzy, odnalezione w bibliotece BizTalk.org schematy i wskazówki można również wykorzystać jako bazę do stworzenia własnych definicji dokumentów, które również można umieścić w jej zasobach. Na stronach odnajdziemy również najnowsze wieści dotyczące zarówno BizTalk, jak i XML, a także listy dyskusyjne na temat BizTalk i XML. Poniższy rysunek przedstawia pierwszą stronę portalu BizTalk.org.

Rysunek 13 www.biztalk.org

• Prosty Protokół Dostępu do Obiektów (SOAP)

Komunikacja pomiędzy systemami, odbywająca się w środowisku zdecentralizowanym, wymaga określenia ścisłych reguł dotyczących zarówno formatu, jak i reguł przetwarzania przesyłanych wiadomości. Istotne jest także opracowanie metod zdalnego dostępu do zewnętrznych interfejsów współpracujących systemów tak, aby nie naruszyć istniejących reguł bezpieczeństwa w nich wdrożonych. Ponieważ komunikacja odbywać się będzie poprzez sieć Internet, opracowana metoda musi pozwalać na bezproblemowe przechodzenie przez systemy bezpieczeństwa sieci lokalnych takie, jak ściany ogniowe (ang. firewall).

Prosty Protokół Dostępu do Obiektów SOAP (ang. Simple Object Access Protocol) umożliwia wymianę informacji poprzez sieć Internet w rozproszonych, zdecentralizowanych środowiskach. Jest oparty na języku XML i określa reguły tworzenia, kodowania i przetwarzania wiadomości, a także metody zdalnego wywoływania metod obiektów. Dzięki zastosowaniu jako głównego protokołu transportowego Protokołu Transportu Informacji Hipertekstowej HTTP, wiadomości SOAP zostaną zaakceptowane przez większość wchodzących w skład systemów bezpieczeństwa ścian ogniowych firewall. Specyfikacja Prostego Protokołu Dostępu do Obiektów SOAP, utrzymywana i rozwijana przez organizację standaryzacyjną W3C, dopuszcza jednak zastosowanie dowolnego mechanizmu transportowego [6].

Specyfikacja jest trzyczęściowa i składają się na nią:

• koperta SOAP (ang. SOAP envelope) - definiująca główny szkielet wiadomości, określający jej format i dozwoloną treść

• reguły kodowania SOAP (ang. SOAP encoding rules) - pozwalające określić mechanizmy wykorzystywane przy wymianie specyficznych, zdefiniowanych na poziomie współpracujących aplikacji typów danych

• zdalne wywołanie procedury SOAP (ang. SOAP Remote Procedure Call) - określające mechanizmy wprowadzone w celu umożliwienia implementacji zdalnego wywoływania procedur przez Internet

Prosty Protokół Dostępu do Obiektów SOAP stanowi bazę metod wymiany informacji w modelu aplikacyjnym BizTalk, więcej informacji na ten temat zawiera rozdział 8.

1. SOAP jako protokół zdalnego wywoływania procedur

Istniejące do tej pory propozycje metod zdalnego wywoływania procedur takie, jak Rozproszony Komponentowy Model Obiektowy DCOM (ang. Distributed Component Object Model), Zdalne Wywoływanie Procedury RPC (ang. Remote Procedure Call) w języku Java, czy też Architektura Uniwersalnego Pośrednika Żądania Obiektu CORBA (ang. Common Object Request Broker Architecture) są specyfikacjami bardzo mocno zależnymi od platform, na których działają, i jako takie nie nadają się do komunikacji w zdecentralizowanych, heterogenicznych systemach rozproszonych. Prosty Protokół Dostępu do Obiektów SOAP jest oparty o XML i tak jak ten język, bardzo dobrze nadaje się do przesyłania danych pomiędzy różnymi platformami, w szczególności do zdalnego wywoływania metod w środowiskach heterogenicznych.

Zdalne wywołanie procedury SOAP umożliwia współdziałanie heterogenicznych komponentów przez sieć Internet. Udostępnia otwartą, rozszerzalną metodę komunikacji bez względu na system operacyjny, model obiektowy, czy też język implementacji konkretnej aplikacji. Aplikacja klienta przesyła zakodowane przy pomocy języka XML zlecenie wywołania metody komponentu, które odebrane przez serwer SOAP jest zamieniane w wywołanie lokalne, właściwe dla platformy. Dzięki zastosowaniu tego elementu pośredniczącego nie trzeba modyfikować istniejących komponentów, i przy pomocy Prostego Protokołu Dostępu do Obiektów SOAP możliwa jest komunikacja z dowolnym zdalnym obiektem. Wynik wykonania metody jest odsyłany w postaci dokumentu XML. Proces ten ilustruje rysunek poniżej.

Rysunek 14 Zdalne wywołanie procedury SOAP poprzez sieć Internet [7]

• Specyfikacja Szkieletu BizTalk (BizTalk Framework 2.0)

Podstawowym efektem pracy grupy BizTalk jest, obecnie dostępna w wersji 2.0, specyfikacja Szkieletu BizTalk (ang. BizTalk Framework) [1]. Jest to zbiór wytycznych określających, w jaki sposób należy projektować i tworzyć oparte o XML rozwiązania służące komunikacji pomiędzy aplikacjami i organizacjami. Specyfikacja Szkieletu BizTalk opiera się o szereg standardów Internetu, przede wszystkim:

• Rozszerzalny Język Znakowań XML

• Prosty Protokół Dostępu do Obiektów SOAP

• Protokół Transportu Informacji Hipertekstowej HTTP

• protokół pocztowy MIME

Wart zaznaczenia jest fakt, że specyfikacja Szkieletu BizTalk nie ma na celu rozpatrzenia wszystkich możliwych aspektów integracji systemów biznesowych, ani ich nie definiuje. Proponuje ona oparty na języku XML sposób tworzenia struktury dokumentów biznesowych, oraz określa metody niezawodnego i bezpiecznego przesyłania tak stworzonych dokumentów z miejsca na miejsce. Specyfikacja nie określa metod implementacji serwerów realizujących jej zadania, wyznacza ona wytyczne dla twórców oprogramowania realizującego zadania integracji biznesowej. Serwery spełniające te wymagania nazywane są serwerami zgodnymi z architekturą Szkieletu BizTalk (ang. BizTalk Framework Compliant servers, w skrócie BFC).

Specyfikacja Szkieletu BizTalk w wersji 2.0 stanowi rozszerzenie Prostego Protokołu Dostępu do Obiektów SOAP w wersji 1.1. Dzięki temu jest ona zgodna z wytycznymi organizacji W3C dotyczącymi rozwoju standardów opartych o XML.

1. Założenia i koncepcje

Szkielet BizTalk nie opisuje zawartości ani struktury określonych dokumentów biznesowych w sposób, jaki zostało to uczynione w standardzie Wymiany Danych Elektronicznych EDI. Zamiast tego definiuje zestaw znaczników oraz wytycznych, w jaki sposób należy tworzyć własne znaczniki, dzięki czemu umożliwia przekazywanie dokumentów o dowolnej, uzgodnionej pomiędzy handlującymi partnerami strukturze.

Reprezentacja logiczna modelu Szkieletu BizTalk może być zaprezentowana jako byt trójwarstwowy. Warstwa najwyższa to aplikacja - adapter łączący istniejące systemy biznesowe z umieszczonym w warstwie środkowej serwerem BFC, czyli zgodnym ze specyfikacją Szkieletu BizTalk. Serwer prowadzi interakcje z innymi systemami wykorzystując leżące w najniższej warstwie protokoły transportowe. Wykorzystując tę warstwową strukturę aplikacje komunikują się przesyłając pomiędzy sobą Dokumenty BizTalk. Ilustrację tego modelu przedstawia rysunek.

Rysunek 15 Miejsce Szkieletu BizTalk w procesie integracji biznesowej

Warstwa aplikacyjna jest odpowiedzialna za tworzenie dokumentów biznesowych w uzgodnionej formie i przekazanie ich do serwera. W zależności od implementacji dokumenty trafiają do serwera już przetworzone do formatu dokumentu BizTalk, lub są tam dopiero do tego formatu tłumaczone. Serwer przetwarza dokument wraz załącznikami, konstruując Wiadomość BizTalk (ang. BizTalk Message), a ona jest ostatecznie przekazywana do warstwy transportowej w celu niezawodnego dostarczenia do systemu docelowego.

Specyfikacja określa dwa podstawowe protokoły transportowe wykorzystywane w BizTalk do przenoszenia wiadomości pomiędzy aplikacjami. Jednym z nich jest Protokół Transportu Informacji Hipertekstowej HTTP, rozszerzony o możliwość przeprowadzania niezawodnej, asynchronicznej komunikacji (patrz rozdział 8.2.2). Drugi to Prosty Protokół Przesyłania Poczty SMTP, umożliwiający przesyłanie Wiadomości BizTalk wykorzystując istniejącą infrastrukturę pocztową.

2. Dokument BizTalk (BizTalk Document)

Dokument BizTalk (ang. BizTalk Document) jest implementacją wiadomości SOAP 1.1 i przenosi jeden lub więcej dokumentów biznesowych [7]. W celu umożliwiania przesłania Dokumentu BizTalk pomiędzy partnerami musi on być wcześniej zawarty wewnątrz Wiadomości BizTalk. Schemat przedstawiający strukturę Wiadomości BizTalk jest przedstawiony na rysunku poniżej:

Rysunek 16 Wiadomość BizTalk (BizTalk Message)

Struktura samej wiadomości jest zależna od transportu użytego do jej przesłania i nie jest określona w specyfikacji Szkieletu BizTalk. Wynika ona bezpośrednio z protokołu wykorzystywanego do przesyłania dokumentów.

1. Struktura Dokumentu BizTalk

Na Dokument BizTalk składa się nagłówek oraz jeden lub więcej dokumentów biznesowych opisanych przy pomocy języka XML. Przykładowy dokument biznesowy przenoszony wewnątrz Dokumentu BizTalk znajduje się na wydruku poniżej.

<SOAP-ENV:Body>

<po:PurchaseOrder xmlns:po="http://electrocommerce.org/purchase_order/">

<po:Title>Integracja systemow biznesowych przy pomocy BizTalk i XML</po:Title>

</po:PurchaseOrder>

</SOAP-ENV:Body>

Wydruk 23 Przykład dokumentu biznesowego przenoszonego przez Dokument BizTalk

Nagłówek zawiera informacje niezbędne do prawidłowego przetworzenia dokumentu przez serwer. Specyfikacja Szkieletu BizTalk w wersji 2.0 definiuje pięć sekcji nagłówka:

sekcja	obowiązkowa	opis
endpoints	tak	określa źródło pochodzenia dokumentu oraz jego miejsce przeznaczenia
properties	tak	umożliwia jednoznaczną identyfikację dokumentu przy pomocy uniwersalnie unikalnego identyfikatora UUID, a także określa dodatkowe właściwości dokumentu takie, jak czas wysłania, okres ważności czy cel przesłania
services	nie	realizuje żądanie niezawodnej przesyłki danych, dzięki żądaniu od serwera docelowego potwierdzenia dostarczenia lub akceptacji dokumentu
manifest	nie	umożliwia skatalogowanie zawartości przesyłanego Dokumentu BizTalk, zarówno zawartych w nim dokumentów biznesowych, jak i towarzyszących im załączników
process	nie	przekazuje informację na temat procesu przetwarzającego dany dokument, umożliwiając zarządzanie nimi

Tabela 7 Sekcje nagłówka Dokumentu BizTalk

Oto nagłówek przykładowego Dokumentu BizTalk:

<SOAP-ENV:Header>

<endpoints SOAP-ENV:mustUnderstand="1"

xmlns:ta="http://schemas.trading-agreements.com/"

xmlns="http://schemas.biztalk.org/btf-2-0/endpoints">

<to>

<address xsi:type="ta:httpURL">

http://www.we-love-books.org/receipts

</address>

</to>

<from>

<address xsi:type="ta:department">Book Orders</address>

</from>

</endpoints>

<properties SOAP-ENV:mustUnderstand="1"

xmlns="http://schemas.biztalk.org/btf-2-0/properties">

<identity>uuid:24d304a0-b6e1-493a-b457-4b86c684d6f3</identity>

<sentAt>2000-05-13T10:34:00-08:00</sentAt>

<expiresAt>2000-05-14T08:00:00+08:00</expiresAt>

<topic>http://electrocommerce.org/delivery_receipt/</topic>

</properties>

</SOAP-ENV:Header>

Wydruk 24 Przykładowy nagłówek Dokumentu BizTalk [1]

Specyfikacja Szkieletu BizTalk zawiera pełne Schematy XML określające w sposób formalny składnię dostępnych elementów Dokumentu BizTalk [1, dodatek A].

2. Pewne dostarczanie dokumentów

Aby móc mówić o odpowiednim poziomie niezawodności systemów biznesowych, nie wystarczy pamiętać jedynie o odpowiednim zabezpieczeniu oprogramowania realizującego interakcję pomiędzy nimi. Komunikacja realizowana podczas procesu wymiany danych pomiędzy serwerami BizTalk ma naturę asynchroniczną, co powoduje brak możliwości natychmiastowego poinformowania o rezultatach ostatniej operacji na zdalnym serwerze. Powoduje to konieczność wprowadzenia mechanizmu detekcji i raportowania błędów pomiędzy granicami organizacji, w środowisku rozproszonym i asynchronicznym. W Szkielecie BizTalk rolę tą pełnią:

• pokwitowanie dokumentu (ang. document receipt) - odsyłane do serwera źródłowego potwierdzenia:

• dostarczenia dokumentu (ang. delivery receipt) - pozwala na upewnienie się, że dokument został poprawnie dostarczony do miejsca przeznaczenia, odebrany i zaakceptowany do dalszego przetworzenia

• akceptacja dokumentu (ang. commitment receipt) - informacja zwrotna określająca, że dokument został przetworzony, zweryfikowany pod względem poprawności, zrozumiany i zatwierdzony do ostatecznego przetworzenia

• powtarzalne dostarczenie (ang. idempotent delivery) - jeśli serwer źródłowy nie otrzyma w odpowiednim czasie wymaganego potwierdzenia dostarczenia lub akceptacji dokumentu, jedną z możliwych akcji może być ponowne przesłanie. Wobec tego konieczne jest wykrywanie i eliminacja duplikatów.

Interakcja pomiędzy serwerami BizTalk wymaga określenia trzech nieprzekraczalnych terminów (ang. deadline) dla interakcji:

• termin dostarczenia - określa, w ciągu jakiego czasu dokument musi być zaakceptowany przez serwer docelowy. Akceptacja dokumentu wymaga przesłania pokwitowania dostarczenia dokumentu przed upłynięciem terminu dostarczenia

• termin akceptacji - określa, w ciągu jakiego czasu dokument musi zostać przeanalizowany i zaakceptowany do dalszego przetworzenia. Wymaga do przesłania pokwitowania akceptacji dokumentu przed upłynięciem terminu akceptacji

• termin przetworzenia - określa termin, po przekroczeniu którego dokument nie może być przekazany do aplikacji w celu przetworzenia, zatwierdzony lub w jakikolwiek sposób brany pod uwagę. Jest unieważniany

Specyfikacja Szkieletu BizTalk definiuje dokładne formaty pokwitowań dokumentu, oraz zachowanie serwerów po obydwu stronach interakcji [1].

1. Dokumenty z załącznikami

Często zachodzi konieczność przekazania wraz z dokumentem biznesowym dodatkowych danych, przeważnie binarnych. Na przykład w przypadku protokołu powypadkowego wysyłanego do ubezpieczyciela po kolizji drogowej, przeważnie wymagane jest załączenie zdjęć pojazdu, schematu poglądowego zdarzenia itp. Specyfikacja Dokumentu BizTalk umożliwia wykorzystanie formatu MIME (ang. Multipurpose Internet Mail Extensions) do tworzenia złożonych, wieloelementowych dokumentów zawierających załączniki. Dokładniejsze informacje na temat wysyłania dokumentów z załącznikami można znaleźć w specyfikacji Szkieletu BizTalk [1] oraz RFC do Wieloczęściowego MIME [42].

2. Zabezpieczanie danych

Oprócz bezpieczeństwa wynikającego z niezawodności dostarczania dokumentów, bardzo istotne jest zapewnienie, że dokument opuszczający serwer dociera do swojego miejsca przeznaczenia w niezmienionej formie. Przekłamania mogą nastąpić z powodu błędów w przesyle, ale również z powodu świadomego działania osób trzecich. Uniemożliwienie przechwycenia dokumentów biznesowych przez niepowołane osoby jest więc bardzo ważnym aspektem nie tylko z powodu bezpieczeństwa i potencjalnej wartości informacji w nich zawartych, ale także z punktu widzenia zachowania integralności danych.. Należy je więc tak zabezpieczyć, aby podsłuchiwanie, czy to w celu wykradania danych, czy też świadomego wprowadzania przekłamań, stało się bezcelowe.

Specyfikacja Szkieletu BizTalk przewiduje trzy poziomy zabezpieczania informacji:

• kodowanie

• podpis cyfrowy

• kodowanie i podpis cyfrowy

Kodowanie umożliwia zaszyfrowanie treści całego Dokumentu BizTalk lub tylko jego części, uniemożliwiając jego odczytanie i modyfikację przez osoby niepowołane. Podpis cyfrowy zapewnia wiarygodność przekazywanych informacji, będąc dowodem na to, że dokumenty odbierane przez serwer rzeczywiście pochodzą z organizacji figurującej w nich jako nadawca.

Do kodowania i podpisywania Wiadomości BizTalk wykorzystana została specyfikacja Bezpiecznego Internetowego Rozszerzenia Pocztowego Wielorakiego Użytku S/MIME (ang. Secure MIME) [43]. Dokładniejsze informacje na temat zabezpieczania Dokumentów BizTalk można znaleźć w specyfikacji Szkieletu BizTalk [1].

• Aranżacja BizTalk (BizTalk Orchestration)

Największym kosztem w czasie tworzenia systemów biznesowych jest koszt utrzymania i rozwoju istniejącego rozwiązania. Procesy biznesowe w przedsiębiorstwie nigdy nie są statyczne i potrafią się zmieniać bardzo często, a każda taka zmiana pociąga przeważnie za sobą konieczność wprowadzania zmian w stworzonych aplikacjach. Niestety, dotychczasowe metody tworzenia informatycznych rozwiązań dla biznesu nie pozwalały na pełne oddzielenie modelu biznesowego od samego procesu. Był on bezpośrednio (często niejawnie) implementowany w tworzonych systemach, powodując powstawanie bardzo wrażliwych na zmiany, a czasami nieco chaotycznych konstrukcji. Tak modelowany proces jest rozproszony w tworzonym kodzie. W przypadku jakichkolwiek zmian w modelu systemy takie wymagają znacznej przebudowy, poza tym są bardzo wrażliwe na błędy, nie nadają się do łączenia pomiędzy organizacjami oraz praktycznie się nie skalują (patrz rysunek).

Rysunek 17 Najczęściej spotykana „integracja” systemów biznesowych

Brak rozdzielenia modelu od procesu go realizującego powoduje konieczność bezpośredniej komunikacji współpracujących ze sobą aplikacji. Przedstawiona do tej pory wiedza pozwala nam na bardzo dokładne wyspecyfikowanie wymienianych danych oraz formatu, w jakim będziemy je wymieniać. Specyfikacja Szkieletu BizTalk pozwala również na określenie bezpiecznych i pewnych metod dostarczania tych danych. Nie umożliwia jednak zaprezentowania spójnego sposobu na przestawienie tego jak i dlaczego chcemy wymieniać dane. Brakuje odpowiedniej metody na formalne wyspecyfikowanie i implementację procesu biznesowego.

1. Aranżacja procesów biznesowych

Jednym z najczęściej spotykanych procesów biznesowych jest zakup dóbr dokonywany przez organizację kupującą oraz ich sprzedaż przez organizację dostarczającą. Istnieje wiele możliwych scenariuszy takiego procesu, uzależnionych od ustaleń pomiędzy handlującymi organizacjami, ich wewnętrznymi uregulowaniami, procesami itp. Opis przykładowej interakcji tego typu przedstawiłem już w rozdziale 5, a poglądowy rysunek w formie diagramu sekwencji przedstawiam poniżej.

Rysunek 18 Przykład procesu biznesowego [39]

Infrastrukturę realizującą zadanie postawione przed systemem opisującym i implementującym procesy biznesowe nazywamy infrastrukturą aranżacyjną (ang. orchestration).

2. Założenia Aranżacji BizTalk

Definicja aranżacji zaproponowana w dokumencie „BizTalk Orchestration White Paper” [2] umożliwia tworzenie i wykonywanie interakcji Biznes-Biznes pomiędzy organizacjami, aplikacjami oraz ludźmi, bez względu na czas trwania, jako medium transmisyjne obierając sieć Internet. Zgodnie z tym dokumentem realizuje ona trzy podstawowe wymagania:

1. Separację definicji procesu (modelu) od jego implementacji

2. Dynamikę procesu, to znaczy zdolność do zmian w trakcie wykonania, bazując na danych i interakcjach nim sterujących

3. Integrację typu „Wszystko z Wszystkim” (ang. „Any to Any” integration), nie narzucając w żadnym punkcie implementacji z jaką platformą, aplikacją czy też protokołem integrujemy system biznesowy

Dzięki spełnieniu tych wymagań jesteśmy w stanie łatwo zbudować i utrzymać wydajny system, który jest zdolny do komunikacji z praktycznie każdym potencjalnym partnerem biznesowym.

Implementacja Aranżacji BizTalk jest dostarczana wraz z serwerem Microsoft BizTalk Server 2000.

1. Rozdzielenie definicji od implementacji

Aranżacja BizTalk umożliwia realną separację modelu biznesowego od aplikacji go implementujących. Na rysunku przedstawiony został przykładowy, prosty model aranżacji, stworzony w wizualnym środowisku BizTalk Application Designer wchodzącym w skład serwera BizTalk Server 2000.

Rysunek 19 Rozdzielenie definicji od implementacji w Aranżacji BizTalk

Po lewej stronie rysunku został zaprojektowany prosty model, składający się z czterech akcji. Modele definiowane są przy pomocy diagramów zbliżonych w formie do diagramów aktywności znanych z języka UML. Prawa strona modelu to implementujące konkretne funkcjonalności aplikacji części rozwiązania informatycznego - interfejs udostępniany przez komponent COM, komponent skryptowy, kolejka MSMQ (ang. Microsoft Message Queuing Services - usługi kolejkowania wiadomości), czy też wiadomości Komunikacji BizTalk. Pośrodku znajdują się porty służące do łączenia modelu biznesowego po lewej z implementacją po prawej stronie. Dzięki tak intuicyjnemu rozwiązaniu uzyskujemy ogromną elastyczność definiowania samego procesu biznesowego - praca analityków biznesowych i specjalistów-informatyków nie koliduje ze sobą, co eliminuje jedną z najpoważniejszych dotychczasowych bolączek - problemy ze zmianą procesów biznesowych.

2. Dynamiczne procesy

Każdy proces aranżacyjny jest zdolny do dynamicznej adaptacji do zaistniałej w trakcie wykonywania sytuacji, ponieważ jest on sterowany danymi i zdarzeniami. Jesteśmy w stanie tak zaprojektować model, aby przebieg wykonania procesu na nim opartego było uzależnione od danych otrzymywanych na konkretnym etapie wykonania, lub też zaistniałego w trakcie wykonania zdarzenia. Oprócz tego nie musimy wiązać akcji z portem implementacyjnym w sposób statyczny, element ją implementujący (komponent, kolejka, kanał komunikacyjny) może być dynamicznie określony w czasie wykonywania przez proces zewnętrzny (patrz „Static and Dynamic Ports” [40]).

Rysunek 20 Przykład definicji dynamicznego portu Komunikacji BizTalk

3. Zapewnienie jednoczesności i synchronizacji

Modelując proces biznesowy często spotykamy się z sytuacjami, kiedy jego poszczególne części mogą być wykonywane równocześnie, niezależnie od siebie. Na przykład rejestrowanie zamówienia w wewnętrznych systemach firmowych może być wykonywane niezależnie od komunikacji z systemami biznesowymi dostawcy. Jednoczesność wykonywania operacji jest szeroko znana i rozumiana, jednak rzadko można spotkać implementacje takich rozwiązań. Przyczyną jest rzadkie wsparcie równoległości w językach programowania, a przede wszystkim dodatkowe trudności wynikające ze znacznej złożoności takiego podejścia.

W tym przypadku rozwiązanie zaproponowane w ramach Aranżacji BizTalk jest przełomowe. W celu stworzenia równoległego modelu biznesowego wystarczy wykorzystać dwa elementy diagramu aktywności - rozdzielenie (ang. fork) oraz połączenie (ang. join). BizTalk sam dba o koordynację jednoczesnych procesów i ich synchronizację (patrz rysunek).

Rysunek 21 Jednoczesność i synchronizacja w Aranżacji BizTalk

4. Problem długotrwałych transakcji

Właściwości systemów transakcyjnych są bardzo pożądane podczas implementacji procesów biznesowych. Ponieważ operacja transakcyjna może się wykonać jedynie w całości lub w ogóle, zapewniamy bezpieczną obsługę błędów, które mogą wystąpić na każdym etapie wykonywania procesu biznesowego. Transakcje mają cztery podstawowe właściwości, określane w skrócie ACID od angielskich słów je opisujących:

• Atomicity - atomowość; oznacza, że transakcja jest traktowana jako jedna, atomowa całość, czyli albo wszystkie modyfikacje dokonywane podczas trwania transakcji zostaną wykonane, albo żadna z nich

• Consistency - spójność; jeśli dane zawarte w bazie przed rozpoczęciem transakcji są spójne, muszą zachować spójność również po jej zakończeniu

• Isolation - izolacja; modyfikacje dokonywane w trakcie trwania transakcji muszą być odizolowane od zmian dokonywanych w trakcie trwania pozostałych, wykonywanych w tym samym czasie transakcji

• Durability - trwałość; po zatwierdzeniu transakcji, wszystkie modyfikacje muszą być zawsze w trwały sposób zapisane do bazy

W systemach Microsoft Windows NT i 2000 transakcje są kontrolowane przez serwis Koordynatora Rozproszonych Transakcji MSDTC (ang. Microsoft Distributed Transaction Coordinator).

Dzisiejsze rozwiązania informatyczne realizują transakcje koordynując ściśle powiązane ze sobą procesy, działające na tej samej platformie oraz wykonujące się w krótkim czasie. Tego typu transakcje są znane pod pojęciem krótkoterminowych. W architekturze Aranżacji BizTalk nie zawsze mamy do czynienia z taką sytuacją. Procesy często działają na różnych platformach, w ramach osobnych instalacji i są bardzo luźno ze sobą powiązane. Dlatego architekci BizTalk wprowadzili do modelu transakcje długotrwałe (ang. long-running transactions). Są to transakcje, które mogą trwać całe dni, tygodnie, a nawet miesiące, a dalej mogą być traktowane prawie tak samo, jak transakcje krótkoterminowe. Rozwiązanie to nie mogło być jednak zaimplementowane spełniając wszystkie dotychczasowe właściwości transakcji krótkoterminowych. Musiano zrezygnować z jednej z właściwości modelu ACID, a mianowicie izolacji. W modelu transakcji krótkoterminowych izolacja jest realizowana poprzez blokowanie bloków informacji (najczęściej w bazie danych) w taki sposób, aby inne procesy nie miały do nich dostępu. Nie trudno sobie wyobrazić, że taka implementacja w przypadku transakcji o niedeterministycznym czasie trwania prowadziła by do powstawania zagłodzeń i wyścigów. Poza tym praktycznie niemożliwe było by na przykład przekonanie administratora obcej bazy danych, aby zezwolił naszym procesom na blokowanie zasobów w jego bazie. Transakcje krótkoterminowe mogą być jednak zagnieżdżane wewnątrz transakcji długoterminowych, co umożliwia dokładną kontrolę nad tymi elementami transakcji długoterminowych, dla których izolacja danych jest niezbędna. Dokładniejsze informacje na temat implementacji transakcji długoterminowych przedstawię w części o Microsoft BizTalk Application Designer [10.4.2].

Innym typem transakcji dostępnych w Aranżacji BizTalk są transakcje terminowe (ang. Timeout Transactions), które są anulowane, jeśli w określonym czasie nie zostaną spełnione określone warunki.

Rysunek 22 Realizacja transakcji w Aranżacji BizTalk

Transakcje są definiowane w sposób graficzny, poprzez zawarcie transakcyjnych elementów diagramu aktywności wewnątrz reprezentującego transakcję prostokąta (patrz rysunek). Bardziej szczegółowe informacje na temat modelu transakcyjnego w Aranżacji BizTalk można znaleźć w artykule na stronach MSDN TechNet [41].

1. Pozostałe elementy Aranżacji BizTalk

Aranżacja BizTalk udostępnia także dwa inne elementy diagramu aktywności, które mogą posłużyć do tworzenia zaawansowanych modeli biznesowych. Jednym z nich jest blok decyzyjny (ang. decision), umożliwiający realizację decyzji warunkowych. Kolejny element diagramu to pętla dopóki (ang. while), wykonująca zadany ciąg akcji dopóki reguła jest prawdziwa. Ostatni, nie omówiony do tej pory element to anulowanie transakcji (ang. abort). Jeśli proces natrafi w trakcie wykonywania na ten element, zostaje uruchomione anulowanie trwającej w tym momencie transakcji.

Wszystkie te elementy są przedstawione na przykładowym diagramie poniżej.

Rysunek 23 Elementy decyzyjne, pętle, anulowania transakcji

• Microsoft BizTalk Server 2000

Inicjatywa BizTalk udostępniając specyfikację Szkieletu BizTalk określiła kierunek rozwoju integracji systemów biznesowych, zarówno w aspekcie Biznes-Biznes (B2B) jak i integracji aplikacji (A2A). Korporacja Microsoft, będąca jednym z członków inicjatywy, wprowadzając Aranżację BizTalk rozszerzyła horyzonty tej dziedziny informatyki o metody modelowania i integracji procesów biznesowych. Oddano także do dyspozycji użytkowników repozytorium dokumentów BizTalk.org, które oprócz swojej głównej roli pełni również rolę edukacyjną. Ponieważ jednak celem grupy nie było przedstawienie gotowej implementacji, żadne z tych przedsięwzięć nie określiło szczegółów implementacji serwerów realizujących zadania integracji BizTalk. Mimo to korporacja Microsoft od samego początku przygotowywała się do zaproponowania produktu realizującego wszystkie postawione przez inicjatywę cele, a sam efekt końcowy został osiągnięty w sposób nietuzinkowy, ponieważ już od samego początku wszystkie działania podejmowane podczas prac nad implementacją serwera BizTalk były jawne i szeroko konsultowane. Pierwsza „przymiarka” została przedstawiona na przełomie 1998 i 1999 roku pod nazwą BizTalk Jumpstart Kit, czyli w wolnym tłumaczeniu BizTalk „Na Szybko”. Korporacja poprosiła o komentarze i uwagi zarówno w środowisku informatyków, jak i pośród głównych zainteresowanych, czyli firm - głównie spoza branży informatycznej. Nie ograniczono się jedynie do „rekinów rynku”, czyli największych firm. Specjaliści firmy Microsoft podróżowali po całym świecie z prezentacjami, promując ideę BizTalk i zbierając uwagi na temat BizTalk Jumpstart Kit. Takie seminarium miało również miejsce w grudniu 1998 roku w Warszawie, miałem okazję w nim uczestniczyć i dzięki temu zapalić się do pomysłu integracji systemów biznesowych w technologii BizTalk.

Zebrane komentarze i propozycje miały ogromny wpływ na kształt przyszłych wersji wstępnych implementacji BizTalk. Dość powiedzieć, że to właśnie uwagi osób testujących BizTalk we wstępnej wersji spowodowały powstanie Aranżacji BizTalk, która obecnie stanowi trzon i główną siłę ostatecznej wersji produktu, czyli Microsoft BizTalk Server 2000.

1. Cechy produktu

Microsoft BizTalk Server 2000 jest pierwszym na rynku produktem implementującym założenia inicjatywy BizTalk. Jest to stworzony przez Microsoft pakiet umożliwiający aranżację procesów biznesowych, oraz integrację aplikacji wewnątrz przedsiębiorstwa lub pomiędzy partnerami biznesowymi. Udostępnia on:

• narzędzia XML do definicji dokumentów biznesowych i przekształceń pomiędzy nimi

• metody komunikacji

• realizację aranżacji procesów biznesowych

• metody śledzenia dokumentów i analizy danych historycznych

• pełną administrację serwerami i procesami w nich funkcjonującymi

Głównym zadaniem BizTalk Server jest umożliwienie definiowania procesów biznesowych i łączenie ich ze sobą, wykorzystując sieć Internet. Umożliwia on tworzenie efektywnych, bardzo dobrze skalujących się rozwiązań integrujących systemy biznesowe. Jest to bardzo istotne, ponieważ tworząc rozwiązanie tego typu nie można wychodzić z założenia, że nie będziemy go rozwijać. Wprost przeciwnie, zmiany są nieuniknione. Poza tym system musi być przygotowany na obsłużenie każdej wymaganej ilości kontrahentów, na obsługę milionów transakcji dziennie. Wszystko to realizuje BizTalk Server 2000.

Ponieważ BizTalk Server 2000 implementuje założenia inicjatywy BizTalk [1][2], jego mechanizmy bardzo intensywnie czerpią z dobrodziejstw języka XML. Poza tym wykorzystuje on standardowe mechanizmy transportowe, bezpieczeństwa oraz formaty danych udostępniając niezawodną i bezpieczną wymianę danych biznesowych poprzez Sieć Internet.

1. Architektura

Microsoft BizTalk Server 2000 udostępnia szereg usług wspomagających proces tworzenia rozwiązań integrujących systemy biznesowe. W dokumentacji [40] podzielono na:

Usługa	Opis
Komunikacja BizTalk (ang. BizTalk Messaging Services)	Usługi umożliwiające wysyłanie, odbieranie, przetwarzanie i śledzenie dokumentów, a także zarządzanie potwierdzeniami odbioru (ang. receipts), odwzorowanie danych, dbające o wewnętrzną integralność danych oraz bezpieczeństwo.
Funkcje odbierające (ang. Receive functions)	Funkcjonalność umożliwiająca serwerowi odbieranie dokumentów i przesyłanie do dalszego przetworzenia, poprzez śledzenie określonych zmian zachodzących w zadanych przez użytkownika miejscach. Mechanizmy funkcji odbierających mogą monitorować system plików (np. pojawianie się plików określonego typu w zadanym katalogu) oraz kolejki MSMQ - usługi kolejkowania wiadomości.
Usługi transportowe (ang. Transport services)	Zbiór usług umożliwiający przesyłanie dokumentów, oparty na protokołach sieciowych takich, jak HTTP, HTTPS, SMTP, protokołach transmisji plików (np. FTP), oraz Komponentach Integracji Aplikacji AIC (ang. Application Integration Components) i MSMQ. Oprócz tego istnieje możliwość przesyłania danych w obrębie tej samej aplikacji dzięki tzw. mostkowaniu portów wyjściowych i wejściowych aplikacji (ang. loopback).

Te trzy usługi składają się na pełen wachlarz możliwości komunikacji w systemach BizTalk, przedstawiony poglądowo na rysunku poniżej.

Rysunek 24 Metody Komunikacji w BizTalk [39]

Pozostałe usługi to:

usługa	opis
Analiza danych (ang. Data parsers)	Analiza danych zgodnych ze standardami przemysłowymi opisu dokumentów takimi, jak ANSI X12, UN/EDIFACT, XML, czy też pliki tekstowe, zgodnie z zasadami Szkieletu BizTalk 2.0 [1], a także sprawdzanie ich pod względem poprawności i zgodności ze specyfikacją.
Sprawdzanie danych (ang. Data validation)
Niezawodne dostarczanie dokumentów (ang. Reliable document delivery)	Zapewnia niezawodne dostarczanie dokumentów zgodnie ze specyfikacją Szkieletu BizTalk 2.0 [1]. Umożliwia przesyłanie potwierdzeń odbioru, określanie ilości powtórzeń oraz czasu pomiędzy nimi.
Bezpieczeństwo	Kodowanie i elektroniczne podpisywanie dokumentów, technologia klucza publicznego.
Aranżacja BizTalk™ (harmonogramy XLANG)	Pełna implementacja zgodnie ze specyfikacją [2], jak opisano w rozdziale 9. Wprowadzenie XLANG - opartego na XML języka opisu procesów biznesowych.
Porty implementacyjne aranżacji BizTalk	Tworząc rozwiązanie oparte o BizTalk Server 2000 możemy skorzystać z Komunikacji BizTalk, komponentów COM, usług kolejkowania MSMQ i komponentów skryptowych WSC (ang. Windows Scripting Components) - patrz Rysunek 19.

Tabela 8 Usługi BizTalk Server 2000

Produkt korporacji Microsoft to nie tylko zestaw usług, a także zestaw narzędzi wspomagających pracę analityków biznesowych , programistów i administratorów. W rozdziale 10.4 zostaną one opisane bardziej szczegółowo, teraz tylko je wymienię dzieląc w zależności od docelowej grupy użytkowników:

aplikacja	grupy użytkowników
BizTalk Editor	analitycy biznesowi programiści
BizTalk Mapper	analitycy biznesowi programiści
BizTalk Orchestration Designer	analitycy biznesowi programiści
BizTalk Messaging Manager	programiści administratorzy
BizTalk Server Administration	administratorzy
BizTalk Document Tracking	analitycy biznesowi

Tabela 9 Narzędzia BizTalk Server 2000

Jeśli planujemy obsługiwanie dużej ilości transakcji, rozwiązanie oparte o BizTalk może wymagać dużej mocy obliczeniowej, a także odpowiedniego zabezpieczenia w postaci nadmiarowości na wypadek awarii. Serwery BizTalk można łączyć w centralnie zarządzane, konfigurowane i monitorowane grupy. Dzięki temu uzyskujemy dużą skalowalność poziomą.

Architekturę serwera BizTalk uzupełniają bazy danych: administracyjna, kolejek dzielonych i śledzenia dokumentów, oparte o serwer Microsoft SQL Server w wersji 7.0 lub 2000, oraz repozytorium WebDAV.

baza danych	opis
administracyjna (ang. Messaging Management)	Przechowuje wszystkie informacje dotyczące konfiguracji grup i pojedyńczych serwerów, oraz innych ustawień dokonanych w aplikacji BizTalk Messaging Manager.
kolejek dzielonych (ang. Shared Queue)	Współdzielona przez wszystkie serwery w grupie, przechowuje informacje na temat etapów kontrolnych w poszczególnych procesach realizowanych przez serwery, działając na zasadzie podobnej do dziennika transakcyjnego (ang. transaction log) baz implementowanych w środowisku Microsoft SQL Server. Baza kolejek dzielonych daje nadmiarowość niezbędną do zachowania ciągłości operacji przy awarii jednego z serwerów w grupie. Umożliwia także równoważenie obciążenia pomiędzy nimi (ang. load ballancing).
śledzenia dokumentów (ang. Document Tracking)	Współdzielona przez wszystkie serwery w grupie, przechowuje informacje o bieżącej i przeszłej działalności instalacji BizTalk.
trwałości aranżacji (ang. Orchestration Persistence)	Przechowuje informacje o stanie procesu aranżacji biznesowej, który został zamrożony (ang. dehydrated). Zamrażanie procesów ma miejsce w przypadku długotrwałych transakcji i ma na celu oszczędną gospodarkę zasobami systemowymi. Więcej informacji na temat zamrażania i odmrażania (ang. rehydration) procesów XLANG znajduje się w dokumentacji BizTalk Server pod hasłem „Dehydration and Rehydration”. [40] Baza ta jest także używana w przypadku przywracania stanu sprzed awarii, oraz analizy działania programu (ang. debugging).
WebDAV	Jest to rozszerzenie standardu HTTP 1.1 umożliwiające udostępnianie hierarchicznych struktur plikowych poprzez HTTP. WebDAV stanowi repozytorium dokumentów, dbając o spójność danych i umożliwiając oznaczanie kolejnych wersji dokumentów w nim przechowywanych.

Tabela 10 Bazy danych BizTalk Server 2000

Zbierając razem wszystkie elementy serwera BizTalk Server 2000 otrzymujemy schemat zawarty na rysunku poniżej.

Rysunek 25 Architektura BizTalk Server 2000 [39]

2. Komunikacja BizTalk

BizTalk Server 2000 wprowadza pewien zestaw pojęć i bytów, umożliwiających definiowanie interakcji między systemami biznesowymi. Wszystkie one wchodzą w skład Komunikacji BizTalk (ang. BizTalk Messaging), drugiego obok Aranżacji BizTalk kluczowego elementu pakietu. Do zarządzania tą częścią został stworzony BizTalk Messaging Manager - aplikacja umożliwiająca zarządzanie wymianą dokumentów pomiędzy organizacjami. Krótki opis obiektów składających się na Komunikację BizTalk zawiera tabela poniżej. Dokładniejsze dane można odnaleźć w dokumentacji produktu [40].

obiekt	opis
kanał (ang. channel)	Jest to podstawowy obiekt Komunikacji BizTalk, definiowany przy pomocy zestawu atrybutów. Określa on definicję dokumentu wejściowego i wyjściowego, przy pomocy map umożliwia określanie transformacji pomiędzy różnymi postaciami dokumentów. Atrybuty kanału umożliwiają również zdefiniowanie niezawodnego dostarczania poprzez potwierdzenia odbioru, oraz poziomów bezpieczeństwa transmisji. Źródłem danych do kanału może być aplikacja, organizacja, lub harmonogram XLANG. Po przetworzeniu w kanale dokument jest przesyłany do portu komunikacyjnego lub listy dystrybucyjnej.
port komunikacyjny (ang. messaging port)	Identyfikuje punkt docelowy dla dokumentów wychodzących z kanałów. Punktami docelowymi mogą być organizacje, aplikacje lub harmonogramy XLANG. Porty komunikacyjne określają także sposób przesyłania dokumentów przy pomocy dostępnych usług transportowych, a także poziom bezpieczeństwa transmisji.
organizacja (ang. organization)	Organizacja stanowi wewnątrz modelu aplikacyjnego BizTalk abstrakt partnera biznesowego. Definiując organizacje określamy zbiór partnerów, z którymi prowadzimy interakcję. Oprócz organizacji zewnętrznych wyodrębnia się osobny byt organizacji lokalnej (ang. home organization), definiującej wewnętrzne aplikacje systemu w ramach którego działa dany serwer BizTalk. Organizacje są wykorzystywane jako źródło danych dla kanałów lub punkty docelowe dla portów komunikacyjnych.
definicja dokumentu (ang. document definition)	Określa specyfikację dokumentu przesyłanego w ramach interakcji BizTalk, czyli jego strukturę, typ oraz wersję. Definicje dokumentów są wykorzystywane podczas określania wejściowych i wyjściowych dokumentów dla danego kanału.
koperta (ang. envelope)	Koperty obudowują elektroniczne dane biznesowe do celów transportu w sposób umożliwiający serwerowi BizTalk otwarcie przychodzącej transmisji (która może się składać z wielu dokumentów) oraz zdefiniowanie transmisji wychodzącej. BizTalk umożliwia określenie koperty dla własnych formatów dokumentów XML, EDI (ANSI X12, UN/EDIFACT), plików tekstowych, niezawodnej transmisji (koperta zgodna ze Szkieletem BizTalk 2.0) oraz innych, definiowanych przez użytkownika dowolnych kopert.
lista dystrybucyjna (ang. distribution list)	Grupa portów komunikacyjnych używana do wysyłania tych samych dokumentów do różnych organizacji lub aplikacji.

Tabela 11 Obiekty Komunikacji BizTalk [40]

Wykorzystując wszystkie powyższe obiekty Komunikacja BizTalk obsługuje interakcje w następujący sposób - kiedy serwer BizTalk odbiera dokument, identyfikuje odpowiadający mu kanał (lub kanały) i przekazuje do niego otrzymany dokument. Tam jest on przetwarzany i przekazywany do portu komunikacyjnego (lub listy dystrybucyjnej), który „opakowuje” w kopertę, zabezpiecza i transportuje dokument do punktu docelowego. Stosując ten scenariusz jesteśmy w stanie po przygotowaniu wszystkich niezbędnych elementów systemu takich, jak harmonogramy XLANG, definicje dokumentów i transformacje pomiędzy nimi, komponenty AIC itp., połączyć je na bardzo wysokim poziomie abstrakcji, aby w sposób atrybutowy integrować ze sobą aplikacje i organizacje.

Przykład takiego połączenia pomiędzy dwoma aplikacjami zdolnymi wyłącznie do przetwarzania plików tekstowych o określonej strukturze ilustruje rysunek poniżej.

Rysunek 26 Przykład komunikacji pomiędzy aplikacjami w architekturze BizTalk Server 2000 [39]

Warty nadmienienia jest również fakt, że wewnątrz kanału każdy dokument, jest reprezentowany w formacie XML, nawet w przypadku dokumentów nie-XML'owych, które są przetwarzane na podstawie specyfikacji źródła do formatu XML i w takiej postaci są poddawane wszystkim procesom zachodzącym wewnątrz kanału.

Rysunek 27 Przetwarzanie dokumentu wewnątrz kanału BizTalk [15]

3. Narzędzia serwera Microsoft BizTalk Server 2000

Pierwsza implementacja wytycznych inicjatywy BizTalk to nie tylko zestaw serwisów i elementy architektury rozwiązania. Dawno już minęły czasy benedyktyńskiego tworzenia kodu w edytorach tekstowych, analizy jego wywołania poprzez skomplikowane programy śledzące ich działanie na bardzo niskim poziomie, czy też administracji poprzez ręczną edycję ustawień w plikach systemowych. Środowisko Windows jest środowiskiem wizualnym i takiego typu narzędzia preferuje. BizTalk Server 2000 nie jest tutaj wyjątkiem, udostępniając analitykom, programistom i administratorom szeroki wachlarz aplikacji czyniących pracę łatwiejszą, a samo rozwiązanie bardziej przejrzyste.

1. Przetwarzanie dokumentów

Jednym z podstawowych pojęć w nomenklaturze BizTalk jest dokument, ponieważ, jak już wielokrotnie wcześniej wspominałem, jest to elementarna jednostka wymiany informacji w interakcji biznesowej. BizTalk serwer udostępnia narzędzia do definiowania schematów dokumentów, i transformacji między nimi.

1. BizTalk Editor

Edytor BizTalk (ang. BizTalk Editor) jest narzędziem umożliwiającym definiowanie specyfikacji dokumentów biznesowych przy pomocy schematów XML. Oprócz definiowania własnych formatów dokumentów, udostępnia zestaw schematów opisujących najczęściej spotykane typy dokumentów biznesowych takie, jak faktura, zlecenie sprzedaży, cennik itp, a także definicje dla dwóch standardów Wymiany Danych Elektronicznych EDI - ANSI X12 oraz EDIFACT. Wart nadmienienia jest również fakt, że Edytor BizTalk jest w stanie przetworzyć praktycznie dowolny format danych dający się wyrazić w strukturze hierarchicznej. Aplikacja ta umożliwia również zaimportowanie gotowych specyfikacji w formatach XDR, opisu typu dokumentu DTD, a także stworzenie jej na podstawie gotowego, poprawnego składniowo pliku XML. Stworzona specyfikacja może zostać sprawdzona pod względem poprawności, a także zapisana do pliku lub repozytorium WebDAV.

Więcej informacji na temat Edytora BizTalk znajduje się w dokumentacji [40].

Rysunek 28 Edytor BizTalk

2. BizTalk Mapper

Kreator Odwzorowań BizTalk (ang. BizTalk Mapper) jest aplikacją umożliwiającą tworzenie będących transformacjami XSLT odwzorowań, umożliwiających przejście z jednego formatu dokumentu na inny. Jest on narzędziem w pełni wizualnym, dzięki czemu unikamy konieczności żmudnego i podatnego na błędy ręcznego kodowania transformacji. Udostępnione środowisko umożliwia łączenie rekordów i pól w dokumentach poprzez technikę „przeciągnij-i-upuść” (ang. drag-and-drop), tworząc graficzne połączenia (ang. links) pomiędzy elementami. Oprócz tego dzięki tzw. funktoidom (ang. functoid) możemy definiować bardziej złożone transformacje strukturalne, polegające na wykonywaniu przekształceń matematycznych i algorytmicznych na wybranych elementach dokumentu źródłowego.

Funktoida jest określeniem opisującym element wizualnego środowiska pracy aplikacji BizTalk Mapper, przy pomocy którego określamy przekształcenia dokonywane podczas transformacji jednego typu dokumentu na drugi. Jest ona reprezentowana przez różnokolorowe kwadraciki. Jednym z prostszych przykładów jest funktoida realizująca funkcję sumowania. Aby dokonać przekształcenia wykorzystującego funktoidę, przeciągamy ją z palety na obszar roboczy, łączymy z polami, rekordami wejściowym i wyjściowymi, oraz opcjonalnie określamy parametry przekształcenia. W przypadku funktoidy sumującej jako wynik jej działania uzyskujemy rekord dokumentu wyjściowego zawierający sumę wszystkich wartości zawartych w podpiętych do funktoidy rekordach dokumentu źródłowego. Mamy do dyspozycji szeroki wachlarz ponad 60 typów funktoid - od wykonujących podstawowe operacje arytmetyczne jak dodawanie czy mnożenie, przekształcenia logiczne, operacje na określonych typach danych, przez funktoidy statystyczne, aż po umożliwiające interakcję z bazą danych czy zaawansowane przekształcenia zdefiniowane w języku skryptowym Visual Basic.

Więcej informacji na temat Kreatora Map BizTalk znajduje się w dokumentacji [40].

Rysunek 29 Kreator Map BizTalk - transformacja wykorzystująca funktoidy

2. Modelowanie procesów biznesowych - Projektant Aranżacji BizTalk

Możliwości Aranżacji BizTalk zostały już przedstawione w rozdziale 9. Tam też znalazło się kilka rysunków będących zrzutami ekranowymi fragmentów przestrzeni roboczej jednego z najważniejszych narzędzi zawartych w BizTalk Server 2000, czyli Projektanta Aranżacji BizTalk (ang. BizTalk Orchestration Designer). Narzędzie to umożliwia wizualne modelowanie procesów biznesowych opartych o Aranżację BizTalk i kompilowanie ich do harmonogramów XLANG. Dzięki wprowadzeniu języka XLANG możliwe stało się opisywanie procesów biznesowych przy pomocy składni XML. Diagramy tworzące harmonogramy aranżacyjne, skompilowane do postaci XLANG mogą być wykonywane przez serwisy usługowe serwera BizTalk.

Projektant Aranżacji BizTalk jest oparty o interfejs wchodzącej w skład pakietu Microsoft Office aplikacji Microsoft Visio 2000, dlatego też musi być ona zainstalowana w systemie, na którym planujemy wykorzystanie Projektanta. Modelując proces biznesowy tworzymy jego wizualną reprezentację, tworzymy diagram aktywności i definiujemy przepływ pomiędzy poszczególnymi akcjami. Również wizualnie określamy porty implementujące konkretne akcje. Określanie szczegółowych danych dla każdego z portów implementacyjnych ułatwiają nam bardzo użyteczne kreatory. Przykładowy model aranżacji biznesowej otwartej w środowisku tej aplikacji znajduje się na rysunku poniżej.

Rysunek 30 Projektant Aranżacji BizTalk

Przeważnie model aranżacji składa się z jednego diagramu - taka sytuacja ma miejsce na rysunku powyżej. Jednak w przypadku, kiedy wykorzystujemy transakcje długoterminowe, często zachodzi konieczność zdefiniowania procesów kompensujących ich działanie w przypadku wystąpienia błędu. Wtedy w modelu może się znajdować nawet kilka różnych diagramów.

Oprócz wizualnej reprezentacji procesu biznesowego w podobny sposób definiujemy przepływ danych pomiędzy wiadomościami przepływającymi między portami obiektów implementujących rozwiązanie. Do każdego portu jest przyporządkowana jakaś wiadomość, która jest odbierana lub wysyłana przez akcję. Zależności pomiędzy tymi wiadomościami reguluje sekcja komunikacji. Rysunek poniżej ilustruje przykład jej wykorzystania.

Rysunek 31 Definiowanie przepływu danych pomiędzy wiadomościami

Więcej informacji na temat Projektanta Aranżacji BizTalk znajduje się w dokumentacji [40].

3. Zarządzanie i analiza

Z biznesowego punktu widzenia równie ważnym, jak funkcjonalność całego systemu elementem jest zapewnienie ciągłości działania, czyli narzędzi administracyjnych, oraz odpowiednich mechanizmów raportowania i analizy aktywności. Serwer BizTalk udostępnia w tym celu zestaw trzech narzędzi - do zarządzania i definiowania interakcji biznesowych, do śledzenia i analizy aktywności oraz do administracji całością instalacji BizTalk.

1. BizTalk Messaging Manager

Zarządca Komunikacji BizTalk (ang. BizTalk Messaging Manager) jest wszechstronnym narzędziem umożliwiającym zajęcie się projektowanym rozwiązaniem na odmiennym od procesów aranżacyjnych poziomie abstrakcji. Przy jego pomocy definiujemy obiekty Komunikacji BizTalk (organizacje, kanały komunikacyjne itp.) i zarządzamy komunikacją pomiędzy nimi. Więcej na ten temat można było odnaleźć w rozdziale 10.3 poświęconym Komunikacji BizTalk.

Aplikacja oddaje do dyspozycji szereg kreatorów, dzięki którym w łatwy i przejrzysty sposób jest w stanie zdefiniować wszystkie elementy niezbędne do stworzenia interakcji biznesowej (więcej informacji na ich temat można znaleźć w dokumentacji serwera BizTalk [40]). Mamy także możliwość wyszukiwania i edytowania zdefiniowanych wcześniej obiektów Komunikacji BizTalk.

Rysunek 32 Przykład kreatora definiującego port komunikacyjny dla organizacji

2. Śledzenie Dokumentów BizTalk

Aby móc skutecznie zarządzać informacjami przepływającymi przez system BizTalk konieczna jest możliwość prostej analizy jego przeszłej i bieżącej aktywności. Do tego celu została stworzona aplikacja Śledzenia Dokumentów BizTalk (ang. BizTalk Document Tracking). Jest to aplikacja internetowa, zbudowana w oparciu o kontrolki ActiveX [46] i skrypty stworzone w języku Visual Basic. Z powodu zastosowanych technologii musi być uruchamiana w przeglądarce Microsoft Internet Explorer, nie jest to jednak duże ograniczenie, ponieważ serwer BizTalk do poprawnego działania wymaga jej w wersji 5 lub wyższej.

Śledzenie Dokumentów BizTalk umożliwia analizę przetworzonych w systemie dokumentów, określając kryteria wyszukiwania poprzez zestaw filtrów takich, jak: przedział czasowy, punkty źródłowe i docelowe, nazwa dokumentu itp. Aplikacja umożliwia również stworzenie zapytań zaawansowanych, uwzględniających analizę dowolnych pól dokumentu przechodzącego przez system. W ten sposób jesteśmy w stanie dokonać przeglądu aktywności na przykład pod kątem wartości transakcji w zadanym okresie czasu.

Aplikacja wykorzystuje tworzoną osobno dla każdej grupy serwerów BizTalk bazę śledzenia dokumentów (patrz Tabela 10), w której przechowywane są dane na temat całej bieżącej i przeszłej aktywności serwera, w szczególności:

• interakcji i przetwarzania dokumentów

• przechowywania kopii wszystkich dokumentów przechodzących przez system

Dzięki tym informacjom jesteśmy w stanie odpowiedzieć na każde pytanie dotyczące obecnej i przeszłej aktywności instalacji BizTalk, co ma bardzo istotne znaczenie biznesowe, ponieważ dzięki temu tworzymy na bieżąco pełną dokumentację wszystkich procesów w firmie. Implikuje to ogromne możliwości analityczne.

Więcej informacji na temat Śledzenia Dokumentów BizTalk zawiera dokumentacja [40]. Poniżej znajduje się zrzut ekranowy aplikacji podczas wyświetlania wyników przykładowego zapytania.

Rysunek 33 Śledzenie Dokumentów BizTalk w przeglądarce Internet Explorer

1. Administracja Serwera BizTalk

Narzędziem typowo administracyjnym jest Administracja Serwera BizTalk (ang. BizTalk Server Administration). Stworzona w postaci “zatrzasku” (ang. snap-in) systemowej konsoli zarządzającej MMC (ang. Microsoft Management Console) aplikacja umożliwia:

• dodawanie serwerów BizTalk i łączenie ich w grupy, zarządzanie nimi

• zarządzanie kolejkami serwera BizTalk i ich zawartością

• zarządzanie funkcjami odbierającymi (ang. receive functions)

Standardowo w domyślnym widoku konsoli zarządzającej MMC, otwieranym przez Administrację Serwera BizTalk, znajduje się również przeglądarka zdarzeń systemowych (ang. Event viewer). Rysunek poniżej przedstawia Administrację Serwera BizTalk podczas przeglądania zawartości jednej z kolejek.

Rysunek 34 Administracja serwerem BizTalk

1. Wsparcie dla innych systemów biznesowych

Microsoft BizTalk Server 2000 nie ogranicza się tylko do integracji pomiędzy systemami zgodnymi ze Szkieletem BizTalk. Aby móc poszerzać krąg partnerów biznesowych w sposób nieograniczony, produkt ten bezpośrednio wspiera integrację z najszerzej obecnie spotykanym standardem wymiany danych biznesowych EDI, a także ułatwia komunikację z systemami finansowymi firmy SAP, systemami spadkowymi i aplikacjami klasy mainframe. Microsoft prowadzi także zaawansowane prace nad połączeniem BizTalk oraz technologii RosettaNet, dostępne są również zestawy szablonów typu Business Accelerator, wspomagających pracę nad konkretnymi rozwiązaniami (np. dla wykorzystywanej w służbie zdrowia architektury HIPPA).

1. Wymiana Danych Elektronicznych EDI

BizTalk Server może pełnić w stosunku do systemów EDI różnorakie role. Pierwszą z nich jest umożliwienie małym firmom, których nie stać na zakupienie i wdrożenie systemu opartego na Wymianie Danych Elektronicznych EDI, komunikację z dużymi organizacjami posługującymi się tym standardem. Druga rola polega na uzupełnieniu funkcjonalności wdrożonych już w firmie rozwiązań EDI o integrację aplikacji wewnątrz przedsiębiorstwa (ang. EAI - Enterprise Application Integration), gdzie serwer BizTalk pełni rolę koncentratora integrującego rozwiązania wewnętrzne, a w przypadku komunikacji z dotychczasowymi partnerami EDI przekazuje sterowanie do serwerów EDI. Rozwiązanie to pozwala również na stopniową migrację systemu EDI do opartego w całości na BizTalk i XML. Schemat takiego rozwiązania znajduje się na rysunku.

Rysunek 35 Serwer BizTalk jako koncentrator

Od strony implementacyjnej interakcja z systemami EDI sprowadza się do określenia specyfikacji dokumentu EDI, którego oczekujemy. BizTalk Server 2000 zawiera schematy XML większości dokumentów opisanych w standardach ANSI X12 oraz EDIFACT, ich edycję i przeglądanie umożliwia BizTalk Editor. Więcej pracy wymaga zdefiniowanie odwzorowań transformacji pomiędzy dokumentem EDI a odpowiadającym mu dokumentem XML. Jednak dzięki aplikacji BizTalk Mapper proces ten jest zdecydowanie prostszy, niż w przypadku ręcznego tworzenia kodu w języku XSLT.

Przykłady dokumentu ANSI X12 4010 850, opisującego zamówienie (ang. purchase order), oraz odwzorowania pomiędzy tym dokumentem a standardowym formatem zamówienia XML w systemie BizTalk znajdują się na rysunku poniżej.

Rysunek 36 Definicja dokumentu oraz transformacji EDI [15]

2. Systemy SAP

Dokumentacja serwera BizTalk [40] jako metodę integracji z systemami ERP firmy SAP wskazuje moduł umożliwiający zdalny dostęp do funkcji tych systemów, czyli SAP Remote Function Call SDK [44]. Ponieważ jednak metoda ta nie należy do najprostszych i wymaga sporych zabiegów programistycznych, firmy Microsoft i SAP pracują nad stworzeniem prostszego sposobu integracji swoich systemów (SAP jest jednym z aktywnych członków inicjatywy BizTalk).

Obecni użytkownicy próbujący integrować te systemy wskazują jednocześnie na dużą awaryjność połączenia poprzez zdalne wywołanie procedur, dlatego często rozwiązują ten problem poprzez bezpośrednią wymianę (na przykład poprzez FTP) dokumentów w formacie IDOC, będącym formatem danych w systemach SAP [45]. Ponieważ BizTalk umożliwia przekazywanie dokumentów w dowolnym formacie, stworzenie odpowiednich schematów XML dla IDOC oraz parsera i publikatora, podobnie, jak zostało to zrobione w przypadku EDI, wydaje się być najlepszym rozwiązaniem.

3. Systemy spadkowe

Integracja z systemami spadkowymi (ang. legacy systems) wymaga bardzo dobrej znajomości systemu, z jakim się komunikujemy. Większość starych aplikacji umożliwia w taki czy inny sposób interakcję ze sobą, czy to poprzez niskopoziomowe wywołania funkcji interfejsowych API (ang. Application Programming Interface), czy też na wyższym poziomie, poprzez przekazywanie dokumentów w określonym formacie. W takim przypadku musimy się liczyć z tym, że format takiego dokumentu może być bardzo różny. Często jest to postać pliku tekstowego o określonej strukturze, na przykład z wpisami rozdzielonymi znakami przestankowymi (ang. delimited), czy też z polami o stałej szerokości (ang. positional). Serwer BizTalk udostępnia mechanizmy do bezpośredniego przetwarzania tego typu plików.

Kiedy jednak rozważamy integrację z systemami spadkowymi, najczęściej format dokumentu jest dużo bardziej złożony, właściwy tylko dla tej konkretnej aplikacji, z którą chcemy się komunikować. Wcale nie musi być to plik tekstowy, równie dobrze dokumenty mogą być zapisywane w formie binarnej. Tego typu scenariusz rozwiązujemy pisząc własne komponenty do analizy dokumentów.

W rozdziale 10.3, traktującym o Komunikacji BizTalk krótko wspomniałem o mechanizmach przetwarzania dokumentów wewnątrz kanałów. Stamtąd też wziąłem rysunek dla celów wyjaśnienia dwóch pojęć, których zrozumienie jest kluczowe w procesie tworzenia rozwiązania integrującego systemy spadkowe. Parser i publikator (ang. serializer) - bo o nich mowa - to dwa komponenty, które umożliwiają nam przetwarzanie w kanale dokumentów w formacie innym, niż XML (pamiętamy, że każdy dokument wewnątrz kanału musi być w formacie XML). Dokument, dzięki opakowaniu w kopertę opisującą jego format (X12, tekstowy itp.) jest przesyłany przez serwer BizTalk do odpowiedniego parsera, który analizuje jego strukturę, przetwarzając jednocześnie na format XML. I odwrotnie - publikator transformuje dokument XML na inny, dowolny format. BizTalk umożliwia nam stworzenie i zarejestrowanie własnych parserów i publikatorów, dzięki czemu możemy przetwarzać dokumenty dowolnego typu. Więcej informacji na temat tworzenia parserów można znaleźć w artykułach technicznych Microsoft MSDN [49] oraz w dokumentacji serwera BizTalk [40][48].

Rysunek 37 Rola parserów i publikatorów w kanale BizTalk.

W tym samym rozdziale pisałem o tak zwanych Komponentach Integracji Aplikacji, w skrócie AIC (ang. Application Integration Components). Są to komponenty COM umożliwiające integrację z aplikacjami spadkowymi na poziomie programowym. Implementując komponenty AIC mamy pełną dowolność co do operacji w nich dokonywanych. Jedynym ograniczeniem jest realizacja jednego z dwóch dostępnych typów interfejsów - rurociągu (ang. pipeline) lub „lekkiego” (ang. lightweight) - dzięki czemu możliwe jest automatyczne wykorzystanie tych komponentów jako metody transportu w kanale BizTalk. Wykorzystanie komponentów AIC niesie ze sobą jeszcze jedną, ogromną zaletę - dzięki nim jesteśmy w stanie komunikować się również z systemami klasy mainframe. Tego typu scenariusze integracyjne upraszcza serwer Microsoft Host Integration Server 2000, o którym wspominam szerzej w rozdziale 10.6.4.

Bardziej szczegółowych informacji na temat integracji z systemami spadkowymi można znaleźć w artykułach MSDN [47] oraz dokumentacji do serwera BizTalk [40][48].

2. Integracja z serwerami i narzędziami z rodziny .NET

.NET, czyli kropka net (ang. dot net) jest nową rodziną rozwiązań firmy Microsoft, opartą na platformie Windows 2000. Stawia ona głównie na Internet i tworzenie aplikacji intensywnie z niego korzystających, kładąc nacisk na powstawanie sieciowych rozwiązań rozproszonych nowej generacji. W tym celu zostały stworzone:

• nowe narzędzia programistyczne z rodziny Visual Studio.NET

• nowe wersje znanych serwerów oraz nowe serwery

• platforma, czyli zasady tworzenia rozwiązań internetowych pod postacią Szkieletu .NET (ang. .NET Framework)

Rysunek 38 Miejsce BizTalk Server 2000 w architekturze Windows DNA 2000 serwerów .NET

Na powyższym rysunku widać umiejscowienie poszczególnych produktów serwerowych .NET na platformie Windows DNA 2000. Serwer BizTalk 2000, który jest głównym przedmiotem analizy w tej pracy, znajduje się w tylnej części architektury (ang. back-end), dostarczając usług integracyjnych i aranżacji procesów dla projektowanych rozwiązań.

1. Platforma Windows DNA 2000

Windows DNA jest platformą stworzoną przez firmę Microsoft w celu umożliwienia tworzenia elastycznego i wydajnego oprogramowania internetowego. Chcąc stworzyć aplikacje łatwo integrujące się z już istniejącymi systemami, umożliwiające rozrost i ewolucję wraz ze zmieniającymi się wymaganiami, oparte na sieci Internet, zdolne do szybkiego wprowadzenia na rynek, warto skorzystać z usług platformy Windows DNA, jest ona bowiem bardzo dobrym rozwiązaniem.

W ekonomii opartej na sieci Internet bardzo istotne jest, aby aplikacje były wprowadzane na rynek tak szybko, jak to tylko możliwe, aby wykorzystać szanse na nim istniejące oraz efektywnie konkurować z innymi produktami. Windows DNA zostało zaprojektowane, aby pomóc w realizacji tego trudnego zadania.

Aplikacje stworzone dla platformy Windows DNA bazują na architekturze wielowarstwowej (n-tier), jednak nie jest to główny powód, dla którego mogą one szybciej wprowadzane na rynek. Windows 2000 udostępnia bogaty zestaw komponentów i technologii zaszytych głęboko w projekcie samego systemu operacyjnego, które można wykorzystać w swoich własnych aplikacjach aby oszczędzić czas niezbędny w innym przypadku do stworzenia podobnych rozwiązań we własnym zakresie. Tworząc aplikacje dla platformy Windows DNA szybko orientujemy się, że możemy skoncentrować się wyłącznie na problemie biznesowym, który mamy za zadanie rozwiązać.

Gdy mamy do czynienia z rozwiązaniami typu e-business, w większości przypadków zadaniem projektantów jest budowa transakcyjnego środowiska zapewniającego przetworzenie wymaganych zadań w zadanej kolejności, zachowując atomowość i spójność całej operacji. Wykorzystując Windows DNA możemy, zamiast oddzielnie kupować i integrować oprogramowanie udostępniające usługi transakcyjne, wykorzystać środowisko udostępniane „z pudełka” przez platformę DNA, jakim jest Microsoft Transaction Service (MTS). Środowisko to jest częścią COM+ (ang. Component Object Model), rozwiązania będącego kontynuacją pracy firmy Microsoft nad technologiami wykorzystującymi komponenty do tworzenia wysoko wydajnych i niezawodnych aplikacji. Wykorzystując dostarczane przez infrastrukturę Windows DNA serwisy takie, jak COM+, nie tylko upraszczamy proces tworzenia całej aplikacji, lecz również w ogromnym stopniu przyczyniamy się do umożliwienia późniejszego jej rozwoju i zapewnienia wysokiej wydajności. Stworzone w technologii COM aplikacje są wysoko skalowalne, zapewniając obsługę dużej ilości równocześnie korzystających z aplikacji użytkowników. Dzięki temu można szybko i tanio przystosować stworzoną aplikację do obsługi większej ilości użytkowników jedynie poprzez dodanie zasobów sprzętowych. Rozszerzając dodatkowo usługi udostępniane przez COM+, Windows 2000 oferuje również możliwość wymiany informacji pomiędzy aplikacjami wykorzystując połączenia sieciowe, indeksowanie danych umożliwiające ich szybkie przeszukiwania. Udostępnia również wysokie bezpieczeństwo przeprowadzanych operacji, wygodny dostęp do danych przechowywanych na różnych systemach bazodanowych (SQL Server, Oracle, DB2 i inne), zapewnia pełne wsparcie dla XML. Poprzez usługę równoważenia obciążenia sieciowego NLB (ang. Network Load Balancing) zapewnia równomierne rozłożenie obciążenia sieciowego na serwerach.

1. Współpraca i integracja

Nowo powstałe i istniejące organizacje potrzebują zintegrować nowo powstające rozwiązania internetowe z istniejącymi aplikacjami. Na przykład może zaistnieć potrzeba integracji internetowej aplikacji przetwarzającej zamówienia z już wdrożonym i wykorzystywanym systemem księgowym. Aby zapewnić niskie koszty tworzenia aplikacji i udostępnić klientom i partnerom usługę o odpowiedniej funkcjonalności, bardzo istotne jest, aby każde nowo tworzone rozwiązanie poprawnie współpracowało z już istniejącymi. Integracja pomaga szybko wprowadzać na rynek coraz lepsze i nowatorskie rozwiązania, poprzez wykorzystanie wartości dodanych udostępnianych przez integrowane, już istniejące i sprawdzone na rynku rozwiązania. Windows DNA został zaprojektowany, aby umożliwić integrację na dwóch poziomach: bazodanowym i aplikacyjnym.

Rozwiązania wprowadzone w Windows DNA umożliwiają wykorzystywanie jako źródeł danych zarówno relacyjnych, jak i nie relacyjnych baz danych, takich jak Microsoft SQL Server, Oracle, mainframe'owe bazy danych jak IBM DB2, SAP itp. Dzięki usługom serwera SNA oraz Host Integration Server 2000 możliwe jest połączenie tworzonych rozwiązań z istniejącymi systemami klasy mainframe, jak na przykład AS/400. Standardy przemysłowe dotyczące oprogramowania wymagają zapewnienia pełnej wymiany informacji między istniejącymi systemami. Dzięki zastosowaniu standardu XML i BizTalk Server 2000 możliwe jest zapewnienie komunikacji między dowolnymi tworzonymi lub już istniejącymi informatycznymi produktami biznesowymi współpracujących partnerów.

2. e-Biznes

Platforma Windows DNA udostępnia szeroką paletę narzędzi umożliwiających budowanie efektywnych i potężnych platform komercyjnych typu e-Biznes (ang. e-Commerce). Dzięki Microsoft Commerce Server 2000 możliwe jest tworzenie rozbudowanych systemów Biznes-Konsument (B2C) w formie sklepów internetowych wykorzystujących mechanizmy personalizacji, śledzenia zamówień, reklamy bezpośredniej, promocji, płatności elektronicznej, integracji z systemami wspomagającymi pracę sklepu (np. systemy magazynowe) jak i platform transakcyjnych Biznes-Biznes (B2B) zestawianych pomiędzy współpracującymi partnerami.

3. Podsumowanie

Windows DNA bazuje na trzech podstawowych zasadach: krótki czas dostarczenia produktu na rynek, współpraca pomiędzy aplikacjami, elastyczność i możliwość adaptacji. Te elementy razem tworzą narzędzie umożliwiające projektowanie, tworzenie, utrzymywanie i skalowanie aplikacji internetowych szybko i w prosty sposób, dając czas na skupienie się na rzeczywistych problemach biznesowych.

2. Microsoft Commerce Server 2000

Głównym serwerem platformy .NET, na którym oparte są rozwiązania komercyjne jest Microsoft Commerce Server 2000. Służy on głównie do budowy elastycznych, skalowalnych sklepów internetowych o bardzo dużych możliwościach funkcjonalnych.

Rysunek 39 Poglądowy schemat architektury serwera Commerce 2000. [50]

Serwer umożliwia tworzenie dużych rozwiązań wykorzystujących takie zaawansowane elementy, jak analityczne narzędzia wspomagania sprzedaży, rozbudowane statystyki oparte o analityczne systemy hurtowni baz danych OLAP.

W chwili obecnej kluczowym elementem skuteczności sprzedaży jest odpowiednio bogata i atrakcyjna oferta. Aby osiągnąć ten cel, trzeba współpracować z wieloma dostawcami, przy czym im więcej ich jest, tym trudniej utrzymać ofertę aktualną, oraz obsłużyć zamówienia. Rozwiązaniem idealnym jest pełna automatyzacja procesów aktualizacji katalogów produktów i składania zamówień u dostawców. Przykład takiej automatycznej interakcji znajduje się na rysunku poniżej.

Rysunek 40 Przykładowa interakcja biznesowa inicjalizowana przez serwer Commerce 2000. [53]

W przedstawionej interakcji sklep internetowy zbudowany w oparciu o serwer Commerce 2000 wykorzystuje BizTalk 2000 do komunikacji w ramach tej samej sieci z serwerem finansowym firmy Great Plains, oraz poprzez Internet z innym serwerem BizTalk, który integruje serwer SAP, system spadkowy i system zbudowany w oparciu o standard EDI. Widzimy, jak bardzo skomplikowana była by tego typu interakcja, gdyby nie pośrednictwo serwerów BizTalk. Ponieważ są one tak pomocne w tworzeniu takich rozwiązań, współpraca serwerów Commerce 2000 i BizTalk 2000 została znacznie uproszczona. Serwer Commerce umożliwia:

• importowanie i eksportowanie katalogów produktów poprzez serwery BizTalk

• przetwarzanie zamówień do dowolnej liczby dostawców

Szczegółowe informacje na temat wykorzystania możliwości współpracy tych serwerów znajdują się w dokumentacji obydwu produktów [50][40].

1. Microsoft SQL Server 2000

SQL Server 2000 to kolejna edycja systemu bazy danych firmy Microsoft. Wśród wielu jego możliwości, bardzo istotną z punktu widzenia serwera BizTalk jest możliwość bezpośredniej interakcji w języku XML. Serwer ten jest także jego głównym silnikiem bazodanowym i jako taki stanowi z nim nierozerwalną całość.

2. Microsoft Host Integration Server 2000

Kolejny serwer z rodziny .NET - Microsoft Host Integration Server 2000 to serwer integrujący, umożliwia zastosowanie systemów spadkowych (ang. legacy) w rozwiązaniach opartych o architekturę DNA 2000. Przegląd jego możliwości przedstawia poniższy rysunek:

Rysunek 41 Możliwości integracyjne oferowane przez Microsoft Host Integration Server 2000 [51]

Wykorzystując możliwości oferowane przez Host Integration Server w rozwiązaniach opartych o serwer BizTalk, jesteśmy w stanie udostępnić wszystkie narzędzia interakcji biznesowej BizTalk również w przypadku systemów spadkowych i aplikacji opartych o serwery klasy mainframe. Jest to produkt znacznie upraszczający proces tworzenia rozwiązań integracyjnych w tego typu sytuacjach, ponieważ daje nam narzędzia do bezpośredniej interakcji z tego typu systemami, przy zachowaniu spójnej platformy programistycznej (Windows DNA 2000).

3. Visual Studio.NET

Wizualne środowisko programistyczne nowej generacji - Microsoft Visual Studio.NET - jest najlepszym narzędziem do tworzenia otoczenia rozwiązań opartych na serwerze BizTalk Server 2000. Pozwala między innymi na tworzenie komponentów COM+, które mogą zostać wkomponowane w proces biznesowy modelowany za pomocą harmonogramu XLANG, jak również komponentów integracyjnych AIC. Oprócz tego umożliwia tworzenie tzw. serwisów sieciowych (ang. web services). BizTalk Server nie wspiera ich na razie bezpośrednio, jednak Microsoft utrzymuje, że kolejne uaktualnienie będzie zawierało porty do nowych typów interfejsów informatycznych, których tworzenie umożliwia Visual Studio.NET.

1. Przykład wdrożenia Microsoft BizTalk Server 2000

Jednym z pierwszych realizacji systemu opartego o BizTalk Server 2000, rozpoczętą jeszcze przy wykorzystaniu pakietu BizTalk Jumpstart Kit jest implementacja procesów biznesowych obejmujących łańcuch dostaw produktów w brytyjskiej sieci sklepów „Marks & Spencer”[54]. Firma ta jest niekwestionowanym liderem w sprzedaży i produkcji ubrań i żywności w Wielkiej Brytanii, prowadząc ponad 300 sklepów w kraju i ponad 600 sklepów na całym świecie. Zaprojektowany i wdrożony system integruje wszystkie sprzedażowe procesy biznesowe zachodzące w sklepach na całym świecie, udostępniając, praktycznie w czasie rzeczywistym, szczegółową informację o wszystkich transakcjach mających miejsce w sieci „Marks & Spencer”, oraz automatyzując współpracę z działającymi w standardzie EDI systemami biznesowymi dostawców. System przetwarza obecnie około pół biliona transakcji w ciągu roku (dane na kwiecień 2001).

Część III: Projekt i implementacja przykładowej aplikacji wykorzystującej BizTalk Server 2000

• Założenia i metodologia pracy

Projekt ilustrujący wykorzystanie serwera BizTalk zostanie przygotowany w środowisku Windows, zgodnie z wytycznymi architektonicznymi Windows DNA 2000, przy użyciu następujących serwerów i narzędzi:

Serwer/Narzędzie	Rola pełniona w projekcie
Microsoft Windows Advanced Server 2000 SP1	system operacyjny
Microsoft SQL Server 2000	system zarządzania relacyjnymi bazami danych
Microsoft BizTalk Server 2000	integracja aplikacji i procesów biznesowych
Microsoft Visual Studio 6.0 SP4	rodzina narzędzi i kompilatorów, głównym językiem stosowanym w projekcie będzie Microsoft Visual Basic 6.0
Rational Rose 2000	środowisko CASE projektowania rozwiązań informatycznych, wykorzystujące język UML

Tabela 12 Narzędzia i serwery stosowane w projekcie.

• Dokumentacja projektu

Na dokumentację projektu realizowanego w ramach pracy składają się następujące dokumenty:

1. Dokument wizyjny, projekt funkcjonalny

Zawarte w osobnym dokumencie (OIRT - projekt funkcjonalny.doc).

2. Dokumentacja wykonawcza, projekt wykonawczy

Zawarte w osobnych dokumentach (dokumentacja papierowa - OIRT - projekt wykonawczy.doc, model UML Rational Rose - Model\OIRT.mdl).

• Literatura i referencje

1. Microsoft Corp., grudzień 2000, “BizTalk Framework 2.0: Document and Message Specification”, zamieszczone na towarzyszącym CD w pliku \Dokumentacja\BizTalkFramework20.doc

2. Microsoft Corp., 5 czerwca 2000, “BizTalk Orchestration Whitepaper”, zamieszczone na towarzyszącym CD w pliku \Dokumentacja\Orchestration.doc

3. W3C , “Extensible Markup Language (XML) 1.0 (Second Edition), W3C Recommendation 6 October 2000”, zamieszczone na towarzyszącym CD w pliku \Dokumentacja\REC-xml-20001006.pdf

4. Jacob Slonim, Abraham Schonbach, Michael A. Bauer, Lachlan J MacRae, Keith A.Thomas , „Building An Open System”, Van Nostrand Reinhold Company Inc. 1987

5. Hans-Jochen Schneider (Hrsg.), „Lexikon der Informatik und Daten-verarbeitung, 3. Auflatge”, R.Oldenbourg Verlag München Wien 1991

6. W3C , „Simple Object Access Protocol (SOAP) 1.1“, W3C Note 08 May 2000 (http://www.w3.org/TR/SOAP)

7. Brian E.Travis , „XML and SOAP Programming for BizTalk Servers“, Microsoft Press 2000

8. William J. Pardi, „XML in Action, Web Technology“, Microsoft Press 1999

9. Microsoft Corp., Dokumentacja elektroniczna Microsoft BizTalk 2000 Beta 2

10. Microsoft Corp., Dokumentacja elektroniczna Microsoft BizTalk 2000 RTM

11. Microsoft Corp., Dokumentacja elektroniczna Microsoft BizTalk Jumpstart Kit

12. W3C, http://www.w3.org/Addressing/

13. Oficjalna strona grupy pl.rec.xml, http://www.xml.pl/

14. T. Berners-Lee, R. Fielding, L. Masinter , IETF RFC 2396 „Uniform Resource Identifiers (URI): Generic Syntax”, 1998 (http://www.ietf.org/rfc/rfc2396.txt)

15. Microsoft Corp., MSDN On-line (http://msdn.microsoft.com/)

16. Microsoft Corp., XDR Schema Developer's Guide (http://msdn.microsoft.com/library/psdk/xmlsdk/xmlp3lpv.htm)

17. W3C, XML Schema Part 0: Primer, W3C Candidate Recommendation 24 October 2000 (http://www.w3.org/TR/2000/CR-xmlschema-0-20001024/), (\Dokumentacja\XML Schema Part 0 Primer.htm)

18. W3C, XML Schema Part 1: Structures, W3C Candidate Recommendation 24 October 2000 (http://www.w3.org/TR/2000/CR-xmlschema-1-20001024/), (\Dokumentacja\XML Schema Part 1 Structures.htm)

19. W3C, XML Schema Part 2: Datatypes, W3C Candidate Recommendation 24 October 2000 (http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/), (\Dokumentacja\XML Schema Part 2 Datatypes.htm)

20. XML-Data reduced DRAFT, 3 July 1998, Version 0.21 (http://www.ltg.ed.ac.uk/~ht/XMLData-Reduced.htm), (\Dokumentacja\XML Data Reduced.htm)

21. W3C, XML-Data, W3C Note 05 Jan 1998 (Dokumentacja\XML-Data.htm)

22. XML Authority (http://www.extensibility.com/)

23. W3C, XSL Transformations (XSLT) Version 1.0, W3C Recommendation 16 November 1999 (http://www.w3.org/TR/xslt.html/), (Dokumentacja\XSL Transformations (XSLT).htm)

24. W3C, Extensible Stylesheet Language (XSL) Version 1.0, W3C Candidate Recommendation 21 November 2000 (http://www.w3.org/TR/2000/CR-xsl-20001121/xslspec.html/), (Dokumentacja\xs001121.zip)

25. W3C, Namespaces in XML (http://www.w3.org/TR/REC-xml-names/), (Dokumentacja\Namespaces in XML.htm)

26. W3C, XML Linking Language (XLink) Version 1.0, W3C Proposed Recommendation 20 December 2000 (http://www.w3.org/TR/xlink/), (Dokumentacja\XML Linking Language (XLink) Version 1_0.htm)

27. W3C, XML Pointer Language (XPointer) Version 1.0, W3C Last Call Working Draft 8 January 2001 (http://www.w3.org/TR/xptr), (Dokumentacja\XML Pointer Language (XPointer) Version 1_0.htm)

28. Microsoft Corp., Microsoft Windows DNA XML Resource Kit CD, czerwiec 2000

29. Microsoft Corp., Microsoft XML Developer Center (http://msdn.microsoft.com/xml)

30. DISA, http://www.x12.org - Accredited Standards Committee (ASC) X12

31. http://www.reims.net/Resource_Zones/EDI/edi_resources/

32. DISA, http://www.disa.org/ - DISA - Accredited Standards Committee X.12 (ASCX.12)

33. Seagate Corp, http://www.seagate.com/support/edi/edimenu.html - Seagate - Typy dokumentów EDI

34. http://www.hkstar.com/~alanchan/papers/edi/ - Introduction to Electronic Data Interchange (EDI)

35. http://www.cla.org/RuhBook/chp7.htm - EDI Implementation, fragment książki ”The Internet and Business: A Lawyer's Guide to the Emerging Legal Issues”

36. http://spuds.cpsc.ucalgary.ca/courses/547-96/wallacea/547/Pres/ - Electronic Data Interchange (EDI) and Electronic Fund$ Transfer (EFT)

37. http://www.vbxml.com/b2b/

38. BizTalk™ Initiative, http://www.biztalk.org

39. Microsoft Corp., Materiały seminaryjne konferencji “Microsoft Developer Days 2000”, Warszawa

1. Nagender Vedula , “9-203 - BizTalk Server 2000™ Functional Overview”

2. Kevin McCall, “9-202 - BizTalk™ Initative for Automating Business Process Orchestration”

3. John Ballard, “9-310 - BizTalk™ Server 2000 Management, Administration, And Tracking Tools”

40. Microsoft Corp., Dokumentacja elektroniczna Microsoft BizTalk Server 2000 (pliki pomocy)

41. Microsoft Corp., http://msdn.microsoft.com/library/techart/BTSOrch.htm - BizTalk Orchestration: Transactions, Exceptions, Debugging

42. IETF, The MIME Multipart/Related Content-type (http://www.ietf.org/rfc/rfc2387.txt)

43. IETF, S/MIME Version 3 Message Specification (http://www.ietf.org/rfc/rfc2633.txt)

44. SAP Corp., http://ifr.sap.com/ - SAP Interface Repository

45. Usenet, w szczególności grupy microsoft.public.biztalk.*

46. Sebastian Zakłada, „ActiveX w zastosowaniach internetowych” - http://www.ci.pwr.wroc.pl/~zaklada

47. Microsoft Corp., http://msdn.microsoft.com/library/techart/LegacyFileInt.html - Legacy File Integration Using Microsoft BizTalk Server 2000

48. Praca zbiorowa, “Microsoft BizTalk Server 2000 Documented”, Microsoft Press 2001

49. Microsoft Corp., http://msdn.microsoft.com/library/techart/ - Writing custom parsers and serializers

50. Microsoft Corp., Dokumentacja elektroniczna Microsoft Commerce Server 2000 (pliki pomocy)

51. Microsoft Corp., Dokumentacja elektronicznia Microsoft Host Integration Server 2000, „Application Integration Services”

52. Kelley DuBois, “Building B2B Applications Using Commerce Server And BizTalk™”, Microsoft Corporation, TechEd 2000 Presentation 2-303

53. Microsoft Corp., “Duluth Mutual Life - przykład automatyzacji procesu zamówienia przy pomocy BizTalk Server 2000”, prezentacja multimedialna (\Seminarium\default.htm)

54. Microsoft Corp., „Marks & Spencer Case Study”, marzec 2001 (http://www.microsoft.com/business/downloads/value/marksspencer.doc)

kwestię standaryzacji poruszam w dalszej części pracy

więcej informacji na temat dokumentów samoopisujących się znajduje się w dalszej części pracy

więcej na temat encji przy okazji opisu języka XML

Dość powiedzieć, że specyfikacja tego metajęzyka ma około 155 stron maszynopisu!

Obecnie dostępna jest rozszerzona specyfikacja w formie dokumentu Second Edition, „XML 1.0 SE W3C Recommendation” z dnia 6 października 2000.

Bardzo szybko można przygotować implementację prostego procesora języka. Również edycja i analiza dokumentu przebiega bardzo sprawnie.

Więcej informacji o elementach oraz strukturze dokumentu XML w rozdziale 3.1.2

Więcej na temat zasad DTD i wynikającej z deklaracji typu dokumentu poprawności strukturalnej w dalszej części pracy.

Więcej na temat encji w dalszej części pracy.

Uwaga - liczby umieszczone po lewej stronie nie są częścią DTD, zostały tam umieszczone aby umożliwić późniejsze odniesienia do konkretnych linii kodu w części objaśniającej.

Więcej o przestrzeniach nazw w rozdziale 3.4.1

Więcej o tego typu systemach w rodziale 5.

Więcej o narzędziach BizTalk Server 2000 w rodziale 10.4

Wspomnę o tym szerzej w dalszej części pracy.

Z małymi wyjątkami wymuszonymi poprzez brak formalnej specyfikacji standardu w trakcie powstawania procesora.

W dosłownym tłumaczeniu dehydrated znaczy odwodniony, ale określenie to nie brzmi dobrze w języku polskim. Kierując się istotą stanu opisywanego przez ten zwrot, zdecydowałem się przyjąć tłumaczenie zamrożony.

W tym celu trzeba odpowiedno skonfigurować obiekty Komunikacji BizTalk odpowiedzialne za przetwarzanie tego typu dokumentu, wskazując pola, które mają być poddawane śledzeniu

Więcej informacji na temat funkcji odbierających zawiera Tabela 8

Scott Woodgate, BizTalk Development Team. Wypowiedź z konferencji Microsoft TechEd 2001, która odbyła się w dniach 3 - 6 lipca w Barcelonie.

Integracja systemów biznesowych przy pomocy BizTalk i XML. praca magisterska 87 z 87

specyfikacja punktu docelowego

specyfikacja źródła

<XML>

<XML>

dokument

wyjściowy

dokument

wejściowy

publikator

mapa XSLT

parser

integracja BizTalk

EDI

do zewnętrznych organizacji

serwer EDI

serwer BizTalk

koncentrator

aplikacje wewnątrz przedsiębiorstwa

specyfikacja punktu docelowego

specyfikacja źródła

<XML>

<XML>

dokument

wyjściowy

dokument

wejściowy

publikator

transformacja XSLT

parser

plik tekstowy

rozdzielenie (fork)

połączenie (join)

warstwa

pośrednicząca

poczta elektroniczna

handel elektroniczny

strony WWW

repozytorium dokumentów

logistyka

system płatności elektronicznej

administracja

zarządzanie kontami użytkowników

przepływ informacji

płatności

systemy zewnętrzne

system pomocy telefonicznej

rozsyłka dokumentów

giełda ofert

raportowanie

finanse

baza danych

zarządzanie kontaktami z klientam (CRM)

hurtownia danych

system księgowy

transport

serwer BFC

aplikacja

transport

serwer BFC

aplikacja

System B

System A

Szkielet BizTalk

5

4

3

2

1

zdalny

komponent

serwer SOAP

klient SOAP

Wynik

Żądanie

wywołania

metody

Internet

INTERNET / VPN

ogólny format wymiany danych

odwzorowanie danych

SAP IDOC

plik tekstowy stałej szerokości

odwzorowanie danych

APLIKACJA B

system finansowy SAP

APLIKACJA A

system sprzedaży detalicznej

SAP IDOC

plik tekstowy stałej szerokości

proces odwzorowania danych

APLIKACJA B

system finansowy SAP

APLIKACJA A

system sprzedaży detalicznej

{\c0\b Transformacja XSL\par}

<P COLOR=Black>

<B>Transformacja XSL</B>

</P>

4.

3.

2.

1.

Drzewo wynikowe xmlns:fo

XSL

<fo:block font-style=”bold” color=”black” xmlns:fo=http://www.w3.org/TR/WD-xsl/FO>Transformacja XSL</fo:block>

Arkusz styli xmlns:xls

eBook

HTML

RTF

Formatowanie C

Formatowanie

B

Formatowanie

A

Transformacja XSL

<CHAPTER>Transformacja XSL</CHAPTER>

Drzewo źródłowe

<xsl:template match=”CHAPTER”>

<fo:block font-style=”bold” color=”black”>

<xsl:apply-templates/>

</fo:block>

</xsl:template>

Chiny

Dania

USA

Rosja

Niemcy

Kanada

Polska

Kupujący

Sprzedawca

Ilość	Opis	Cena	Suma
100	Narty	12	1200
200	Kask narc.	3	600
100	Buty narc.	6	600
			2400

Numer faktury: 1300/2001

Data wystawienia: 1.06.2001

Klient

FAKTURA

<!DOCTYPE ...>

<?xml version=”1.0” ... ?>

Zagnieżdżone elementy

Zagnieżdżone elementy

Zagnieżdżone elementy

Główny element dokumentu

PROLOG

Odwzorowanie dokumentów XML

---