Technologie webových služeb vystavěných z Javy

Webové služby slibují krásný nový svět snadné softwarové integrace s využitím XML a internetu. Jelikož jsou založ...


Webové služby slibují krásný nový svět snadné softwarové integrace s využitím
XML a internetu. Jelikož jsou založeny na XML, mají potenciál posloužit jako
tmel nezávislý na platformách mezi aplikacemi napsanými v různých
programovacích jazycích a běžícími na různorodých operačních systémech. Mnozí
odborníci tuto schopnost popisují jako svatý grál distribuovaných výpočetních
systémů. Dokonce ani Java ve své nejčistější podobě se nemůže vyrovnat
snadnosti integrace a výměně distribuovaných dat, jakou nabízejí webové služby.
IT organizace mají dnes k dispozici dostatek cest pro implementaci webových
služeb. Dokonce i v rámci iniciativy open source jsou k tomuto účelu nabízeny
tucty nástrojů včetně Apache, Perlu, Pythonu a PHP. Microsoft zase poskytuje
platformu .Net. A "javovští" vývojáři mohou samozřejmě implementovat webové
služby na stejné platformě, jakou používají pro provoz svých současných
webových aplikací, tedy na aplikačním serveru J2EE.
Vývojářům v Javě se přechod k webovým službám prostě jeví jako další logický
krok. Takže dodavatelé komerčních platforem J2EE také naskočili do tohoto vlaku
a přidali do svých vývojových nástrojů a aplikačních serverů speciální
schopnosti z oblasti webových služeb. Jak důležité jsou tyto vlastnosti pro
usnadnění tvorby a nasazení webových služeb? Nakolik skutečné jsou jejich
výhody oproti iniciativě open source? Který aplikační server J2EE je nejlepší
platformou pro webové služby?
Abychom to zjistili, oslovili jsme dva přední dodavatele komerčních serverů
J2EE: Společnosti BEA System (nabízí produkt WebLogic) a IBM jež dodává
aplikaci WebSphere. Dále jsme tyto produkty doplnili o EAServer od Sybase a
nejpopulárnější J2EE server iniciativy open source JBoss, a všechny jsme
otestovali. Na každé z těchto platforem jsme zprovoznili webové služby a
hodnotili jsme jejich nástroje pro správu i jejich podporu základních standardů
webových služeb, SOAP, XML-RPC (Remote Procedure Call), WSDL a UDDI. Také jsme
"pokukovali" po flexibilní konfiguraci a sadě vlastností, jako jsou podpora JMX
(Java Management eXtensions), JNDI (Java Naming and Directory Interface), JMS
(Java Messaging Service) a JTA (Java Transaction API), které se dají očekávat u
jakékoliv celopodnikové javové platformy.
Podle našeho testovacího scénáře jsme implementovali vícevrstvý dodavatelský
řetězec složený ze čtyř webových služeb. Jedna služba umožňovala koncovému
zákazníkovi koupit produkt od maloobchodního dodavatele. Druhá služba
umožňovala maloobchodnímu dodavateli obratem nakoupit velkoobchodní zboží od
dodavatele. Třetí umožňovala velkoobchodníkovi nakoupit surový materiál od
dodavatele dílů. Konečně čtvrtá služba umožňovala všem těmto subjektům sledovat
jejich dodávky. Všechnu tuto obchodní logiku jsme naprogramovali v Javě a
vytvořili jsme adaptéry pro implementaci každé komponenty jako webové služby.
Hlavní výhodou webových služeb je flexibilita umožňující měnit aplikační logiku
beze změn rozhraní služeb a bez obtěžování obchodních partnerů. Zprovoznění,
modifikace, znovuzprovoznění a zajištění, že vaše webové služby jsou stále k
dispozici, jsou klíčové přísady úspěšného receptu na webové služby. Proto se
náš test soustředil na to, jak hladce se naše čtyři řešení vyrovnala s těmito
úlohami. Více detailů o průběhu testování naleznete ve vloženém textu Jak jsem
testovali.

Alternativa open source
Aby mohlo řešení založené na open source soupeřit s komerčními účastníky,
potřebovalo by několik prvků. Jako aplikační server jsme v našem případě
zvolili JBoss 3.2.1 (v době testování jsme ještě neměli k dispozici verzi 4.0,
která je již nyní na trhu), protože je všeobecně považován za nejpopulárnější a
bohatě vybavený funkcemi dostupný aplikační server J2EE. Jako prostředí pro
provoz servletů jsme použili Apache Tomcat 5.0 a Apache Axis jako implementaci
SOAPu.
Instalace všech těchto nástrojů byla jednoduchá. Na rozdíl od komerčních řešení
nepotřebují JBoss a Tomcat propracované instalační rutiny. Prostě se aplikační
soubory dekomprimují z archivů zip nebo tar (v závislosti na platformě) do
zvoleného adresáře, a následně vše běží. Díky malé velikosti a jednoduchosti
instalace lze také snadno vytvořit bezobslužné instalační skripty.
Stinnou stránkou jednoduché instalace se posléze ukázal být nedostatek
konfiguračních možností. Vše, co jsme měli u serveru Jboss k dispozici, byly
dva základní nástroje aplikační manažer a administrační nástroj. Oba jsou
funkční, ale sporné co do vlastností a přizpůsobitelnosti. Buď pracujete jejich
způsobem, nebo použijete něco jiného. I tak zde ovšem naleznete většinu
vlastností, které potřebujete pro celopodnikové řízení za předpokladu, že se
seznámíte s JMX (Java Management eXtensions). Architektura JBossu je totiž
založena na JMX a MBeans, a server používá pro specifikaci konfiguračních
informací variantu syntaxe JMX Mlet.
Ve srovnání s nástroji založenými na grafickém uživatelském rozhraní,
dodávanými s produkty WebLogic, WebSphere a EAServer, byly spravovací
vlastnosti produktů Axis, Tomcat a JBoss průměrné. Administrace serveru
založeného na open source byla obtížnější než v případě kteréhokoliv komerčního
řešení, především kvůli hloubce znalostí, potřebných pro přizpůsobení či pro
změnu čehokoliv.
Produktu JBoss scházely nástroje pro správu velkých víceserverových
celopodnikových instalací. Viděno z té lepší stránky jakmile byl server správně
nakonfigurován, bylo sotva potřeba jej vůbec spravovat, prostě šlapal a šlapal.
Avšak k dispozici jsou díky partnerství s několika dodavateli řešení založených
na open source některé správcovské nástroje třetích stran, jako jsou například
management výkonnosti a software pro organizaci webových služeb.
V našem implementačním testu jsme vzali standardní archivní soubor J2EE s
příponou .war a zprovoznili jsme jej s použitím nástroje Tomcat Application
Manager bez jakýchkoliv potíží. Měli jsme přitom na výběr z několika
implementačních nástrojů včetně nástroje Tomcat Application Manager, dále
populárního nástroje založeného na open source Ant nebo konfiguračního souboru
XML. Po instalaci nebylo třeba restartovat server. Prostě jsme vše
nainstalovali a začali používat.
Odinstalování proběhlo také bez zvláštních událostí, jakmile jsme přišli na
kloub správcovským nástrojům. Byli jsme schopni odstranit aplikaci bez
restartu. Měli jsme také možnost prostě aplikaci zastavit bez odstranění a
rekonfigurovat ji off-line. Stejně jako s WebSphere jsme nicméně museli po
modifikování a znovuzprovoznění aplikace restartovat server.
Jedna věc však jasně vyplynula z našeho testování na povrch JBoss podporuje
všechny relevantní standardy. Jen tak nečiní prostřednictvím menu, průvodců
nebo mile hovořících ikon, musíte znát syntax J2EE a Javy. Pokud spadáte do
této kategorie uživatelů, JBoss může poskytnout granularitu řízení aplikací,
které konkuruje pouze produkt Web Services SDK nabízený IBM.
Na obzoru jsou rovněž rozsáhlé změny. Verze JBoss 4.0, která již je v tuto dobu
na trhu, má nové vlastnosti včetně vylepšeného mikrojádra JMX, které umožní
individuální přidávání vlastností a komponent. Dále používá nový programovací
rámec zvaný AOP (Aspect Oriented Programming). Vývojářské týmy tak budou moci
změnit čisté staré javové objekty tak, že budou moci imitovat funkcionalitu
J2EE, nebo dokonce do nich zavést transakční atributy typu EJB. Bitva mezi
komerčními nástroji a inovacemi iniciativy open source má tedy ještě daleko do
konce.

Seminář webových služeb
WebLogic od společnosti BEA byl prvním komerčním produktem, který jsme
testovali následně po našem úvodním testu produktu založeném na open source, a
rozdíly byly patrné okamžitě. WebLogic nabízí plný rozsah konfiguračních
možností, bohatou sadu vlastností produktu celopodnikové třídy a elegantní
grafické rozhraní pro jejich implementaci. Nejenže všechno běželo správně hned
po instalaci, ale navíc zprovoznění trvalo pouze několik minut a to je v
případě celopodnikově orientovaného vývojového prostředí velice působivé.
Zapůsobila na nás také flexibilita instalačního procesu, který byl velice
efektivní a jednoduchý, dovoloval rychle označit a vybrat, které komponenty se
mají instalovat a které registrovat jako služby na serveru s Windows. Vítaným
přídavkem by byl skript pro bezobslužný instalační proces, který by zjednodušil
případnou instalaci na více serverů.
Po instalaci nám konfigurování WebLogicu přichystalo několik překvapení.
Největším z nich byla frekvence, s níž jsme museli restartovat server. WebLogic
je napsán ve "stoprocentní" Javě, což by obecně mělo znamenat méně restartů.
WebLogic je dále navržen jako aplikační platforma celopodnikové úrovně, takže
je obtížné pochopit, proč nás BEA nutí shazovat a zase nahazovat pracovní
server kvůli změnám v konfiguraci se stejnou lehkostí, jako by šlo o vypínání
příchozího portu HTTP.
Stesky ale stranou, flexibilita, kterou jsme zažili při instalačním procesu
WebLogicu, pokračovala i při konfiguraci serveru. Například je zde rozsáhlá
sada konfiguračních možností pro individuální instance serveru, které umožňují
rekonfigurovat prakticky každý aspekt základní konfigurace, cluster, provozní
nastavení a ladění výkonnosti. Je zde také podpora pro konfigurační nástroje
založené na nástroji Ant, která poskytuje vestavěnou kontrolu souladu se
standardy.
Ve WebLogic Serveru je celá řada nových celopodnikově orientovaných
správcovských a konfiguračních nástrojů, které se nám velice líbily. Například
je zde vylepšený průvodce konfigurací domén a průvodce pro nastavení
serverových clusterů, psaní bezpečnostních pravidel, a dokonce pro konfiguraci
databázových zdrojů.
V průběhu testování pracoval WebLogic dobře, ale s několika zádrheli. Za prvé
jsme museli upravit naši testovací aplikaci, aby pracovala specificky na
WebLogicu. Za druhé, i když jsme se o to pokoušeli, nebyli jsme schopni
zprovoznit naši testovací aplikaci přímo z konzole serveru. Místo toho jsme
museli použít nové doprovodné IDE (integrované vývojové prostředí) společnosti
BEA, WebLogic Workshop. Za třetí, po zprovoznění aplikace bylo snadné
rekonfigurovat ji prostřednictvím konzole, ale každá změna vyžadovala restart
serveru.
WebLogic Workshop také měl svou porci světlých a stinných stránek. Workshop
poskytuje jakožto nástroj šetřící čas při tvorbě J2EE aplikací a webových
služeb vizuální vývojové prostředí podobné Visual Studiu od Microsoftu. Navíc
Workshop nabízí provozní rámec, který řídí uvádění služeb do provozu, a také
přidává testovací a ladicí vlastnosti. Všechny přísady úspěšného IDE jsou ve
Workshopu obsaženy, zdál se nám být ale trochu "syrový". Například jeho funkce
pro import vyžaduje, aby všechny programové soubory webových služeb byly
přejmenovány na ty s příponou .jws (Java Web Services), a to je třeba udělat s
dodatečnou modifikací vyžadovanou pro obsluhované metody. Bylo by také hezké,
kdyby Workshop vyvinul určitou snahu rozeznat metody služeb, i kdyby jen prostě
nabídl vývojářům nabídkový seznam možných voleb. Za stávajícího stavu se musíte
ponořit do zdrojového kódu a přidat speciální značku "@" do JavaDoc, aby IDE
bylo schopno rozeznat metody použité ve službách. Od společnosti jako BEA jsme
v oblasti vlastností pro import očekávali o trochu více, například umožnit
vybrat, ve kterých případech se jedná o soubory webových služeb, a poté se
postarat o jejich přejmenování automaticky.
Celkově navzdory množství našich připomínek, jak vylepšit WebLogic a jeho
doprovodný Workshop v příštích verzích, jsme zjistili, že tyto nástroje v našem
testovacím scénáři zprovoznit, modifikovat a znovu zprovoznit, obstály velice
dobře. Jakmile si zvyknete na požadavky Workshopu na pojmenování a popis,
integrace mezi IDE a serverem je skutečně velice působivá.

Seznamte se s WebSphere
První věcí, které si u WebSphere 5.0 a WSAD (WebSphere Studio Application
Developer) všimnete, jsou CD. Je to jako byste otevřeli reklamní balíček od
Columbia Records v dodávce naleznete celkem 54 disků.
IBM na nich dodává aplikační servery pro veškeré operační systémy včetně
příslušných klientů, databázový systém DB2, sady nástrojů, manažera rozmístění,
adresářový server a mnohé další. Když se tím vším probíráte, je těžké nenabýt
dojmu, že jste dostali za své peníze slušnou hodnotu.
Navzdory tomuto nadbytku je instalace dostatečně jednoduchá, i když neočekávaně
náročná na čas. Ve skutečnosti jsme měli větší potíže zjistit, která CD máme
instalovat, než potom s jejich instalací. Dokonce v dodávce najdete také
jakéhosi "verifikátora" instalace, který zkontroluje, zda je všechno správně
nainstalováno.
Konfigurace WebSphere je také nekomplikovaná a IBM přidala některé vlastnosti,
které se nám líbily, jako například prohlížeč logu. Nepoužívá se tak snadno
jako stejný nástroj od Sybase, ale má vestavěný opravdový analyzér logu.
Systémovým administrátorům se také bude líbit Performance Viewer, který jim
umožňuje sledovat souhrnnou zprávu o systémových zdrojích včetně využití EJB,
HTTP a dalších.
IBM věnovala velkou pozornost potřebám velkých, distribuovaných prostředí pro
publikování webových služeb. Volby WebSphere pro provoz v síti obsahují několik
nástrojů ve stylu průvodců navržených speciálně pro uvádění do provozu,
konfiguraci a správu webových služeb v prostředí velkého počtu serverů a
serverových clusterů. Některé z těchto nástrojů lze automatizovat, a pro ty,
kteří si oblíbili příkazovou řádku, IBM stále poskytuje spoustu funkcionality i
zde.
Náš praktický test probíhal u WebSphere výjimečně hladce. Na jednu stranu byla
extrémně snadno a intuitivně použitelná nemuseli jsme dokonce nijak podrobně
studovat dokumentaci. Ani nás nenutila dělat nějaké specifické změny do naší
testovací aplikace, abychom ji rozchodili. Ve skutečnosti WebSphere poskytuje
stejně hladkou podporu standardům jako JBoss.
WebSphere dále nainstalovala všechny naše J2EE specifické komponenty bez
přejmenovávání nebo jiných problémů (zkoušeli jsme jich spoustu včetně souborů
J2EE s koncovkami .ear, .ejb, .jar a .war). Na rozdíl od WebLogicu žádná ze
změn konfigurace nevyžadovala restart serveru.
Odinstalování testovací aplikace bylo podobně působivé, i když psát o něm není
tak vzrušující. Aplikace prostě zmizela bez potřeby restartu. Znovuzprovoznění
se odehrálo téměř stejně hladce, i když v tomto případě server vyžadoval
restart.
Měli jsme málo důvodů k použití doprovodného IDE WebSphere, nástroje WSAD,
protože většina procesu publikování webových služeb je vestavěna přímo do
konzole samotné WebSphere. Použili jsme WSAD při testování importu, podobně
jako jsme použili Workshop WebLogicu, a IDE importovalo všechny naše komponenty
J2EE bez zádrhele i když mu provedení tohoto úkolu trvalo spíše déle. Jakmile
byly naše služby importovány, použili jsme WSAD pro jejich modifikaci a
shledali jsme, že IDE orientované na webové služby je hodné jména Velké modré.
WSAD nás také nadchl svou těsnou a pečlivou integrací s aplikačním serverem
WebSphere. V rámci vysoce přizpůsobitelného IDE najdete nástroje na správu
všech aspektů vytvořené nebo importované aplikace bez ohledu na její zdroj, ať
je to EJB nebo webová služba. Import je speciálně jednoduchý, protože WSAD
umožňuje vyhledávat a integrovat všechny webové služby třetích stran přímo z
IDE. Je zde dokonce i jednoduchý nástroj pro publikování na testovací nebo
provozní server UDDI od IBM; podporuje i ostatní servery UDDI, ale ne jako
standardní volbu. Pro ty, kteří mají zájem o větší porci příkazové řádky a o
méně grafického rozhraní, IBM také dodává WebSphere SDK, i když my jsme neměli
možnost tento produkt otestovat. SDK se skládá ponejvíce z nástrojové sady
Apache Axis, ale je doplněn také odlehčenou verzí serveru WebSphere.
V kostce se WebSphere řadí vysoko jakožto velmi dobře spravovatelná platforma
pro publikování webových služeb. I když je produkt zřetelně zaměřen na oblast
větších společností, malé podniky mohou tuto sadu nástrojů také skvěle využít,
pokud si mohou za něj dovolit zaplatit vyšší cenu. Pro menší společnosti má IBM
ve svém portfoliu řadu produktů označenou jako WebSphere Express, která nabízí
méně funkcí za nižší cenu.

Služby podle Sybase
EAServer 4.2 společnosti Sybase se odlišuje intuitivním a efektivním IDE a
relační databází celopodnikové třídy. Nicméně jej poškozuje chybějící podpora
pro některé standardy z oblasti webových služeb, jmenovitě JMX. A ačkoliv se
EAServer vypořádal s naším testem bez větších problémů, jednoduše není tak
"nablýskaný" jako např. WebSphere.
Instalace sady EAServeru byla jednoduchá. Líbila se nám snadná možnost označit
a vybrat ty komponenty, které pro instalaci potřebujeme. Jakmile bylo vše
nainstalováno, server se rovnou rozběhl.
EAServer v nové verzi obsahuje několik nových vlastností specifických pro
webové služby. Jsou zobrazené na levé straně obrazovky ve stromovém formátu a
zahrnují provozní nástroj, instalační nástroj a sekci programů, které zahrnují
aplikace pro zabalení, zprovoznění a instalaci webových služeb. Potřebujete
více funkcionality? EAServer dovoluje vývojářům psát plug-in moduly pro řídicí
konzoli pro ještě pokročilejší přizpůsobení.
Také se nám líbily navigační schopnosti EAServeru disponuje skutečně účelně
vystavěným prostředím. To znamená, že nejste omezeni na prvky uživatelského
rozhraní a na potenciální bezpečnostní nedostatky správcovské konzole založené
na webu. Dokonce ani WebSphere od IBM neposkytuje tak efektivní rozhraní. A pro
ty, kteří ho chtějí, Sybase povoluje plnou správcovskou funkcionalitu na
příkazové řádce.
Náš test proběhl bez jakýchkoliv potíží, i když jsme museli restartovat server
pro přístup k opakovaně zprovozňované aplikaci. Sybase a WebLogic převážně
sledují stejné kroky pro uvedení aplikace do provozu: za prvé nahrát, za druhé
nainstalovat a za třetí restartovat server.
Mezi hezkými vlastnostmi, na které jsme narazili, bylo vestavěné verzování,
které usnadňuje sledování iterací provozované aplikace a návrat k předchozí
známé funkční verzi, pokud je třeba. EAServer také dovoluje exportovat aplikaci
zpět do standardního souboru J2EE s koncovkou .war nebo .jar. Tuto schopnost
jsme nenašli u produktů WebLogic nebo JBoss. Nejedná se o průlomovou
záležitost, ale tento šikovný nástroj je dobré mít po ruce.
Celkem vzato EAServer fungoval velice dobře i bez přibaleného IDE orientovaného
na webové služby. Nicméně jeho schopnost importu a exportu jakýchkoliv
programových souborů standardu J2EE znamená, že vývojáři nejsou svázáni s
žádným určitým IDE, ale mají svobodnou volbu z ohromné nabídky produktů třetích
stran.
Jakožto platforma pro publikování webových služeb by EAServer unesl některá
vylepšení, jako je podpora pro Microsoft .Net. Nejsme zasvěcení do toho, co
Sybase plánuje pro příští verzi, ale jestli EAServer zahrne správnou kombinaci
nových vlastností, bude to v budoucích iteracích silný konkurent mezi
platformami pro správu webových služeb.

Proč webové služby v Javě?
Java nabízí spoustu nástrojů a API, které usnadňují vývoj webových služeb.
Webové služby nejsou technologie samy pro sebe, ale spíše jde o nový
programovací model, který prostě využívá několik obecných technologických
specifikací. Základními stavebními kameny webové služby jsou některé formy XML
messagingu, jako jsou SOAP nebo XML-RPC (Remote Procedure Call) a webový
komunikační protokol, nejčastěji HTTP nebo HTTPS. Existují také standardy pro
popis rozhraní webové služby (WSDL), zajišťující integraci služeb a publikování
informací o službách v adresářích (UDDI), aby je potenciální uživatel mohl
najít.
Mnozí dodavatelé včetně Microsoftu prohlašují, že podporují specifikace SOAP,
XML-RPC, WSDL a UDDI, takže kde je přesvědčivý argument pro použití J2EE? Žádný
neexistuje. Webové služby jsou prostě poslední model distribuovaného
programování pro web, což řadí servery J2EE do standardní nabídky. Společnosti
již provozují webové aplikace na aplikačních serverech J2EE, a budou chtít
mnohé z těchto aplikací vystavit jako webové služby. Takže je smysluplné
implementovat webové služby na stejné platformě.
Mezi přednosti javové cesty k webovým službám patří například spousta nástrojů
a API určených pro jejich vývoj. Například JAXR (Java API pro XML registry)
používá několik nástrojů J2EE zejména UDDI4J (javová implementace UDDI) a
WSIL4J (Web Services Inspection Language pro Javu) pro řízení konverzního
procesu mezi registrovanými prvky UDDI a javovým modelem objektů a tříd.
Významní dodavatelé produktů založených na J2EE také přidali k webovým službám
nástrojové menu. IBM prosazuje WSDL2Java a Java2WSDL, dva nástroje, které
generují Javu z WSDL a obráceně WSDL z Javy.
Pro zjednodušení vývoje koncových bodů protokolu SOAP existuje JAX-RPC (Java
API pro XML-RPC), který používá javovou verzi protokolu SOAP. Konečně Java se
orientuje na programování typu objekty/třídy/metody, zatímco XML se nutně
orientuje směrem k dokumentovému paradigmatu. Takže nějaká konverzní
technologie je potřeba dokonce již na této základní úrovni. A tady opět Java
nezklame, její JAXP (Java API pro zpracování XML) obsahuje nástroje na rozbor
dokumentů DOM (Document Object Model) a SAX (Simple API pro XML) v rámci
vývojového prostředí pro Javu.
J2EE 1.4 (uvolněna toto léto), zahrnuje ještě více vlastností určených pro
webové služby. Mezitím společnosti, které již používají aplikační servery pro
vývoj a provoz webových aplikací, se lépe vyrovnají s vývojem webových služeb s
využitím nástrojů, o nichž zde píšeme.
Ti, kteří se dnes na trhu poohlížejí po aplikačních serverech J2EE, by se měli
ujistit, že obsahují vývojářské a správní nástroje určené pro tyto technologie.
Většina komerčních aplikačních serverů toto splňuje a navíc přinášejí jiné
důležité výhody včetně podpory pro celopodnikové databáze a stávající systémy,
granulární monitorování a správu a vlastnosti zvyšující spolehlivost, jako jsou
clusterování, vyrovnávání zátěže a přidělování a seskupování zdrojů.

Jak jsme testovali
Pro náš test jsme vyvinuli čtyři webové služby s použitím produktů CodeWarrior
a Eclipse společnosti Metrowerks. Naprogramovali jsme naši obchodní logiku a
obchodní objekty v Javě. Potom pro implementaci každé komponenty jakožto webové
služby jsme vytvořili adaptéry k obchodní vrstvě. S použitím nástroje
verifikujícího soulad se standardy od IBM a nástroje The Mind Electric jsme se
ujistili, že naše všechny čtyři aplikace striktně dodržují čtyři základní
standardy v oblasti webových služeb: SOAP, XML-RPC, UDDI a WSDL.
Naše čtyři webové služby byly svázány dohromady do simulované víceúrovňové
aplikace pro dodavatelský řetězec. Ke dvěma z našich služeb se přistupovalo s
využitím standardu SOAP, ke druhým dvěma se přistupovalo s využitím XML-RPC.
Naše první služba Dodávka dílů umožňovala zákazníkovi zkontrolovat úroveň
dodavatelských skladových zásob na základě čísla dílu a jeho popisu, také jim
umožňovala tyto díly koupit. Naše služba Dodávka výrobků nakupovala surový
materiál ve formě dílů a uskladnila je k prodeji jako hotové výrobky, také
poskytovala informace o úrovni skladových zásob výrobků. Naše služba Maloobchod
s výrobky nakupovala hotové výrobky a obratem je uskladňovala k prodeji
maloobchodním zákazníkům prostřednictvím nákupních a skladových služeb. Konečně
naše služba Přepravce se starala o dopravu dílů a výrobků k jejich zákazníkům a
zároveň umožňovala sledování zásilek.
Protože tyto webové služby byly implementovány jako adaptérová vrstva nad
vrstvou obchodní logiky, všechny systémy prodejců byly provázány dohromady
automaticky. Takže pokud úroveň skladových zásob v Maloobchodě s výrobky klesla
na předdefinovanou úroveň, byla spuštěna služba Dodávka výrobků, zkontrolovala
úroveň skladové zásoby výrobků a učinila nákupní objednávku.
Pro běh našich testů jsme používali JUnit, protože tento nástroj dovoluje
automatizované skriptování v Javě. JUnit simuloval maloobchodního zákazníka,
nakupujícího dokončené výrobky prostřednictvím služby Maloobchod s výrobky.
Protože všechny služby byly automaticky navzájem provázány, každý požadavek
maloobchodního klienta způsobil interakce mezi různými webovými službami.
Importovali jsme naše testovací webové služby na každý aplikační server s
použitím řídicí konzole produktu nebo v případě společností BEA a IBM s
využitím řídicí konzole a doprovodného IDE. Prostřednictvím stejného rozhraní
jsme pak aplikace zprovoznili. Po průběhu sekvence příkazů JUnitu v této
konfiguraci jsme aplikaci odstavili z provozu s použitím stejných řídicích
nástrojů a pak jsme modifikovali balíček služeb změnou detailu a formátu
informace o dílech, zveřejňované službou Dodávka dílů. Namísto prostého použití
řetězcové reprezentace informace o dílech byla služba změněna tak, že vracela
aktuální objekt s informací o dílu. Změnu jsme v případě produktů společností
BEA a IBM dělali přibaleným IDE, s použitím nástrojů Eclipse a Ant v případě
produktů JBoss/Tomcat a pro EAServer jsme použili CodeWarrior. Konečně po
modifikaci pro zohlednění naší změny v informaci o dostupnosti dílů jsme
aplikaci znovu uvedli do provozu s použitím řídicí konzole nebo doprovodného
IDE.
Všechny naše testy jsme prováděli s použitím počítače Compaq ProLiant DL360 se
dvěma procesory 1 GHz Xeon a s 1 GB RAM s OS Windows 2000 Server s
nainstalovaným Service Packem 3. Tento server byl připojen do testovací sítě
prostřednictvím směrovacího přepínače Intel 550R 10/100. Zbytek sítě se skládal
ze tří klientů založených na stolních počítačích Dell Dimension s procesory
Pentium III 1 GHz, s 512 MB RAM a s OS buď Windows XP Professional (Service
Pack 1) nebo Windows 2000 Professional (Service Pack 3).









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.