Systemy zarządzania treścią (Część 3). Elektroniczna wymiana danych

Prezentacja na temat: "Systemy zarządzania treścią (Część 3). Elektroniczna wymiana danych"— Zapis prezentacji:

1 Systemy zarządzania treścią (Część 3). Elektroniczna wymiana danych
4 grudnia 2003

2 Konfigurowanie produktów i generowanie dokumentacji
Problem: produkt występuje w wielu wariantach, różniących się od siebie szczegółami, dokumentacja produktu powinna być dedykowana dla danego modelu, jak uniknąć tworzenia wielu podobnych wariantów dokumentacji? Analiza: dokumentacja każdego modelu ma identyczną strukturę, dokumentacja różnych modeli różni się treścią wybranych sekcji. Rozwiązanie: zdefiniować szablon dokumentacji, określający: strukturę (rozdziały, sekcje, ...), parametry wyboru konkretnej wersji sekcji; przygotować możliwe warianty każdej sekcji, określić parametry modelu i wygenerować dedykowaną dokumentację.

3 Szablon dokumentacji – przykład

4 Konfigurowanie produktu – przykład
Category: Cars Requirement: transmission-type Requirement: engine-type Requirement: radio-type Product: Locano Transmission-type: standard, automatic Engine-type: V6, V8 Radio-type: standard, CD Player Templates: Owner Manual, Maintenance Manual Model: Locano L600A: Transmission-type: automatic Engine-type: V6 Radio-type: CD Player

5 Rezultat: instrukcja obsługi
Locano L600A Owner’s Manual Operating Instructions Driving Your Car Using Your CD Player-AM/FM Radio Maintenance Instructions Changing the Oil [create content] Type: Chapter Info type: maint-info Engine-type: V6 Washing Your Car

6 XML: jedno źródło, wiele publikacji
treść + znaczenie XSL skład i łamanie XSL Styl elegancki  Styl COOL! Przeglądarka Styl standardowy Przeglądarka

7 Publikowanie WWW – dzisiaj
Wygląd połączony z danymi. Skrypty generujące stronę w Perlu, PHP, ASP zawierające kawałki kodu HTML. Niedoskonały język komunikacji – HTML. Strona WWW nie może być źródłem informacji dla innego komputera. Brak podziału ról: redakcja treści, redakcja graficzna, organizacja.

8 Publikowanie WWW w modelu trójwarstwowym
Bazy danych XML Artykuł Serwer WWW XML Wynikowy XML TXT HTML Pliki Przeglądarka XML Nagłówek XSL XML Konfigu- racja Inne źródła XML można wykorzystać do uelastycznienia obecnie stosowanego dwuwarstwowego modelu serwowania stron WWW. Może on być wówczas stosowany jako warstwa pośrednia pomiędzy różnymi źródłami danych a wynikowymi postaciami strony. Transformacje o których tu mowa mogą być przeprowadzane zarówno dynamicznie – po każdym zapytaniu otrzymanym przez serwer, jak i statycznie – przed opublikowaniem plików wynikowych na serwerze. Pierwszy, dynamiczny model realizuje np. serwer Cocoon.

9 XML w serwisach WWW XML konwertowany na HTML po stronie serwera:
statycznie, dynamicznie. XML interpretowany przez przeglądarkę: np. Microsoft Internet Explorer 6.x. Sposób konwersji: XSL – Extensible Stylesheet Language. Konwertowanie statyczne oznacza przeprowadzenie konwersji przed opublikowaniem materiałów – są one wówczas de facto serwowane jako HTML. Konwersja dynamiczna jest przeprowadzana „w locie” za każdym razem, gdy użytkownik ściąga stronę. Na serwerze są więc przechowywane jedynie pliki źródłowe XML. Wybór sposobu konwersji zależy przede wszystkim od częstotliwości uaktualnień zawartości witryny. Jeśli chcemy, aby każda zmiana wprowadzona przez autora była od razu widoczna jako opublikowana, to zapewne zdecydujemy się na konwersje dynamiczne. Konwersja po stronie klienta odciąża serwer. Wymaga jednak, aby klient (przeglądarka) potrafiła taką konwersję wykonać. Może to zawęzić grono potencjalnych czytelników strony. XSL jest językiem opisu sposobu wizualizacji dokumentu XML, pozwalającym jednocześnie na wykonywanie zaawansowanych transformacji dokumentu.

10 Geneza elektronicznej wymiany danych (EDI)
Problemy z automatyzacją procesów między przedsiębiorstwami. "Izolowane wyspy" Przedsiębiorstwa najpierw automatyzują wewnętrzne procesy wymiany dokumentów. Połączenie między przedsiębiorstwami nie jest jednak zwykle możliwe bezpośrednio, ze względu na różne platformy sprzętowe, aplikacje i formaty danych. Dlatego wymiana dokumentów między przedsiębiorstwami pozostaje w postaci tradycyjnej – papierowej. Różne rodzaje „zygzaków” reprezentują różne formaty kodowania informacji (komunikatów).

11 Pojedyncze rozwiązania
Wielka korporacja dostarcza kontrahentom narzędzia dostosowujące do własnego formatu. Wielka korporacja wymusza na kontrahentach dostosowanie do swojego formatu. Schemat przedstawia drugi z wymienionych wariantów, w którym konwersję implementuje mniejszy kontrahent.

12 Standard Standardy EDI
EDIFACT – United Nations Standard Messages Directory for Electronic Data Interchange For Administration, Commerce and Transport. ANSI Accredited Standards Committee X12 sub-group. Standard Dlatego opracowano standardowe metody kodowania i przesyania komunikatów EDI. EDIFACT jest rozpowszechniony w Europie, zaś X12 jest bardziej popularny za oceanem. Wykorzystanie standardu wymaga zastosowania konwerterów – ale tym razem tylko jednego na system. Konwertery są zwykle dostarczane wraz z systemami klasy ERP.

13 Nowa EDI Pomysł: zakodować strukturę dokumentu EDI przy pomocy elementów XML. <faktura> <dostawca> <nazwa>empolis Polska sp. z o.o.</nazwa> <adres>ul. Płocka 5a</adres> <kod>01-231</kod> <miasto>Warszawa</miasto> </dostawca> ... </faktura> N1*BY*92*1287 N1*ST*92*87447 N1*ZZ*992*1287 PO1*1*1*EA*13.33**CB* 80211*IZ*364*UP*

14 Tradycyjna EDI – XML EDI
Format dokumentów zapisany w specyfikacji. „Samoopisujący się” format dokumentów. Zwięzłe komunikaty, zawierające tylko niezbędne dane. Rozwlekłe komunikaty – narzut na „samoopisywanie się”. Scentralizowana, trudna zmiana standardu. Możliwość tworzenia własnych odmian standardów. Zmiany standardu pociągają uciążliwe zmiany oprogramowania. Większość problemów ze zmianą standardu bierze na siebie parser XML. Komunikaty EDIFACT zawierają jedynie dane, oddzielone od siebie odpowiednimi separatorami. Znaczenie każdej danej jest opisane w specyfikacji. Komunikaty EDIFACT są więc stosunkowo zwięzłe. W przeciwieństwie do nich, dokumenty XML zawierają nazwy elementów i atrybutów, które są w pewnym sensie informacją nadmiarową, powodującą rozwlekłość komunikatu. Dzięki temu XML jest jednak bardziej elastyczny i odporny na zmiany, bowiem aplikacje korzystające z komunikatów XML nie muszą mieć „zakodowanej w sobie” specyfikacji formatu komunikatu, lecz mogą być sparametryzowane strukturą komunikatu zawartą w samej jego treści.

15 Tradycyjna EDI – XML EDI
Przetwarzanie przez specjalne aplikacje Interakcja przy pomocy przeglądarki Implementowanie od podstaw Możliwość korzystania z gotowych narzędzi Łącza dedykowane dla EDI (Value Added Networks) Internet + bezpieczne protokoły Tradycyjne dokumenty EDI wymagają specjalnych aplikacji do ich przetwarzania, z reguły pisanych od zera. W przypadku XML EDI, możemy wykorzystać istniejące parsery XML-a i inne moduły programistyczne wspierające przetwarzanie dokumentów XML. Tradycyjna EDI jest zwykle realizowana na dedykowanych łączach, tzw. Value Added Networks (VAN). Dostawca takich łącz dzierżawi je zwykle od korporacji telekomunikacyjnej, dodając usługi takie jak wykrywanie błędów, bezpieczeństwo komunikatów. Takie usługi są kosztowne, w przeciwieństwie do Internetu, za który i tak się płaci, niezależnie od tego, czy korzysta z niego EDI. Możliwość integracji z tradycyjnymi systemami EDI

16 Elastyczność XML EDI empolis Polska
<firma nazwa=”empolis Polska” adres=”Płocka 5a” kod=”01-231” miasto=”Warszawa” /> <firma nazwa=”empolis Polska” /> empolis Polska Adres: Płocka 5a Kod: Miasto: Warszawa Tel. Pewne zmiany w ustalonym formacie danych mogą się obejść bez jakichkolwiek poprawek oprogramowania. Przykład: można stosować różne zestawy atrybutów opisujących firmę. Dodanie nowego atrybutu nie powoduje błędnego działania aplikacji, która takiego atrybutu nie oczekuje – jest on przez nią ignorowany. <firma nazwa=”empolis Polska” adres=”Płocka 5a” miasto=”Warszawa” />

17 XML EDI a przeglądarki internetowe
Najnowsze wersje przeglądarek wspomagają wyświetlanie dokumentów XML. XSL jako język opisu formatowania. Nowe zastosowanie EDI: podstawowa funkcjonalność – wymiana danych między aplikacjami przedsiębiorstw, nowe perspektywy: kontakt z klientami wyposażonymi tylko w przeglądarki, E-Commerce. Dzięki przeglądarkom można myśleć o wykorzystaniu technologii XML EDI wszędzie tam, gdzie klient nie zawsze jest wyposażony w systemy komputerowe wspierające EDI, a więc np. w sklepach internetowych, w firmach kurierskich (klient śledzi drogę przesyłki), itp.

18 Inicjatywy standaryzacji XML-EDI
XML jest zbyt elastyczny. Inicjatywy standaryzacyjne: ogólne – dążą do ukierunkowania tej elastyczności, aby: można było wymieniać informacje dowolnego typu, informacje jednego typu były tak samo reprezentowane; branżowe – standaryzują konkretne komunikaty. XML pozwala zamodelować i zakodować wszystko. Niestety, ten sam byt można zakodować na wiele sposobów, różniących się choćby nazwami elementów. Inicjatywy w różny sposób próbują ograniczyć tą dowolność, która w końcu może przeszkadzać w integracji. Inicjatywy tego typu dość intensywnie pączkują, tworzą się i upadają. Wśród inicjatyw ogólnych, nie związanych z konkretną branżą, najważniejsza to ebXML. XML

19 ebXML ebXML: zbiór specyfikacji definiujących sposób prowadzenia biznesu i wymiany danych przez Internet, zaakceptowane 14 maja 2001 r., oczekiwane implementacje i wsparcie w istniejących systemach, wsparcie przez inne inicjatywy standaryzacyjne. Electronic Business XML Working Group: założona we wrześniu 1999 r., ok. 150 specjalistów, patronat OASIS i UN/CEFACT. Po 18 miesiącach prac, specyfikacje ebXML zostały zaakceptowane. Pojawiają się już pierwsze implementacje. Inicjatywa ebXML wygląda na najpoważniejszą na rynku i można wróżyć jej sukces. Znamienne jest, że powstała ona jedynie w celu zaprojektowania XML-owej ramy dla EDI, zaś nie zamierza nią zarządzać, rozpatrując przekazanie tej działalności (wraz z ewentualnym połączeniem) jednej z istniejących inicjatyw. Jest to o tyle prawdopodobne, że niektóre inne inicjatywy (np. RosettaNet, zajmująca się standaryzacją w branży informatycznej i elektronicznej) przejmują idee ebXML i stosują je w swoich rozwiązaniach.

20 Podejście do standaryzacji
Meta-model pozwalający na opracowywanie modeli specyficznych dla zastosowań: zbiór podstawowych schematów, elementów XML oraz procesów biznesowych, sposób definiowania słowników danych, nie definiuje konkretnych, docelowych komunikatów. Metainformacje: informacje o wersjach, metadane odpowiadające nagłówkom z istniejących systemów EDI. Ramy architektury technicznej: sposoby implementacji repozytoriów, serwisów, itp., integracja z istniejącymi technologiami EDI. Grupa ebXML zaprojektowała ramę pozwalającą na opracowywanie specyficznych sub-standardów. Jej podstawą będzie repozytorium przechowujące typowe obiekty (schematy, elementy, encje). ebXML zakłada od początku integrację z istniejącymi technologiami. Podstawowy zbiór komponentów, używanych niezależnie od technologii, zostanie bowiem opisany w sposób niezależny od konkretnej implementacji. ebXML będzie ponadto wspierać konwersje i migracje z innych technologii.

21 Inicjatywy branżowe SWIFT, RosettaNet,
Automotive Industry Action Group, Health Level Seven, Open Applications Group, Open Travel Alliance, ... Wiele inicjatyw ma charakter branżowy i stara się wystandaryzować komunikaty związane z wymianą dokumentów dotyczących danej branży. Wiele z nich wykorzysta zapewne koncepcje ebXML, w ramach których implementowane będą specyficzne dla zastosowań komunikaty, opracowane przez te inicjatywy. SWIFT jest standardem wymiany informacji między bankami nie wykorzystującym XML-a. jednak organizacja SWIFT deklaruje, że przejście na XML jest jej priorytetem. Nowy standard będzie połączeniem FIX i FpML-a.

22 Gdzie szukać dalej B. Marchal, Electronic Data Interchange on the Internet: developer.netscape.com/viewsource/marchal_edata.htm M. Bryan et. al., Guidelines for using XML for Electronic Data Interchange XML/EDI Group's Home Page: EDISON – Narodowy Operator EDI: S. Zioło, R. Księżyk, Wykorzystanie języka XML w EDI Materiały na VIII Krajową Konferencję EDI-EC, Wydawca: Niedźwiedziński Consulting, Łódź, 2000 Treść rekomendacji XML. „Kuźnia standardów internetowych” – organizacja zajmująca się ich zatwierdzaniem i promowaniem. Duży zbiór materiałów, artykułów itp. Nowości, zasoby, lista organizacji zajmujących się XML-em itp. Między innymi potężny zbiór referencji do narzędzi XML-owych. Tutorial po polsku – dla początkujących.