Koncept infrastruktury a nástrojů pro práci s ICS

Autodesk Academia Grant 2005

Koncept infrastruktury a nástrojů pro práci s ICS Návrh na propojení produktů Autodesku s technologií .NET

Vypracovali: Vlastimil Kaluža Jiří Špaček

Obsah 1. Předmluva ............................................................................. 3 2. Úvod ...................................................................................... 4 2.1. Seznam zkratek ................................................................ 4 3. Úvod do webových služeb ..................................................... 5 3.1. Vývoj webových služeb....................................................... 5 3.2. Webová služba a webová aplikace........................................ 7 3.3. Princip webových služeb ..................................................... 9 3.4. Základ webových služeb ....................................................10 3.5. SOAP ..............................................................................11 3.6. WSDL .............................................................................11 3.7. UDDI ..............................................................................11 3.8. Jak webová služba funguje.................................................12 4. Podrobný popis UDDI .......................................................... 14 4.1. Specifikace UDDI ..............................................................15 4.2. Datové struktury UDDI ......................................................16 4.3. Programové rozhraní UDDI (UDDI API) ................................17 4.4. Inquiry API ......................................................................18 4.5. Publication API (a primární klíče UDDI) ................................19 4.6. Zprávy ............................................................................22 4.6.1. Zprávy typu Inquiry .......................................................23 4.6.2. Zprávy typu Publishing ...................................................23 4.6.3. Zprávy typu Response ....................................................24 4.7. Společné přístupové body (Common Access Points) ...............25 4.8. Datový model UDDI ..........................................................25 4.9. Identifikátory ...................................................................28 4.10. Kategorizace ....................................................................30 5. Úvod do UML ....................................................................... 34 5.1. Použití UML......................................................................35 5.2. Základní stavební bloky .....................................................36 5.3. Předměty ........................................................................36 5.4. Relace.............................................................................38 5.5. Diagramy ........................................................................39 5.6. Komerční produkty pro práci s UML .....................................39 5.7. Produkty šířené pod GPL a podobnými licencemi ...................39 6. Spojení ICS s aplikací Autodesku......................................... 40 6.1. Základní informace o návrhu ..............................................41 6.2. Návrh infrastruktury na straně klienta .................................41 6.3. Napojení infrastruktury na aplikaci Autodesk ........................43 6.4. Infrastruktura na straně serveru .........................................47 7. Literatura ............................................................................ 49

1. Předmluva Cílem tohoto projektu je vypracovat návrh infrastruktur pro tvorbu nových ICS, jejich vyhledávání v rámci sítě Internet, nástrojů pro jejich správu a práci s nimi v produktech firmy Autodesk s technologií .NET od společnosti Microsoft. Důvodem je, že většina produktů firmy Autodesk v současné době pracuje na operačních systémech této společnosti. V současné době neexistuje v České republice řešení podobného druhu, které by bylo všeobecně známé, dostupné a použitelné širokou odbornou veřejností ve školství a komerční sféře. Firma Autodesk výrazně využívá prostředí intra/internetu a oblast .NET technologií Microsoftu se také stává základní platformou pro další vývoj iDesign technologií.

2. Úvod První část je věnována popisu webových služeb. Druhá část je věnována UDDI, které je stěžejní technologií pro definování a vyhledávání požadovaných webových služeb. Třetí část je věnována popisu UML, což je standard pro modelování jednoduchých i složitých aplikací pomocí formální syntaxe. Čtvrtá část je věnována vlastnímu popisu modelu internetové CAD služby. Tento projekt by měl sloužit správcům počítačového vybavení škol při zřizování vlastních serverů se službami pro výuku a nastavení parametrů pro využití serverů firmy Autodesk a jiných serverů. Dále by měl sloužit jako inspirace pro návrháře jednotlivých webových služeb, které by tak měly co nejlépe sloužit nejen k další výuce, ale i pro komerční oblast. Taktéž poslouží jednotlivým konstruktérům, při vyhledávání, přidávání a používání jednotlivých služeb.

2.1.Seznam zkratek Zkratka HTTP

XML

SOAP WSDL UDDI UML W3C RPC

Popis HyperText Transfer Protocol protokol pro přenos webových stránek eXtensible Markup Language standardní jazyk pro zápis strukturovaných informací v textové podobě; hlavním rysem standardu XML je rozšiřitelnost zápisu a existence nástrojů pro automatickou kontrolu a konverzi dat zapsaných v jazyce XML Simple Object Access Protocol standard konsorcia W3C pro komunikaci v prostředí internetu; hlavním rysem standardu SOAP je přenos dat v textové podobě vytvořené v jazyce XML Web Services Description Language standard konsorcia W3C pro popis webových služeb Universal Description, Discovery and Integration standard konsorcia UDDI, který popisuje webovou službu určenou k registraci a vyhledávání dalších webových služeb Unified Modeling Language standardní grafický jazyk pro popis architektury programu World Wide Web Consortium konsorcium pro vývoj webových technologií Remote Procedure Call metoda volání procedur na dálku po síti; hlavním rysem metody RPC je automatické generování kódu, který maskuje komunikaci po síti jako volání procedur, z popisu rozhraní těchto procedur

3. Úvod do webových služeb O webových službách se mluví mezi odbornou veřejností již delší dobu, nicméně teprve v posledních letech, zejména od doby nástupu .NET technologie firmy Microsoft, se zdá, že se webové služby budou stále více rozšiřovat pro běžné použití širokou veřejností. Máme-li webové služby definovat, potom bude zřejmě nejvýstižnější následující

tvrzení:

webové

technologie

umožňují

integrovat

libovolné aplikace provozované na různých platformách a ovládat je

prostřednictvím

webového

rozhraní,

tedy

z

běžného

internetového prohlížeče. Společnost IBM nabízí jinou, technicky přesnější, definici: webové služby jsou nové služby charakteristické třístupňovým zásobníkem s technologiemi SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) a UDDI (Universal Discovery, Description and Integration). Mottem

většiny

strategií,

které

v

oblasti

webových

služeb

softwarové firmy prezentují, je informace kdekoliv. Znamená to, že k datům by měl být možný přístup kdekoliv a z jakéhokoliv zařízení (PDA, mobilní telefon, notebook či stolní počítač). Webové služby by měly fungovat jako více či méně univerzální prostředník (rozhraní) mezi firmou (aplikací) a uživateli.

3.1.Vývoj webových služeb Internet se ve svém vývoji dostává do třetí etapy či generace: •

První generaci představují statické (HTML) stránky určené k přenosu informací směrem od serveru ke klientovi.

•

Druhá generace jsou interaktivní stránky s podporou obousměrné komunikace klient - server. V obou případech je příjemcem informace člověk.

•

Třetí

generace

internetu

(programování

webu)

se

vyznačuje

webovými službami, které jsou jejím dominantním představitelem.

Příjemcem informace se může stát stroj a člověk hodnotí výsledky vzájemné webové komunikace počítačů. Technologie webových služeb není ve světě počítačové vědy revolucí, ale evolucí starých koncepcí vývoje softwaru na bázi komponentů. [1] Úsilí o zvýšení efektivnosti programování vedlo v 80. letech minulého století ke vzniku objektově orientovaného programování. Definování a opakované využívání

objektů

a

využívání

tříd

postupně

pronikalo

do

všech

programovacích jazyků, vývojových prostředí a technologií, někde ve větší, jinde v menší míře. Nejdříve se využívaly knihovny tříd, později dynamicky připojené knihovny. V první polovině 90. let tento vývoj vyvrcholil tvorbou a využíváním komponentů - objektů COM (Component Object Model). Ve druhé polovině 90. let se v podobě DCOM (distributed COM) podařilo překročit hranici jednoho počítače, čímž byla vytvořena možnost, aby program běžící na jednom počítači v síťovém prostředí využíval

třídy

umístěné

na

jiném

počítači.

Webové

služby

jsou

pokračováním této expanze za hranice počítače – umožňují překročení hranice jedné platformy, programovacího jazyka a dokonce i síťového protokolu. [2] Vývoj internetu založený na postupné inovaci jednotlivých standardů znázorňuje obr. 1.

Obrázek č. 1: Vývoj webových technologií [3]

3.2. Webová služba a webová aplikace Mezi tradičními webovými aplikacemi a webovými službami existují tři podstatné rozdíly: •

webové služby využívají místo zpráv MIME zprávy SOAP,

•

webové služby nejsou typu http,

•

webové služby poskytují metadata popisující zprávy, které produkují a konzumují.

První rozdíl je v tom, že webová služba komunikuje pomocí zpráv typu SOAP. SOAP formalizuje použití XML jako způsobu přenosu údajů mezi dvěma procesy, definuje rámcový model pro rozšiřitelnost a verze protokolu, způsob přenosu chybových informací a způsob zasílání zpráv přes HTTP. Tělo zprávy SOAP obsahuje jakýkoli XML obsah posílaný aplikací. Posun od zprávy typu MIME k XML zprávám souvisí s podstatným rozdílem mezi klientem tradiční webové aplikace (prohlížečem) a klientem webové služby. Prohlížeče obyčejně pouze provázejí (rendují) HTML (HyperText Mark-up Language) stránky (nebo jiné údaje typu MIME, jako jsou například obrázky) a interpretaci zobrazené informace ponechávají na uživateli. Klient webové služby naopak většinou potřebuje interpretovat údaje, které dostal, a něco smysluplného s nimi poté udělat - dokonce nemusí mít ani uživatelské rozhraní. XML představuje standardní způsob reprezentace

a

správy

údajů

a

nástroje

pro

práci

s

XML

jsou

všudypřítomné, takže jeho volba jako formátu pro webové služby je zcela logická. Druhým velkým rozdílem mezi webovou službou a tradiční webovou aplikací je to, že webová služba je nezávislá na transportním protokolu. SOAP specifikace pouze definuje jak poslat SOAP zprávu přes HTTP (a dnes to dělá převážná většina webových služeb), ale je možné použít i jiný přenosový protokol. Je možné použít SMTP (Simple Mail Transfer Protocol), čisté TCP (Transmission Control Protocol) nebo protokol přímých zpráv jako Jabber či libovolný jiný protokol. Ačkoli většina SOAP zpráv

bude v blízké budoucnosti posílaná přes HTTP, schopnost použít jiné protokoly je velmi důležitá. HTTP není určeno na podporu dlouhotrvajících požadavků nebo potvrzení události odeslání klientem. Tyto problémy jsou lépe řešené v jiných protokolech a jejich standardizovaná podpora se v blízké budoucnosti očekává. Třetím podstatným rozdílem je skutečnost, že webová služba je samopopisující. Poskytuje metadata popisující produkované a konzumované zprávy, modely výměny zpráv na vyjádření režimu činnosti, použitý fyzický transportní protokol a logickou adresnou informaci potřebnou na její vyvolání. Formáty zpráv webových služeb jsou definované pomocí XML schémat XSD (XML Schema Definition). XML schéma je dostatečně flexibilní k popisu širokého rozsahu struktur zpráv, včetně otevřených modelů obsahu (open content models) s jemným řízením rozšiřitelnosti, což je kritické pro služby, jež mají být volně vázané. [10]

Obrázek č. 2: Schéma webové aplikace [8]

Obrázek č. 3: Schéma webové služby [8]

3.3. Princip webových služeb Jednoduchost interakcí

ve webovém programovacím modelu umožňuje

inkrementální vytváření systémů. Na rozdíl od těsně vázaných systémů RPC a systémů distribuovaných objektů, které vyžadují rozmístění a vytvoření všech částí aplikace najednou, k systémům založeným na webu je možné přidávat klienty a servery podle potřeby. Vytvoření připojení k novým aplikacím je jednoduché, dá se dělat decentralizovaně, bez jakékoli centrální koordinace kromě registrace DNS jménem, a s podstatně vyšším stupněm vzájemné součinnosti, rozšiřovatelnosti a ovladatelnosti. Základní

idea

webové

služby

spočívá

v

přizpůsobení

volně

vázaného

webového modelu programování na použití v aplikacích, které nejsou založené na využití prohlížečů. Cílem je poskytnout platformu pro vývoj distribuovaných aplikací s využitím softwaru pracujícího na různých operačních systémech a zařízeních, vytvořených v různých programovacích jazycích a vývojových nástrojích od různých dodavatelů, vše s možností nezávislého vývoje a aplikace. [9]

3.4. Základ webových služeb Webová služba je softwarový systém identifikovaný URI (Uniform Resource Identifier). Jeho rozhraní a vazby jsou definované a popsané pomocí XML. Definice může být objevená jinými softwarovými systémy. Tyto systémy jsou pak schopny vzájemně působit s webovou službou způsobem předepsaným v její definici a s použitím zpráv založených na XML a přepravovaných pomocí internetových protokolů. [7] Základem webových služeb je trojice standardů SOAP, WSDL a UDDI pro komunikaci, popis služeb a vyhledávání služeb. SOAP je označení protokolu, s jehož pomocí Webové služby komunikují. WSDL je speciální jazyk, kterým jsou popsány Webové služby a UDDI označuje registr, kde lze ukládat a vyhledávat informace o jednotlivých Webových službách. Vzájemný vztah SOAP, WSDL a UDDI je patrný z obrázku č. 4.

Obrázek č. 4: Vztah SOAP, WSDL a UDDI [8]

Princip webové služby je poměrně jednoduchý. Vytvořenou aplikaci (funkci) je potřeba umístit někam na síť a určitým jazykem (konkrétně WSDL) definovat její rozhraní. Když se někdo rozhodne tuto službu využít, pošle dohodnutým protokolem (SOAP) vstupní údaje a dostane zpět výsledek. Při vytváření aplikací je potřebné nejdříve ve speciálním katalogu (UDDI) zjistit vhodné existující webové služby a ty potom stačí připojit.

3.5. SOAP Simple Object Access Protocol (SOAP) je standard pro komunikaci v prostředí internetu vydaný konsorciem W3C [4]. Definuje kódování předávaných zpráv textovým zápisem v jazyce XML, kdy se každá zpráva skládá ze série hlaviček a těla s vlastním obsahem zprávy. Ačkoliv takto kódované zprávy mohou být delší, než je nezbytně nutné, jejich textový formát umožňuje předávat je prostřednictvím protokolu HTTP. To je velmi důležité v prostředí internetu, kde jiné protokoly než HTTP nemusí být kvůli různým technickým či bezpečnostním překážkám použitelné.

3.6. WSDL Web Services Description Language (WSDL) je standard pro popis webových služeb, také od konsorcia W3C. [5] Tento popis, opět v jazyce XML, obsahuje definice všech typů dat a formátů zpráv nutné pro komunikaci

s

webovou

službou.

Popis

obsahuje

také

specifikaci

přenosového protokolu, specifikaci kódování zpráv a informaci o tom, na kterých konkrétních adresách je daná webová služba k dispozici. Popis podle standardu WSDL tak obsahuje všechny údaje potřebné pro volání webové služby.

3.7. UDDI Universal Description, Discovery and Integration (UDDI) je standard konsorcia UDDI [6], který popisuje webovou službu určenou k registraci a vyhledávání dalších webových služeb. UDDI se opírá o třídění služeb podle některého ze standardních katalogů, jako je registr DUNS nebo katalogy NAICS či UNSPSC. Záznam o každé webové službě obsahuje vedle zatřídění služby také informace o jejím poskytovateli a popis služby podle standardu WSDL.

3.8. Jak webová služba funguje Komunikaci klienta a serveru znázorňuje obrázek č. 5. Ten vychází z případu, kdy se použije Microsoft SOAP Toolkit na straně klienta i na straně serveru a kdy webovou službu poskytuje komponenta COM (tak se implementuje prostřednictvím aplikace vytvořené ve Visual FoxPro). V prostředí .NET to funguje trochu jinak.

Obrázek č. 5: Princip komunikace s webovou službou

Celý proces začíná požadavkem ze strany klientské aplikace. Ta kontaktuje klienta SOAP, předá mu parametry pro webovou službu a sdělí mu její URL adresu. Adresa služby je ve skutečnosti adresou souboru WSDL. Klient SOAP si stáhne ze souboru WSDL informace o službě. Pomocí získaných dat ověří, zda daná služba opravdu obsahuje metodu, kterou aplikace požaduje a ověří datové typy získaných parametrů. Dále sestaví požadavek SOAP (SOAP request) a odešle jej v těle požadavku HTTP (http request) na zjištěnou adresu "listeneru“, který přijímá požadavky pro webovou službu. Listener (poslouchač/naslouchač) může být dvojího typu. Buďto se jedná o server ISAPI nebo stránku ASP. Rozdíl mezi nimi je především v rychlosti. ISAPI je asi čtyřikrát rychlejší. Stránka ASP se

používá v případě, že chceme před předáním požadavku serveru SOAP provést ještě nějaké dodatečné zpracování, či úlohu serveru SOAP úplně vynechat.

Pokud

tedy

není

na

stránce

ASP

příslušného

listeneru

specifikováno jinak, předá se požadavek přímo serveru SOAP. Server SOAP z přijatého požadavku zjistí jméno metody komponenty COM, kterou má zavolat a jaké parametry jí má předat. Nakonec si ze souboru WSML načte poslední informace potřebné k vytvoření objektu komponenty COM. Nyní dochází k samotnému volání požadované metody objektu COM spolu s požadovanými parametry. Objekt COM požadavek zpracuje a vrátí výsledek zpět serveru SOAP. Ten na základě návratové hodnoty sestaví odpověď ve formátu XML, odpověď vrátí listeneru a ten jí vrátí zpět klientovi SOAP. Klient SOAP nakonec z odpovědi zjistí návratovou hodnotu a vrátí ji aplikaci. Je důležité si uvědomit, že z pohledu uživatele je objekt COM při každém požadavku vytvořen a znovu zrušen. Není proto možné, aby si do příští interakce s uživatelem uchovával jakékoliv stavy, jako jsou například hodnoty vlastností. Ve skutečnosti se objekt COM z důvodu lepší výkonnosti ponechává v paměti i pro případná další volání.

4. Podrobný popis UDDI Pro účely tohoto projektu je významný především standard UDDI, který je dále v textu podrobně rozepsán. První specifikace UDDI pochází ze září 2000 a označuje se jako 1.0. Následovala 2.0 (březen 2001) a 3.0 (prosinec 2001). Specifikace UDDI má umožnit podnikům rychle, snadno a dynamicky najít partnera a rozvinout s ním obchodní styky. Toho se dosáhne: •

popsáním vlastního businessu a služeb,

•

vyhledáním partnerských podniků, které nabízejí služby, jež daný podnik požaduje,

•

propojením s těmito podniky.

Obecněji řečeno, UDDI má umožnit širší, snazší a výhodnější spolupráci firem nejrůznějších odvětví z celého světa, která se má následně pozitivně odrazit v jejich ekonomických výsledcích, např. formou úspory nákladů nebo vyšší efektivnosti. Kromě toho UDDI též představuje globální informační a reklamní médium. Podíváme-li se na to z technologického hlediska, UDDI znamená snahu o vytvoření systému pro dynamické vyhledávání, připojování a využívání webových služeb business aplikacemi. Cílem UDDI je přitom poskytnout uživateli jak klasická data (především informace o poskytovateli služby), tak metadata (způsob použití služby) [5]. To se realizuje tzv. UDDI protokolem, který je základem uvedeného standardu. Protokol je založen na (starší) verzi protokolu SOAP (Simple Object Access Protocol), též označované jako "XML Protocol messaging specifications", jejímž tvůrcem je dobře známé konsorcium W3C. UDDI

funguje

na

principu

registrace

webových

služeb

jejich

poskytovateli. V současné době existuje implementace nesoucí název "The UDDI Business Registry" (čili "UDDI-obchodní rejstřík"), kde producenti těchto služeb registrují svou firmu (popis, druh služeb obecně) a dále konkrétní nabízené webové služby (obvykle formou URL odkazů, a příp. i

přesně definovaného typu služby - pomocí tModelů) a naopak zákaznické podniky zde pak mohou tyto služby vyhledávat. Systém je provozován rovněž pod záštitou OASIS, konkrétně firmami IBM, Microsoft a SAP, jako distribuovaná aplikace se společným rozhraním a průběžnou datovou synchronizací. Je zatím zdarma volně přístupný v režimu 24x7, očekává se připojení dalších uzlů. Kromě toho je samozřejmě možné (a doporučené), aby podobné registry vznikaly nezávisle na čistě privátní bázi, tj. v rámci intranetu, a poskytovaly služby pouze svým registrovaným uživatelům. IBM, Microsoft, resp. Novell nabízejí pro tuto oblast produkty WebSphere UDDI Registry, Microsoft Enterprise UDDI Services in Windows .NET Server, resp. Novell Nsure UDDI Server. Vyhledávání v UDDI lze provést jak podle názvu a dalších charakteristik firmy či verbálního popisu služeb, tak podle vymezeného typu služby. K dispozici je jak webové, tak programové (služební) rozhraní vyhledavače pracující na protokolu SOAP. UDDI ovšem nepředepisuje žádný formát či metodiku pro popis vlastního rozhraní nabízené webové služby. Může se jednat o prostý text, vlastní (uživatelské) XML schéma, nebo kód ve WSDL (Web Services Description Language). Z toho vyplývá, že odpověď vyhledavače může být nesourodá.

4.1.Specifikace UDDI Specifikace UDDI se už od verze 1.0 skládala z několika základních dokumentů, které postupně přibývaly: •

UDDI Programmer's API - popisuje programové (raději než "programátorské" - pozn.překl.) rozhraní UDDI, které je závazné pro každý UDDI registr. Tedy vlastně metody, kterým odpovídají příslušné vyměňované zprávy v protokolu SOAP. Původně (v1.0) se jednalo především o dotazovací a registrační funkce.

•

UDDI Data Structure Reference - popisuje detailně datové struktury (objekty) používané v UDDI registru, především jejich jednotlivá pole (atributy) a jejich význam [6].

•

UDDI XML Schema - představuje formální zápis datových struktur UDDI v jazyce XML. Uvádí se jako samostatný jazyk (XSD - XML Schema Definition (Language))

•

UDDI WSDL Service Interface Descriptions - popis registru UDDI

(jakožto

webové

služby)

v

jazyce

WSDL,

jakási

"metametadata". •

UDDI tModel - popisuje tModely potřebné pro vnitřní fungování UDDI registru, povinně implementované

•

UDDI Replication Specification a XML Schema - popisují proces replikace dat a příslušné interface mezi jednotlivými distibuovanými UDDI uzly. K tomu se váže též dokument UDDI Operator's Specification s požadavky na provozovatele uzlu.

4.2.Datové struktury UDDI UDDI umožňuje: •

vyhledání webové služby podle definovaného rozhraní,

•

vyhledání producenta podle zvolených klasifikačních znaků,

•

zjištění podporovaných protokolů dané webové služby,

•

vyhledání webové služby podle klíčových slov,

•

uložení zjištěných informací (např. během tvorby aplikace) a jejich online update za běhu.

Specifikace UDDI popisují obsah UDDI serveru a zprávy používané pro komunikaci se serverem. Popis v další části textu se bude týkat specifikací UDDI verze 2.0, které zahrnují specifikaci datové struktury, která definuje obsah UDDI registru, a API specifikaci, která definuje zprávy zasílané do a z registrů. K tomu slouží následující datové struktury (objekty), obsah registrů: •

businessEntity - popisuje poskytovatele služeb: jeho název a popis v různých jazycích, kontakt, klasifikační znaky. Může dále obsahovat

vnořené objekty businessService a bindingTemplate, sloužící k popisu poskytovaných služeb. •

businessService - představuje seznam poskytovaných služeb : u každé název, popis, klasifikační znaky. Každá businessService je podřízena jediné businessEntity.

•

bindingTemplate - popisuje konkrétní webovou službu, a to z čistě technologického hlediska (jakým způsobem se k ní připojit): obsahuje buďto její adresu (typicky URL) nebo nepřímý odkaz.

•

tModel (celým názvem Technical Model) - představuje abstraktní vlastnost/atribut/rozhraní

jiného

UDDI

objektu.

Každá

detailní

specifikace, každý typ přenosu, protokol nebo jmenný prostor jsou dány jedním tModelem, který může být zapsán např. pomocí WSDL nebo XSD (XML Schema Definition). Každá bindingTemplate pak obsahuje odkazy na relevantní tModely, které popisují jednotlivé vlastnosti dané webové služby a v souhrnu vlastně určují její typ. Webové služby jsou stejného typu, pokud obsahují odkazy na stejné tModely.

Každý

tModel

může

být

samozřejmě

takto

použit

libovolněkrát. Z hlediska fyzické realizace je podstatné, že tModel opět obsahuje pouze odkazy na definiční dokumenty, nikoli přímo definici daného rozhraní. •

publisherAssertion – vztah mezi dvěmi jednotkami businessEntity

Jednotka businessEntity může obsahovat žádnou nebo několik jednotek businessService,

které

mohou

obsahovat

žádnou

či

více

jednotek

bindingTemplate. Jednotka bindingTemplate se může vztahovat k jedné či více jednotkám tModel a publisherAssertion se vztahuje ke dvěma jednotkám businessEntity.

4.3.Programové rozhraní UDDI (UDDI API) UDDI API se skládá z několika dílčích rozhraní, která vznikala postupně. Podstatu služby UDDI nicméně tvoří dvě z nich, přítomné již od verze 1.0:

•

Inquiry API - rozhraní pro dotazování

•

Publication API - rozhraní pro aktualizaci

4.4.Inquiry API Inquiry API slouží k dotazování UDDI registru. Umožňuje tři základní typy dotazů: •

The browse pattern (procházení) - umožňuje zadat široký dotaz (např. název firmy) a v obdrženém výsledku následně listovat a získávat detailnější informace (např. zvolit ze seznamu služeb podle požadovaných tModelů).

•

The drill-down pattern (detail) - vrátí záznam (businessEntity, businessService, bindingTemplate, tModel) podle primárního klíče, slouží ke zpodrobnění nebo opakování předchozího dotazu.

•

The invocation pattern (volání) - vrací informace potřebné k volání zvolené webové služby, zajišťuje dynamickou vazbu - jedná se především o vrácení aktuální bindingTemplate v případě, kdy dříve nalezená služba z nějakých důvodů neodpovídá.

K realizaci uvedených dotazů slouží následující funkce (metody). Všechny jsou synchronní a přístupné pomocí HTTP/POST. Metody vracejí seznamy objektů, z nichž každý má ve specifikaci opět vlastní název (kvůli přehlednosti není uveden). Kromě toho je vhodné rozdělit metody na dva typy: metody find_, sloužící k hledání podle různých kritérií, a metody get_, vracející objekty podle primárního klíče. •

find_binding

-

vrací

seznam

bindingTemplate

(k

množině

businessService) •

find_business - vrací seznam businessEntity

•

find_relatedBusinesses - vrací seznam businessEntity, které mají potvrzený vztah k zadané businessEntity (viz též 2.3.2, metoda add_publisherAssertions)

•

find_service

-

vrací

seznam

businessService

(k

množině

bussinessEntity) •

find_tModel - vrací seznam tModelů

•

get_bindingDetail - vrací seznam bindingTemplate - za účelem volání služeb (invocation)

•

get_businessDetail - vrací seznam businessEntity

•

get_operationalInfo - vrací interní data UDDI objektů (čas poslední

aktualizace,

uzel

registrace,

identitu

zakládajícího

uživatele) •

get_serviceDetail - vrací seznam businessService

•

get_tModelDetail - vrací seznam tModelů

Metody find_ umožňují použití sady operátorů označované jako Find Qualifiers. Metody find_binding, find_business a find_service umožňují navíc ještě vnořené dotazy.

4.5.Publication API (a primární klíče UDDI) Publication API slouží k publikování, resp. aktualizaci dat v UDDI registru. Uživateli je přitom ponechána možnost a zodpovědnost, aby si zvolil uzel UDDI, který bude nadále výlučně k publikování využívat. Případné duplicity záznamů nejsou nijak řešeny. Metody rozhraní jsou opět synchronní, a navíc atomické (tj. mají charakter transakce). Základní otázkou při zápisu do UDDI registru jsou primární klíče. Nejprve popišme, jakou mají tyto klíče strukturu. Primární klíč UDDI (uddiKey) je založen na všeobecně známých principech URI (Uniform Resource Identifier, RFC 2396) a UUID ((formatted) Universally Unique Identifier, OSF) a má jednu ze tří následujících podob: •

uuidKey - uddi:, přičemž představuje řetězec 8,4,4,4,12

hexadecimálních

číslic

oddělených

pomlčkami

(dohromady 128 bitů), celkově tedy uuidKey např. uddi:4CD7E4BC648B-426D-9936-443EAAC8AE23.

•

domainKey - uddi:<doména> (podle RFC 2459)

•

derivedKey - uddi::[:...], kde znamená "key specific string" a představuje řetězec alfanumerických a některých dalších povolených znaků, který se může libovolněkrát opakovat.

Existují dvě možnosti generování nových klíčů: •

automatické přidělení ze zvoleného uzlu - řídí se následujícími hierarchickými pravidly : každý uzel má právo generovat klíče z předem určené podmnožiny (partition) všech uddiKey, a dále toto oprávnění delegovat - k tomu slouží tModel keyGenerator, který se "restriktivně dědí". Přesněji řečeno, vlastník keyGeneratoru může přidávat na konec klíče libovolné kss, přidělený začátek však musí dodržet. Na nejvyšší úrovni nutně existuje několik uzlů, které spravují celý prostor uddiKey (root partition), a to jsou právě uzly "The UDDI Business Registry".

•

návrh uživatele (v orig. publisher) - pokud k tomu obdržel od příslušného uzlu oprávnění, tj. svůj keyGenerator (tato možnost vlastně představuje nejnižší úroveň hierarchie, která už nikomu dalšímu služby generování klíčů neposkytuje).

První způsob je na rozdíl od druhého vždy dostupný. Použije se vždy v případě, že uživatel klíč nezadal. Metody Publication API: •

add_publisherAssertions - přidá jednu nebo více vazeb vlastních businessEntity na jiné businessEntity, vlastní nebo cizí (tj. mající jiného vlastníka). Slouží k realizaci metody find_relatedBusinesses, která vrací seznam businessEntity s komplementárními vazebními atributy

(např.

podobu

tvrzení

mateřská<->dceřinné (assertion),

což

společnosti).

znamená,

že

v

Vazba

má

případě

cizí

businessEntity musí její vlastník příslušnou vazbu potvrdit, jinak

zůstane neviditelná. Z datového hlediska jsou tvrzení realizována objekty publisherAssertion •

delete_binding - provede výmaz zadané bindingTemplate

•

delete_business - provede výmaz zadané businessEntity

•

delete_publisherAssertions - provede výmaz jednoho nebo více zadaných vazebních tvrzení, s dopadem na viditelnost příslušných vazeb

•

delete_service - provede výmaz zadané businessService

•

delete_tModel - skryje uživateli informace o zadaném tModelu. tModel zůstává uložen v registru a je nadále přístupný odkazem, a rovněž pomocí metody get_tModelDetail, ale neobjevuje se ve výstupech metody find_tModel. Fyzický výmaz tModelu provést nelze

•

get_assertionStatusReport - vrací seznam vazebních tvrzení, jednak publikovaných daným uživatelem o vlastních businessEntity, jednak tvrzení jiných uživatelů o těchto businessEntity. Slouží ke správě publikovaných tvrzení

•

get_publisherAssertions - vrací seznam vazebních tvrzení, (oproti předchozí

metodě

pouze)

publikovaných

daným

uživatelem

o

vlastních businessEntity •

get_registeredInfo - vrací stručný seznam businessEntity a tModelů spravovaných daným uživatelem. Slouží ke správě vlastních dat

•

save_binding - vloží nebo aktualizuje (pokud již existuje) jednu či více zadaných bindingTemplate

•

save_business - vloží nebo aktualizuje (pokud již existuje) jednu či více zadaných businessEntity

•

save_service - vloží nebo aktualizuje (pokud již existuje) jednu či více zadaných businessService

•

save_tModel - vloží nebo aktualizuje (pokud již existuje) jeden či více zadaných tModelů

•

set_publisherAssertions - nahradí současný seznam vazebních tvrzení daného uživatele zadaným seznamem (existující tvrzení, která nejsou uvedena, jsou odstraněna) [12]

4.6.Zprávy Když klientské aplikace objeví informaci o webových službách, tak posílají do UDDI registrů zprávy typu Inquiry, pokud klientské aplikace registrují informace o webových službách, posílají zprávy typu Publishing. Jako odpověď na oba druhy zpráv odesílá webová služba zprávu typu Reponse. Následující typy zpráv lze zasílat do a z registrů: •

zprávy typu Inquiry – slouží k hledání potenciálně použitelných objektů a k získání detailních informací o daných objektech

•

zprávy typu Publishing – vytvářejí a udržují obsah registrů

•

zprávy typu Response – poskytují výsledky vyhledávání

Všechny typy zpráv se dále dělí do několika podtypů, v závislosti na funkčních

charakteristikách.

Následující

schéma

popisuje

celkový

konceptuální model UDDI včetně obsahu registrů, zpráv do registrů zasílaných a odpovědí, které registry vracejí. Schéma č. 6 popisuje celkový konceptuální model UDDI včetně obsahu registrů, zpráv do registrů zasílaných a odpovědí, které registry vracejí:

Obrázek č. 6: Konceptuální model UDDI

4.6.1.

Zprávy typu Inquiry

Uživatelé webových služeb využívají zpráv typu Inquiry k vyžádání informací z UDDI registrů. Existují dva druhy zpráv tohoto typu: vyžádá od UDDI serveru informace požadovaného druhu – find_xxx

např.zpráva find_business vyhledá informace o určité business entity vrátí od UDDI serveru vyčerpávající informace o typu informací

get_xxx

specifikovaném klíčem key, který generují UDDI registry – např.zpráva get_businessDetail vrací informace o registrovaných business entitách

4.6.2.

Zprávy typu Publishing

Poskytovatelé webových služeb využívají tento typ informací k zpřístupnění informací o webových službách v UDDI registrech. Existuje šest zpráv tohoto typu: add_xxx

slouží k přidání určité informace do UDDI registrů – např.add_publisherAssertion

delete_xxx discard_xxx get_xxx save_xxx set_xxx

4.6.3.

slouží k výmazu určité informace z UDDI registrů – např.delete_business slouží k odložení určité informace získané z UDDI registrů – např.discard_authToken slouží k různých typů informací o registračním proceu UDDI registrů – např.get_authToken slouží k přidání nebo úpravě registračních informací v registrech – např.save_business slouží k nastavení informací v registrech – např.set_publisherAssertion

Zprávy typu Response

Zprávy typu Response poskytují výsledky zprávám typu Inquiry a Publishing, které jsou zaslány do UDDI registrů. Existuje šest zpráv tohoto typu: xxxAssertions xxxDetail xxxList

obsahuje informaci o všech vztazích dané entity – např.publisherAssertion obsahuje informaci o detailní informace o daném typu informací – např.businesDetail obsahuje zkrácenou informaci o daném typu informací – např.serviceList obsahuje zkrácenou informaci o dané entitě –

xxxInfo

např.registeredInfo – zkrácené informace o všech registrovaných business entitách a technickém modelu řízeném danou entitou

xxxReport xxxToken

obsahuje status právě probíhajícího procesu v registrech – např.assertionStatusReport např.authToken – autentizační informace pro následující zprávy, které je potřebují

4.7.Společné přístupové body (Common Access Points) Servery na kterých je spuštěna služba UDDI používají následující přístupové body: Účel

Přístupový bod

InquireURL

http://servername/uddi/inquire.asmx

PublishURL

https://servername/uddi/publish.asmx

4.8.Datový model UDDI V této části je popsán datový model UDDI, který používají servery, na kterých běží služba UDDI (obr. č. 7).

Obrázek č. 7: Celkový datový model

Třída businessEntity obsahuje tyto prvky a vlastnosti: Název

Typ

Popis

businessKey

vlastnost

jedinečný identifikátor dané Business Entity

operator

vlastnost

authorizedName

vlastnost

discoveryURLs

prvek

name

prvek

název dané Business Entity

description

prvek

krátký popis

contacts

prvek

kontaktní informace

businessServices

prvek

identifierBag

prvek

categoryBag

prvek

UDDI server spravuje řídící kopii dané Business Entity jméno osoby, která danou Business Entity publikovala URL odkazující na další informace o dané Business Entity

jednotky businessService poskytované danou Business Entity prvky keyedReference sloužící jako identifikátor dané Business Entity prvky keyedReference sloužící jako informace o kategorii dané Business Entity

Třída businessService obsahuje tyto prvky a vlastnosti: Název

Typ

Popis

serviceKey

vlastnost

businessKey

vlastnost

jedinečný identifikátor rodičovské Business Entity

name

prvek

název

description

prvek

krátký popis

bindingTemplates

prvek

categoryBag

prvek

jedinečný identifikátor dané jednotky Business Service

prvky bindingTemplate které popisují daný Business Service prvky keyedReference které slouží jako informace o kategorii dané jednotky Business Service

Třída bindingTemplate obsahuje tyto prvky a vlastnosti: Název

Typ

serviceKey

vlastnost

bindingKey

vlastnost

jedinečný identifikátor pro daný bindingKey prvek

description

prvek

krátký popis

accessPoint

prvek

hostingRedirector

prvek

tModelInstanceDe tails

prvek

Popis jedinečný identifikátor rodičovské jednotky Business Service

adresa vstupního bodu pro volání dané webové služby přesměrování na jiný prvek Binding Template prvky tModelInstanceInfo které se vztahují k příslušným technickým modelům

Třída tModel obsahuje tyto prvky a vlastnosti: Název

Typ

Popis

tModelKey

vlastnost

operator

vlastnost

authorizedName

vlastnost

name

prvek

název technického modelu

description

prvek

krátký popis technického modelu

overviewDoc

prvek

identifierBag

prvek

categoryBag

prvek

jedinečný identifikátor daného technického modelu stránky UDDI registrů, kde je spravován řídící kopie daného řídícího modelu jméno osoby, která publikovala daný technický model

Metadata popisující souhrnné informace o daném technickém modelu prvky keyedReference sloužící jako identifikátor daného technického modelu prvky keyedReference které slouží jako informace o kategorii daného technického modelu

Třída publisherAssertion obsahuje tyto prvky a vlastnosti: Název

Typ

fromKey

prvek

toKey

prvek

keyedReference

prvek

Popis Identifikátor první jednotky Business Element v daném vztahu Identifikátor druhé jednotky Business Element v daném vztahu Typ vztahu

[13]

4.9.Identifikátory Jedním z navržených prvků UDDI je schopnost označit pro účely registrace informace identifikátory. Účelem identifikátoru v UDDI při registraci, zejména se to týká businessEntity a tModel, je umožnit ostatním

najít

publikované

informace

použitím

více

formálního

identifikačního systému. V UDDI registrech, které využívají jen uzavřené komunity, se mohou použít identifikátory známé pouze členům této komunity. Například v UDDI registru, který je určen pro použití v rámci privátní sítě obchodů, mohou dodavatelé používat speciální identifikátory, které jsou známé právě pouze obchodům v této privátní síti. Dvě z hlavních struktur UDDI poskytují strukturu s podporou připojení identifikátorů k datům. Jedná se o struktury businessEntity a tModel (obr. č. 8). Poskytnutím vyhrazeného místa pro připojení identifikátorů k těmto datovým strukturám, vzniká možnost využít identifikátory k různým účelům.

Obrázek č. 8: Použití identifikátorů

Následující fragment XML dokumentu ukazuje příklad přidání identifikátoru do businessEntity a jeho identifierBag: …
…

tModelKey="uddi:uddi.org:ubr:identifier:dnb.com:d-u-n-s" keyName="D-U-N-S:My Company" keyValue="12-345-6789"/>

…

Pozornost je nutné věnovat třem atributům keyedReference: • • •

tModelKey: unikátní identifikátor tModelu, který reprezentuje systém identifikátoru keyName: pojmenování určené pro běžné čtení člověkem a pokud je identita zakódována, pak zde musí být k dispozici lidsky ztvárněná hodnota keyValue: aktuální identifikátor uvnitř specifikovaného identifikátoru systému

Pokud se registr řídí doporučenou politikou pro rozpoznávání systémů identifikátorů, pak jsou všechny systémy identifikátorů zaregistrovány do zvláštního registru UDDI a lze je nalézt při hledání tModelu nasledujícím způsobem:



4.10. Kategorizace Kromě možnosti označit data v registru UDDI identifikátorem, je další možností schopnost přiřadit kategorizační informace. Bez kategorizace by bylo hledání a lokalizace dat uvnitř UDDI registru velmi obtížné. Zvláště se jedná o případy, kdy je potřeba najít neznámé služby, vazby nebo typy. Kategorizace dat je tedy nepostradatelná pro všeobecné vyhledávání v registru UDDI. Všechny čtyři hlavní struktury UDDI poskytují strukturu s podporou připojení kategorie k datům. Jedná se o struktury businessEntity, businessService, bindingTemplate a tModel. Poskytnutím vyhrazeného místa pro připojení kategorií k těmto datovým strukturám, vzniká možnost využít kategorie k různým účelům. Následující

fragment

XML

dokumentu

ukazuje

příklad

přidání

kategorie do businessEntity s využitím categoryBag: …
keyName="UNSPSC:Drugs and Pharmaceutical Products" keyValue="51.00.00.00.00"/>

Instance businessEntity, která je identifikována společně s businessKey uddi:my_company.example,

obsahuje

categoryBag

s

dvěma

kódy

produktů UNSPSC a třemi kódy zemí dle ISO 3166. Obchodní informace jsou zde reprezentovány pomocí businessKey, které se snaží specifikovat, že se prodává lékařské vybavení a lékárenské produkty v Německu, Francii a USA. Technicky je to provedeno pomocí třech atributů v každém z třech keyedReferences: •

tModelKey:

unikátní

identifikátor

tModelu,

který

reprezentuje

kategorizační systém •

keyName: pojmenování určené pro běžné čtení člověkem a pokud je aktuální kategorie zakódována, pak zde musí být k dispozici lidsky ztvárněná hodnota

•

keyValue:

aktuální

kategorizačního systému

kategorie

uvnitř

specifikovaného

Za účelem nalezení všech kategorizačních informací, které jsou zaregistrovány ve zvláštním UDDI registru, je doporučená následující politika rozpoznávání kategorizačního systému. find_tModel může vypadat následujícím způsobem:

Aby se dala jednoduše použít klíčová slova místo plnohodnotných názvů skupiny kategorií, může být použita všeobecná taxonomie klíčových slov UDDI, jak je uvedeno v příkladu: …



Instance

businessEntity,

která

je

identifikována

společně

s

businessKey uddi:my_company.example, obsahuje categoryBag s dvěmi klíčovými slovy za použití kategorizačního systému klíčových slov UDDI. Obchodní informace jsou zde reprezentovány pomocí businessKey, které se snaží specifikovat, že se nabízí Web service konzultace a UDDI konzultace a přitom používá klíčová slova "Web service" a "UDDI" jako atributy keyValue uvnitř elementů keyedReference.

5. Úvod do UML Návrh aplikace může teoreticky vzniknout pouze za použití tužky, mozku a poznámkového bloku, s jejichž pomocí programátor navrhne jednoduchý model aplikace. Model ale bude používat jen jemu známou syntaxi a sémantiku, takže jej jen těžko bude sdílet. Dalším problémem je, že za těmito náčrty většinou nestojí žádný konzistentní logický metamodel ani formálně kodifikovaná sémantika jednotlivých elementů modelu, takže případná komunikace mezi návrháři připomíná situaci v IT Babylónu po zmatení jazyků. Unified Modeling Language (UML) má již ve svém názvu slovo unifikovaný, protože jedním z jeho cílů je sjednocení používaných výrazových prostředků. UML je jazykem s bohatou sémantikou a syntaxí, který usnadňuje návrh a vizualizaci různých typů aplikací. Navíc tvůrci jazyka

UML

nebyli

natolik

naivní

ani

sebevědomí,

aby

věřili,

že

standardními elementy jazyka UML pokryli kompletně veškeré požadavky návrhářů, a přímo do jazyka zabudovali mechanismy rozšíření, které usnadňují řízenou deklaraci a definici nových elementů jazyka. Jedná se tedy unifikovaný modelovací jazyk, který má, na rozdíl od převážně textově orientovaných programovacích jazyků, vlastní grafickou syntaxi (tj. pravidla pro sestavování jednotlivých elementů jazyka do větších objektů) a sémantiku (tj. jednoznačná pravidla určující jednotlivým syntaktickým výrazům jejich význam). UML je jazyk, který umožňuje modelovat jednoduché i složité aplikace pomocí stejné formální syntaxe, a proto můžete výsledky své práce sdílet s ostatními návrháři. Jazyk UML nevznikl ve vzduchoprázdnu, předcházelo mu myšlenkové úsilí mnoha OOP znalců o vytvoření kvalitní metodiky. V roce 1996 pánové Jacobson, Booch a Rumbaugh, kteří již dříve významně přispěli k rozvoji OOP metodik, přešli k firmě Rational Corp., pro kterou vytvořili jazyk UML. V roce 1997 byl jazyk UML akceptován jako průmyslový standard a postupně začal vytlačovat ostatní analytické jazyky na pověstné smetiště

dějin. V současné době se připravuje uvedení verze 2.0. V existujících CASE nástrojích se můžete většinou setkat s podporou UML verze 1.2, 1.3 nebo dokonce 1.4.

5.1.Použití UML Model v UML se skládá z různých diagramů, jež představují průhledy na různé části sémantického základu navrhované aplikace. Sémantickým základem je souhrn specifikací aplikace, který vymezuje teritorium, v němž se může návrh pohybovat. Diagram ve vizuální formě vypráví právě jeden konkrétní "příběh" o aplikaci. Žádný dvourozměrný diagram nemůže zachytit komplexní aplikaci v celku, ale soustředí se vždy právě na jeden důležitý aspekt. Jazyk UML rozeznává pět základních pohledů na systém. •

Pohled případů užití. V případech užití jsou vyjádřeny základní požadavky kladené na systém. Veškeré další pohledy se pohybují v mantinelech vymezených pohledem případů užití.

•

Logický pohled se zabývá zejména pojmy z problémové domény zadavatele a jejich vzájemnými statickými vztahy.

•

Procesní pohled se soustřeďuje na chování systému, které musí splňovat požadavky a omezení z případů užití, jež jsou kladeny na průběh

procesů.

Pregnantně

řečeno,

jedná

se

o

procesně

orientovaný doplněk logického pohledu. •

Implementační pohled zachycuje fyzické rozdělení aplikace na samostatné komponenty a jejich závislosti.

•

Pohled

nasazení

mapuje

komponenty

na

množinu

výpočetních uzlů v cílovém prostředí. Pohledy jsou konkretizovány v následujících typech diagramů: •

Diagram případů užití

•

Diagram tříd

•

Diagram objektů

•

Diagram komponent

•

Diagram nasazení

fyzických

•

Sekvenční diagram

•

Kolaborační diagram

•

Stavový diagram

•

Diagram aktivit [15]

5.2.Základní stavební bloky V jazyce UML se rozlišují tři základní stavební bloky (Building Blocks): •

Předměty (Things) – Do předmětů jsou řazeny samotné elementy modelu.

Oblast

předmětů

je

dále

členěna

na

podkategorie.

Podkategorie strukturních předmětů (Structural Things) obsahuje subjekty

modelu.

Subjekt

modelu nese

statické

informace

o

softwarovém artefaktu a je většinou vyjádřen podstatným jménem (třída, komponenta, uzel). V podkategorii pro dynamické předměty (Behavioural dynamické

Things) chování

se

nalézají

systému

předměty,

(aktivita,

které

stav).

K

zachycují sdružování

sémanticky příbuzných předmětů se používají takzvané balíčky, pro něž je vytvořena samostatná kategorie předmětů vyjadřujících seskupení (Grouping Things). Ke každé části modelu je možné zadat libovolné

množství

poznámek.

Poznámky

patří

do

kategorie

anotačních předmětů (Annotational Things). •

Relace (Relations) – Předměty neleží vedle sebe jako chaotické shluky nesouvisejících informací, ale jsou vzájemně propojeny komplexním předivem vztahů. Vztahy v modelu ukazují, jak spolu jednotlivé předměty souvisí.

•

Diagramy (Diagrams) –

Diagramy zachycují různé aspekty

modelovaného systému. [16]

5.3.Předměty Předměty jsou elementy zpracovávaného modelu, jež jsou následně členěny do několika navzájem rozdílných podkategorií. Prvním typem

podkategorií jsou takzvané strukturní abstrakce UML modelu, například programové

třídy,

aplikační

či

objektové

rozhraní,

případy

užití,

komponenty či uzly. V diagramu UML jsou strukturní abstrakce zobrazeny jako různé převážně plošné tvary, které jsou však vždy uzavřené. Například se jedná o obdélníky, elipsy, kružnice či jednoduché zdánlivě trojrozměrné tvary, například krychle či kvádry. Každý smysluplný UML diagram by měl obsahovat alespoň dvě strukturní abstrakce, při jedné abstrakci totiž modelování ztrácí svůj hlavní smysl – popis vztahů mezi jednotlivými objekty. Kromě strukturních abstrakcí patří mezi předměty i takzvaná chování, která v UML diagramu prezentují interakce, tj. vzájemné komunikace mezi jednotlivými objekty. Pomocí chování lze také modelovat stavový stroj, u nějž se stavy specifikují pomocí přechodů, událostí a aktivit. Chování se v UML

diagramu

většinou

vyznačuje

pomocí

různým

způsobem

konstruovaných a různě zakončených šipek či propojovacích čar. Mezi předměty patří i takzvané seskupení, které podle potřeby modelu graficky seskupuje části diagramu na nižší úrovni. Většinou se jedná o takzvané balíčky, jež mají tvar stylizované kancelářské složky s popisem umístěným v levé horní části obdélníku (zobrazení seskupení se však může v různých prostředích odlišovat). Seskupení nejsou v současné době v některých dále popisovaných aplikacích použitelná (tj. nelze vytvářet hierarchické diagramy), což je pro tvorbu rozsáhlejších grafů velké omezení. Posledním a současně velmi jednoduchým typem předmětů jsou poznámky, které blíže specifikují vlastnosti a chování dalších elementů UML diagramu. Graficky jsou poznámky na prakticky všech typech UML diagramů většinou vyvedeny žlutě vyplněným obdélníkem s ohnutým rožkem.

5.4.Relace UML rozeznává následující typy vztahů: •

Asociace (Association) – Obecná souvislost předmětů. UML přesně definuje asociaci jako "měnící se populaci vztahů daných propojením objektů". Co přesně tato věta znamená, bude vysvětleno u diagramu tříd, kde budete seznámeni i se speciálními variantami asociace, kterými jsou kompozice a agregace.

•

Závislost – Změna v jednom předmětu způsobí změnu v jiném předmětu nebo mu poskytne požadovanou informaci. Například když třída pro odesílání emailu v aplikaci získá šablonu emailu z třídy globálních konfiguračních parametrů, měli bychom tento vztah zachytit jako závislost. Dobře zmapované závislosti nás neustále informují o celkové míře provázanosti jednotlivých částí modelu. Pokud závislosti v modelu začnou připomínat propletené křižovatky, je na čase vztahy mezi třídami refaktorovat, protože jde o spolehlivý symptom blížícího se poločasu rozpadu implementovaného systému při prvním pokusu o jeho další rozšíření.

•

Generalizace (Generalisation) – Jeden předmět je specializací jiného předmětu. Například třída osobní auto je specializací obecné třídy vozidlo.

Vztahy

generalizace

a

specializace

jsou

v

objektově

orientovaném modelování velmi důležité, protože jejich neadekvátní použití

předznamenává

většinou

krizi

celého

návrhu

i

jeho

implementace. •

Realizace (Realization) – Realizace je druh vztahu, při němž jeden předmět představuje dohodu, za jejíž plnění je odpovědný jiný předmět. Například z jazyků Java, C# a dalších jsou známá rozhraní, která reprezentují dohodu, jejíž plnění je požadováno po třídách, jež rozhraní implementují.

5.5.Diagramy Diagramy zachycují různé aspekty modelovaného systému, který nemusí být obecně vyjádřen pouze jedním UML diagramem, protože je možné například pomocí balíčků (packages) sdružovat více diagramů do jednoho hierarchicky organizovaného celku. Různých typů diagramů existuje velké množství, například diagram případů použití, diagram tříd, diagram objektů, diagram komponent, diagram nasazení, diagram aktivit, stavový diagram, diagram spolupráce a sekvenční diagram. Každý z výše vyjmenovaných typů diagramů obsahuje poněkud odlišný repertoár dostupných grafických značek (předmětů a relací).

5.6.Komerční produkty pro práci s UML Většinou se jedná o velmi rozsáhlé profesionální produkty, pro jejichž úspěšné a efektivní používání je zapotřebí absolvovat školení či poměrně dlouhé studium. Výsledkem nasazení těchto systémů však bývá rapidní urychlení práce, zejména prvotního návrhu systému. Mezi nejznámější můžeme zařadit: •

Rational Rose

•

ARTiSAN Real-time Studio

•

I-Logix Rhapsody

•

MetaMatrix MetaBase Modeler

•

Together Designer Community Edition

5.7.Produkty šířené pod GPL a podobnými licencemi V této kapitole budou vyjmenovány zejména produkty šířené pod licencí GPL či pod licencí podobného charakteru – dále popisované aplikace jsou tedy šířeny zdarma a i jejich použití pro tvorbu prvotních dat není žádným zvláštním způsobem omezeno. Předností a současně i záporem těchto produktů je jejich menší komplexnost, což na druhou stranu znamená kratší dobu na zaučení: •

Violet

•

Umbrello UML Modeller

•

ArgoUML [17]

6. Spojení ICS s aplikací Autodesku Jak a kde najít ICS, jak poznat co nabízí, už víme, ale stále není jasné, jak tyto informace a daný ICS modul (plugin) dostat do aplikace. Jak se s ní spojit, jak s ní pracovat a co všechno může s danou aplikací dělat. Možností odpovědí na tuto otázku je několik. Někteří navrhnou Visual Basic for Application, jiní zase VisualLisp nebo AutoLisp. Tyto nástroje lze využít, ale pro naše potřeby nejsou úplně vhodné. Odpovědí je ObjectARX SDK (Software Development Kit). Tato sada tříd umožňuje plnohodnotně rozšiřovat a využívat možnosti AutoCADu. Co si pod tím má člověk představit? Nejlepší cesta vede přes příklady, a proto jen výčtem vyjádřím, co všechno lze pomocí sady ObjectARX vytvořit. Tato sada umožňuje vytvářet takzvané rozšiřující aplikace. Jsou to .dll knihovny, které jsou nahrávány produkty Autodesk. Tyto knihovny můžou obsahovat kód pro vytváření nových nabídek,

panelů nástrojů, vlastní

formuláře pro vytváření bloků, které potom lze vložit do výkresu. Tím máme vytvořené spojení mezi produktem společnosti Autodesk a aplikací mimo daný produkt. Internet CAD services jsou navrženy na platformě .NET a to z důvodu využívání webových služeb. Proto potřebujeme sadu knihoven, která je určena pro .NET technologii. Sada knihoven ObjectARX je již starším produktem společnosti Autodesk, který podporuje programovací jazyk C/C++.I tyto knihovny bychom mohli využít, ale připravili bychom se o sílu technologie .NET. Proto tato sada bylo rozšířena o .dll knihovny řízených tříd (manage class). Z těchto knihoven můžeme vybírat třídy pro platformu .NET, které jsou

ekvivalentní

třídám

pro

programovací

jazyk

C/C++.

V rámci

nápovědy Autodesk produktů je uváděna mapovací tabulka těchto řízených tříd na třídy v C/C++. Z internetových stránek lze zdarma stáhnout referenční materiály k ObjectARX, které obsahují rozdělení tříd, dle užití a jmenných prostorů.

6.1.Základní informace o návrhu Návrh je vytvořen pomocí modelovacího jazyka UML, který již byl zmíněn výše v textu. Slouží k ujednocení komunikace mezi autorem návrhu a ostatními účastníky procesu navrhování. Zejména klient, programátoři a v neposlední řadě i management firmy, kde se daná aplikace bude vytvářet. Nesmíme zapomenout, že technologie ICS je navržena pro práci v internetu, popřípadě intranetu. To znamená, že základní charakteristikou je princip klient/server. Klientem zde chápeme jednotlivé ICS Pluginy (moduly), které se stahují automaticky při výběru chtěné ICS. Na straně serveru je webová služba, která nám poskytuje popis, svou funkcionalitu umožňuje stažení ICS Pluginy. Toto rozdělení nám určuje, že musíme vytvořit dva relativně rozdělené modely. Pro stranu klienta a server. Proč relativně rozdělené modely? Protože mezi nimi ve skutečnosti existuje vazba pomocí proxy třídy, o které již byla řeč. Proxy třída slouží pro generování a zpracování SOAP dotazů, které posílá nebo přijímá od webové služby na dané adrese. Tato proxy třída je právě součásti ICS pluginu, a jenom on ví, jak s danou ICS komunikovat a pracovat. Jednotlivé modely nejsou žádnou jinou vazbou propojeny a proto se budeme věnovat každé části zvlášť. Posledním obecným faktem je skutečnost, že se jedná o návrh infrastruktury pro běh a funkčnost ICS technologie a tím tedy se může výsledný model, získaný po úplné implementaci, lišit od zde navrhovaného. Například není ještě úplně uzavřena množina všech nástrojů, které by měli být na straně klienta, popřípadě na straně serveru. Už vůbec nezmiňuji nástroje a sadu knihoven pro zautomatizování vytváření nových ICS služeb a k nim odpovídajících pluginů.

6.2.Návrh infrastruktury na straně klienta Nesmíme zapomenout, že ICS služby budou různorodé, budou nabízet různou funkčnost za odlišných podmínek. Například pouze internímu

použití v rámci intranetu, v rámci výuky a další různá omezení. Proto musí být návrh univerzální, aby nijak neomezoval tvůrce ICS služeb. Mezi základní funkčnost infrastruktury, potažmo sada nástrojů, patří postupy pro vyhledávání a stahování ICS pluginů služeb na internetu. K těmto

účelům

budou

sloužit

formuláře

FindForm

a

LoadForm.

Samozřejmě většina operací vychází z podnětu Uživatele, avšak nesmíme zapomenout na důležitou roli vlastní infrastruktury, která provádí vlastní vyhledávání a instalování ICS pluginů z internetu.

Obrázek č. 9: Diagram užití infrastruktury na klientském počítači

ICS služby existují proto, aby pomáhaly při práci s produkty společnosti Autodesk, proto nesmíme opomenout vlastní užívání ICS pluginů, které

volají vzdálené, v internetu umístěné ICS služby. Velkou roli zde hraje vlastní plugin, který obsahuje proxy třídu dané ICS služby. Samozřejmě i ICS pluginy potřebují nějakou konfiguraci, popřípadě logovací údaje pro aktualizace.

Systém

se

sám

snaží

na

pozadí

služby

automaticky

aktualizovat, ale vždy je vhodné tuto možnost nabídnout i zkušenějším uživatelům. Tyto základní úkony a role, které tyto úkony vykonávají jsou znázorněny v diagramu užití na obrázku č. 1. K tomuto diagramu odpovídá diagram tříd, který si postupně rozebereme v následujících kapitolách

6.3.Napojení infrastruktury na aplikaci Autodesk Základem

klientské

infrastruktury

je

napojení

na

daný

produkt

společnosti Autodesk. K tomu nám poslouží třídy a rozhraní z SDK sady ObjectARX. Na diagramu tříd si můžeme všimnout dvou tříd. Třída ICSLoadApplication,

která

implementuje

rozhraní

Autodesk.AutoCAD.Runtime.IExtensionApplication je vstupním bodem celé infrastruktury. Tato třída implementuje dvě metody z jmenovaného rozhraní. První je Initialize(), která slouží k prvotnímu nastavení celé infrastruktury. V rámci této inicializace se provádí vyhledávání stažených ICS pluginů v předem definovaných adresářích, popřípadě uživatelem zadané cesty v nastavení produktu a jejich inicializaci. Musím upozornit, že jenom jedna jediná třída v dané rozšiřující aplikaci může implementovat toto rozhraní. Je to logické, více vstupních bodů do jedné aplikace je nesmysl. Aby bylo zřejmé, která třída obsahuje vstupní bod, dodáme informaci celé assembly, jak je uvedeno na následujícím řádku:

Základ inicializace udělá statická metoda FindICSPlugins() uložena ve třídě ICSPlugins, která vrátí instanci této třídy a vloží ho do atributu icsPlugins ve třídě ICSLoadCommands. Když máme tento objekt, který obsahuje všechny načtené ICS pluginy, spustíme jejich aktualizaci na

pozadí. Ovšem jen tehdy, máme-li tuto možnost povolenou v nastavení a jsme připojeni k síti. Každý ICS plugin může generovat svou

vlastní nabídku. Proto

požádáme všechny načtené pluginy o vrácení nabídky. Pokud dostaneme relevantní objekt, přidáme položku do menu, které nazveme „ICS pluginy“. Tato položka je také automaticky vytvořena při inicializaci. Metody, které jsou zaregistrovány na odchytávání události, například Click, jsou také součástí ICS pluginu. Druhou

metodou

rozhraní

IExtensionApplication

je

metoda

Terminate(), která je volána při ukončení aplikace. V této metodě dochází k úklidu a uložení konfigurací do souborů. Každý ICS plugin obsahuje metodu určenou pro úklid. Nazval jsem ji obdobně Terminate(). Schválně jsem nepoužil metodu Dispose() z rozhraní IDisposable, která slouží k úklidu po sobě samém. Dále definujeme třídu ICSLoadCommand, která obsahuje statickou proměnnou s objektem všech nahraných ICS pluginů. Tato třída obsahuje metody, ke kterým jsou přiřazeny textové položky pomocí nichž můžeme tyto metody volat přímo z příkazového řádku v AutoCADu. Před každou takovouto metodu opět vložíme dodatečnou informaci o assembly. Metoda pro zobrazení formuláře pro vyhledávání ICS služeb může vypadat následovně: _ Public Function FindCommand() Dim dlg As New FindForm() dlg.ShowDialog() End Function

Samozřejmě, že nemusíme psát příkazy, abychom mohli využívat výhod ICS služeb. V rámci inicializace rozšiřující aplikace se generuje menu pro ICS klienta, kde má každá metoda své zastoupení. Většina těchto metod, bude mít vlastní formulář, proto jsem znázornil základní dialogová okna, které jsou nejdůležitější ze všech. Tyto třídy obsahují většinu metod pro obsluhu grafického uživatelského rozhraní a v rámci návrhu infrastruktury nás nezajímají. Základním formulářem je FindForm, který ulehčuje vyhledávání ICS služeb na internetu. Je to průvodce, který nás provede všemi částmi nutných při hledání potřebné ICS služby na Internetu. Po vyhledávacím dialogovém okně se automaticky otevře formulář pro nahrání ICS pluginu do našeho počítače. Tento krok má svůj vlastní formulář, protože uživatelé si mohou adresy těchto ICS služeb předávat mezi sebou napřímo a proto vyžadují nástroj pro přímé vkládání. V neposlední řadě je třeba i ICS pluginy a celého klienta konfigurovat. Konfigurace je zde znázorněna třídou SettingForm. Skutečným cílem je začlenění těchto věcí tak, aby uživatel nepoznal, že se jedná o cizí technologii. Opět připomínám, ovládání a vzhled nastavovacího formuláře není nijak podstatný pro návrh infrastruktury. Samozřejmostí je, že ICS klient se neobejde bez podpůrných tříd, které můžeme najít v knihovnách daného produktu. Na modelu jsou tyto nejdůležitější třídy jenom vypsány. Nepatří do návrhu modelu ICS klienta. Jen potvrzují závislost na těchto třídách. Ještě jsem se nezmínil o poslední abstraktní třídě ICSPlugin. Ta je snad nejdůležitější ze všech. Je to abstraktní třída, která předepisuje společné metody pro všechny ICS pluginy. Pokud tedy chci vytvořit nový ICS plugin pro svou ICS službu, musím vytvořit novou třídu, která dědí právě z ICSPlugin třídy. Celá infrastruktura ICS klienta, jak je vidět na modelu, pracuje právě jenom s touto abstraktní třídou. Pokud se někdo ptá, proč je to možné. Je to vlastně princip objektově orientovaného programování, kdy potomky tříd mohu použít všude tam, kde se vyžaduje typ rodičovské třídy.

Tato třída předepisuje metody právě pro generování menu, ukončovací operace, vrací název daného ICS pluginu a další metody, které jsou volány ostatními třídami. Nástroje, které mají být používány při práci s ICS pluginy a službami vůbec, jsou reprezentovány třídami, které obsahují formulář (FindForm, LoadForm, …). Jejich obsah je již z výše uvedeného popisu UDDI znám. Obsahem je zde myšlena funkčnost, kterou budou nabízet uživateli prostřednictvím grafického uživatelského rozhraní.

6.4.Infrastruktura na straně serveru Infrastruktura na straně serveru je o něco jednodušší. Většina potřebného kódu je již implementována v systému a o ICS služby se stará webový server, popřípadě UDDI registry, kde se ukládají informace o ICS službě s vlastním tModelem pro specifikaci kategorií ICS služeb. TModel slouží k vytváření filtru, abychom se při hledání zajímali pouze o ICS služby. V rámci technologie .NET a implementace webových služeb nám .NET Framework nabízí abstraktní třídu WebService a další třídy pro sestavení celé XML webové služby. To nám velice zjednodušuje návrh. Nejdříve bude upřesněno, jak se vytváří obyčejná XML webová služba pomocí

.NET

FrameWorkeru

SDK.

Z této

sady

máme

k dispozici

zmiňovanou třídu WebService, která reprezentuje celou webovou službu. Pro vytvoření webové služby, například HelloWorld, vytvoříme novou třídu HelloWorld, která bude dědit

od

třídy

WebServices.

V této třídě

implementujeme metody, které má nabízet k veřejnému publikování na intranet, a které jsou pouze pro interní potřeby. Metoda, která je určena k publikování, se liší od privátní metody informacemi pro celou assembly. Vzhled můžeme vidět na následujícím příkladu, kde máme metodu, která nám vrátí nějaký řetězec:

Obrázek č.10: Základní třída pro vytváření ICS služeb [WebMethod] public string HelloWorld() {}

Obdobně jak u ICS klienta i zde potřebujeme trochu sjednotit funkčnost

ICS

služeb.

Proto

v následujícím

modelu

můžeme

vidět

začlenění třech webových metod, které nám zajistí zjišťování jména webové služby, což také jde zjistit z WSDL popisu dané služby, stažení ICS pluginu pro instalaci na klientském počítači a metoda pro zjištění verze dané ICS služby, kvuli aktualizacím ICS pluginů. Bohužel na straně serveru nejsou žádné nástroje, které by pomohli obyčejným uživatelům při práci s ICS službami. Jediným krokem na straně serveru je instalce, popřípadě registrace, nové ICS služby. O vše ostatní se již stará webový server, .NET framework a nástroje, které jsou již součástí .NET Frameworkeru.

7. Literatura [1] Samtani G.: Top five Web service myths. Aug. 2002, Builder Architect - Web Services [2] Buranský, I.: XML a webové služby. Prienik do XML cez Microsoft.NET a Murphyho zákony. Microsoft Praha 2003, 132 str. [3] Travis B. E.: XML a SOAP Programování serverů BizTalk. Computer Press Praha 2000, ISBN 80-7226-303-X, 419 str. [4] Standard SOAP. http://www.w3.org/TR [5] Standard WSDL. http://www.w3.org/TR [6] Standard UDDI. http://www.uddi.org/specification.html [7] Champion M., Ferris Ch., Newcomer E., Orchard D.: Web Services Architecture. W3C Working Draft 14 November 2002 [8] http://atm.felk.cvut.cz/mps/referaty/2004/patockam [9] Třísková L.: Zaostřeno na .NET a webové služby. Softwarové noviny 8/01, str. 108 – 109 [10] Ewald T.: Understanding XML Web Services. Microsoft Corporation, September 2002 [11] Vít I.: Visual FoxPro a webové služby, http://www.dbsvet.cz/view.php?cisloclanku=2005010501 [12] Tomek M.: UDDI aneb jak sehnat webovou službu, http://nb.vse.cz/~zelenyj/it380/eseje/xtomm19/uddi.htm [13] Kraus T.: UDDI, http://nb.vse.cz/~zelenyj/it380/eseje/xkrat02/UDDIsmpr.htm [14] http://uddi.org/pubs/uddi-v3.0.2-20041019.htm [15] Stein R.: http://interval.cz/clanek.asp?article=2783 [16] Stein R.: http://interval.cz/clanek.asp?article=2977 [17] Tišnovský P.: http://www.root.cz/clanky/nastroje-pro-tvorbu-umldiagramu/