A jak do toho celého zapadá WebCenter?
Před zodpovězením této otázky je ještě na chvíli zastavme u termínu integrace. Máme-li připravené moduly, propojitelné pomocí otevřených standardů, pořád ještě někdo tyto stavební kostky pospojovat. Zůstanete-li v oraclovském světě, uděláme to za vás, pro některé neoraclovské systémy, se kterými se setkáváme často to uděláme také, pro jiné však budete potřebovat systémového integrátora či pár vlastních architektů a vývojářů.
Pokud bychom šli odspodu, pro kompozitní aplikace může být zajímavá i datová integrace, tj. sloučení mnoho, často heterogenních zdrojů, aby uživatel mohl dostat jednotný pohled na data organizace. To jsme ve světě BI, DWH či data miningu a na toto téma najdete spoustu zajímavého čtení na blogu kolegů.
Další vrstvou integrace je integrace na úrovni aplikací, což dnes zpravidla znamená využití web services, SOAP či XML messages. Pokud se jedná o orchestrované systémy, tady samozřejmě musí přiložit ruku k dílu jejich tvůrci. O backend processing se však už dokáží postarat komponenty middleware (u Oracle to je Oracle BPEL Process Manager). Kromě backendu je však potřeba občas interagovat i s uživatelem - a to je přesně místo pro WebCenter. Tím, že součástí licence WebCenter Suite je limitovaná licence BPEL PM, jsou v rámci WebCentra dodávány i hotové komponenty pro tzv. "human workflows", tj. pracovní seznamy apod.
Poslední vrstvou, kdy je možné integraci provést, je prezentační vrstva. Zde může WebCenter přispět dvěma způsoby:
1. pro již hotové aplikace je možné využít produkt Ensemble, který umí na úrovni proxy "smíchat" výstupy z několika výstupu (mashup) a dosáhnout tak efektu kompozitní aplikace tak říkajíc ad-hoc. Tento přístup se dá použít i při přechodu z existujících aplikací na nový framework (umí nejen Java a .NET aplikace, ale i skriptovací jazyky jako Perl či PHP). Jeho evidentním nedostatkem bude výkonnost. Výhodou je naopak to, že "smíchání" může provést zkušenější uživatel - vůbec tedy na něj nepotřebujete vývojáře!
2. pro vytvářené aplikace je možné využít WebCenter Framework a tím připravit aplikaci, aby jak uměla začlenit zdroje třetích stran (portlety či jiné zdroje), ale také aby se sama prakticky bezpracně stala takovýmto zdrojem. Není asi tajemstvím, že tímto způsobem jsou či budou upraveny i aplikace Oracle jako je Siebel, Peoplesoft či EBS. Postranním efektem je pak obohacení těchto aplikací o Web2.0 funkce jako je tagging, diskuze, online messaging apod.
Základní myšlenkou kompozitních aplikací je poskytnout uživatelům takovou funkcionalitu, jakou měli či mají ERP systémy, ale při zachování uživatelského komfortu a flexibility, na kterou jsou uživatelé zvyklí z portálových řešení a WebCenter je produkt, který pro tento požadavek nabízí unikátní výhody.
Tím, že odjíždím na dovolenou, se s Vámi až do září loučím. Užijte si konec prázdnin.
Showing posts with label composite applications. Show all posts
Showing posts with label composite applications. Show all posts
Wednesday, 11 August 2010
Wednesday, 28 July 2010
WebCenter - kompozitní aplikace, 1. část
Abychom si na chvíli odpočinuli od UCM 11g, pojďme se věnovat jinému produktu, který by v fiskálním roce 2011 mohl mít úspěch - WebCentru.
Jedním z konceptů, na které se tento produkt velmi dobře hodí, jsou tzv. kompozitní aplikace (viz. např. definice na Wikipedii). O co jde? Zejména ve větších organizacích platí, že uživatelé přistupují v rámci svých pracovních povinností ke mnoha systémům. Zpravidla však ne všichni ke všem. Navíc, zde jako nikde jinde v IT může platit, že hodnota celku je výrazně větší než součet jednotlivých komponent.
Samozřejmě, to už tu jednou bylo - a říkalo se tomu Enterprise Resource Planning (ERP), což je termín, který se zdá v současnosti spíše na ústupu ze slávy. Proč?
V jednom speciálním Zverimexu prodávali opice. Opice byly poměrně drahé a tak to jednomu zákazníkovi nedalo a zeptal se, proč jedna opice stojí celých 5000 dolarů. "No tahle umí programovat v jazyce C," dostalo se mu odpovědi od prodavače. "A co umí tahle za 10000?" nedal se odradit zákazník. "No ta umí ještě C++." "A co tahle za 50000?" ptal se s úžasem zákazník. "No, to nevíme, ale říká, že je to konzultant na SAP."
Pokud se to někoho dotýká, nechť si klidně dosadí Oracle EBS či Siebel. V době, kdy jsem vtip poprvé viděl, jsem byl zaměstnán ve Walldorfu, tak mám na tuto verzi morální právo.
Kromě ceny však mají ERP systémy ještě několik dalších problémů, které by se daly shrnout pod termín nedostatek agility, tj. neschopnost dostatečně reagovat na měnící se podmínky či požadavky zákazníků, neschopnost integrace s okolím, pokud někdo jiný nabízí něco zajímavého a pak vysoké nároky na pracovníky obsluhující řešení díky značnému využití proprietárních technologií či know-how.
Jakkoli jistě ani v Oracle není vše ideální, přeci jen byl Larry Ellison jedním z prvních pionýrů, který nastínil nový trend (viz např. Fusion Application).
Kompozitní aplikace stojí na třech pilířích:
Pokud jde o standardizaci, to je velmi vstřícný krok směrem k zákazníkům - máte-li již nějaké řešení, které podporuje standardy, nebo zdá-li se vám v nějaké oblasti jiné řešení lákavější, budeme vás rádi podporovat tam, kde si nás vyberete. Pod standardizaci patří hesla jako XML, XSLT, web services, SOAP, UDDI, BPEL, či BPMN, tedy něco, co Oracle podporuje, ale zdaleka nekontroluje.
A de-coupling? Některé v současnosti velmi úspěšné produkty (např. Oracle Business Intelligence SE1 či EE) vznikly odštěpením (zde od balíku Siebel). Ještě zajímavější je tento koncept však z pohledu samotných aplikací, které jsou psány modulárně (např. správa uživatelských účtů se bere skutečně jako nezavislý modul, takže je v zásadě jedno, kdo jej dodává).
(pokračování příště)
Jedním z konceptů, na které se tento produkt velmi dobře hodí, jsou tzv. kompozitní aplikace (viz. např. definice na Wikipedii). O co jde? Zejména ve větších organizacích platí, že uživatelé přistupují v rámci svých pracovních povinností ke mnoha systémům. Zpravidla však ne všichni ke všem. Navíc, zde jako nikde jinde v IT může platit, že hodnota celku je výrazně větší než součet jednotlivých komponent.
Samozřejmě, to už tu jednou bylo - a říkalo se tomu Enterprise Resource Planning (ERP), což je termín, který se zdá v současnosti spíše na ústupu ze slávy. Proč?
V jednom speciálním Zverimexu prodávali opice. Opice byly poměrně drahé a tak to jednomu zákazníkovi nedalo a zeptal se, proč jedna opice stojí celých 5000 dolarů. "No tahle umí programovat v jazyce C," dostalo se mu odpovědi od prodavače. "A co umí tahle za 10000?" nedal se odradit zákazník. "No ta umí ještě C++." "A co tahle za 50000?" ptal se s úžasem zákazník. "No, to nevíme, ale říká, že je to konzultant na SAP."
Pokud se to někoho dotýká, nechť si klidně dosadí Oracle EBS či Siebel. V době, kdy jsem vtip poprvé viděl, jsem byl zaměstnán ve Walldorfu, tak mám na tuto verzi morální právo.
Kromě ceny však mají ERP systémy ještě několik dalších problémů, které by se daly shrnout pod termín nedostatek agility, tj. neschopnost dostatečně reagovat na měnící se podmínky či požadavky zákazníků, neschopnost integrace s okolím, pokud někdo jiný nabízí něco zajímavého a pak vysoké nároky na pracovníky obsluhující řešení díky značnému využití proprietárních technologií či know-how.
Jakkoli jistě ani v Oracle není vše ideální, přeci jen byl Larry Ellison jedním z prvních pionýrů, který nastínil nový trend (viz např. Fusion Application).
Kompozitní aplikace stojí na třech pilířích:
- znovupoužitelnost služeb a zdrojů
- standardizace
- de-coupling (což by šlo přeložit jako "rozlámání na menší kousky")
Pokud jde o standardizaci, to je velmi vstřícný krok směrem k zákazníkům - máte-li již nějaké řešení, které podporuje standardy, nebo zdá-li se vám v nějaké oblasti jiné řešení lákavější, budeme vás rádi podporovat tam, kde si nás vyberete. Pod standardizaci patří hesla jako XML, XSLT, web services, SOAP, UDDI, BPEL, či BPMN, tedy něco, co Oracle podporuje, ale zdaleka nekontroluje.
A de-coupling? Některé v současnosti velmi úspěšné produkty (např. Oracle Business Intelligence SE1 či EE) vznikly odštěpením (zde od balíku Siebel). Ještě zajímavější je tento koncept však z pohledu samotných aplikací, které jsou psány modulárně (např. správa uživatelských účtů se bere skutečně jako nezavislý modul, takže je v zásadě jedno, kdo jej dodává).
(pokračování příště)
Subscribe to:
Posts (Atom)
