DP/xschrein: Porovnání verzí

Z FI WIKI
Přejít na: navigace, hledání
 
(Cíl práce)
Řádka 3: Řádka 3:
 
Na bázi současných enterprise trendů poskytnout technické zázemí pro   
 
Na bázi současných enterprise trendů poskytnout technické zázemí pro   
 
[http://kore.fi.muni.cz:5080/wiki/index.php/DP:xsmid7 Waste Site Energy Management Calculator].
 
[http://kore.fi.muni.cz:5080/wiki/index.php/DP:xsmid7 Waste Site Energy Management Calculator].
 +
 +
== Přehled zvažovaných entreprise technologií ==
 +
 +
=== SOA (''Service Oriented Architecture'') ===
 +
SOA je softwarová architektura postavená na využití služeb jako elementárních funkčích komponent. Služby navíc sami popisují svoji funkcionalitu (''self-describing''), jsou tak samostatnými a navzájem nezávislými elementy. Komunikují s okolím prostřednictvím rozhraní ve standardizovaném formátu. Používají při tom běžné protokoly, z pohledu klienta je tak používání služeb naprosto nezávislé na platformě či programovacím jazyku.
 +
 +
Komunikační vrstva SOA se obecně nazývá middleware.
 +
 +
Výhody použití SOA:
 +
* robustnost (výpadek jedné služby neovlivní zbytek systému)
 +
* udržovatelnost (konkrétní implementace je pro klienta nepodstatná a může být transparentně nahrazena jinou)
 +
* platformní nezávislost (služby poskytují funkcionalitu definovanou rozhraním nehledě na platformě, na níž běží)
 +
* škálovatelnost (možnost distribuovat služby)
 +
 +
Odkazy:
 +
* http://www.soamodeling.org/ - Rozcestník, který má pomoci v orientaci ve světě SOA. Web není ještě úplně hotov. V každém případě je zde k dispozici:
 +
** referenční model architektury SOA - vyvinutý OASIS, k dispozici samotný dokument, WIKI, UML model
 +
** katalog standardů, návrhových vzorů, protokolů, technologií, produktů
 +
 +
 +
=== ESB (''Enterprise Service Bus'') ===
 +
Ne konkrétní software nebo standard, ale komunikační vrstva v architektuře SOA (s o něco méně obecnýn významem než middleware).
 +
 +
Zajišťuje komunikaci mezi službami v SOA, umožňuje jim pracovat nezávisle na konkrétních komunikačních metodách a protokolech. V ideálním případě vytváří ESB prostředí, ve kterém je používání SOA transparentní (komunikace např. realizována jako běžné "lokální" volání metod nějakého rozhraní).
 +
 +
V nejjednodušším případě se ESB stará jen o směrování požadavků na služby (tedy např. HTTP požadavek v Internetu).
 +
 +
Sofistikovanější je potom např. využití webových služeb, s rozhraním popsaným pomocí jazyka WSDL (''Web Services Definition Language''), a protokolu SOAP (''Simple Object Access Protocol'') nad HTTP.
 +
 +
Lze využít i komplexnějších ESB, jako třeba JBI nebo SCA.
 +
 +
Zdroje:
 +
* http://www-128.ibm.com/developerworks/opensource/library/ws-esbscen - Popis ESB a její role v SOA. Mimo jiné obsahuje výčet schopností současných implementací ESB přehledně rozdělený do kategorií.
 +
 +
 +
=== JBI (Java Bussines Integration) ===
 +
* komplexní řešení ESB
 +
* definivána specifikací JSR 208 (http://jcp.org/en/jsr/detail?id=208) v rámci Java Community Process
 +
* standard pro integraci systémů v rámci SOA
 +
* reakce na mnoho komerčních/uzavřených middlewarů a jejich komplikovanou vzájemnou integraci
 +
* standardní infrastruktura, do ní jsou proprietání (uzavřené, nestandardní) systémy "připojeny" pomocí plug-inů
 +
* hodně informací bude doplněno v brzké době
 +
 +
Konkrétní implementace:
 +
* Petals
 +
* Open ESB (implementace ESB od Sunu založená na JBI)
 +
 +
Zdroje:
 +
* [http://jcp.org/en/jsr/detail?id=208 JSR# 208] - definice JBI od Java Community Proccess
 +
* [http://forum.java.sun.com/forum.jspa?forumID=512 Java Technology Forums - JBI] - "oficiální" JBI fórum
 +
* [http://www.artima.com/lejava/articles/jbi.html Service-Oriented Java Business Integration] - rozhovor s navrhářem JBI (Ron Ten-Hove)
 +
* [http://blogs.sun.com/roller/page/rtenhove Ron Ten-Hove's Weblog] - bolg návrháře JBI (Ron Ten-Hove)
 +
* [https://open-esb.dev.java.net/public/pdf/JBI-Components-Theory.pdf JBI components theory] - popis JBI komponent a vzorů výměny zpráv v JBI (''Message Exchange Patterns'')
 +
* [https://open-esb.dev.java.net/public/whitepapers/ImplementingSOA.pdf Implementing SOA with J2EE 5] - detailnější popis JBI a konkrétních implementací vybraných komponent)
 +
* [http://www.javaworld.com/javaworld/jw-07-2006/jw-0717-jbi.html Use JBI components for integration] - výborný článek, schematický popis komunikace JBI komponent vzhledem k jednotlivým komunikačním vrstvá, tutoriál pro implementaci komponenty
 +
* [http://java.sun.com/integration/reference/techart/jbi/ Developing a Service Engine Component] - celkem přehledný step-by-step tutoriál, bohužel nedotažený a uspěchaný závěr
 +
 +
 +
 +
=== SCA (''Service Components Architecture'') ===
 +
* způsob řešení middlewaru
 +
* definováno [http://www.osoa.org/ OSOA Collaboration] - [http://www.osoa.org/display/Main/Service+Component+Architecture+Specifications OSOA - Service Component Architecture Specifications]
 +
* vývoj systému ve dvou krocích:
 +
*# implementace komponent
 +
*# sestavení (assembly) systému kombinací příslušně nakonfigurovaných komponent
 +
* komponenty úplně odstíněné od "distributivnosti", pouze aplikační logika.
 +
* komunikační partneři = rozhraní
 +
* konfigurace komunikačních partnerů, komunikačnách metod (webové služby, messages, lokální objekt žijící ve stejné JVM) a nastavení deklarativně (v XML)
 +
* detailněji:
 +
** služba (''service'') - entita poskytující operace definované rozhraním
 +
** rozhraní (''interface'') - rozhraní definující operace služby
 +
** reference - při implementaci komponenty lze využít referenci jako handle (ručku:-) na jinou službu
 +
** vlastnosti (''properties'') - vlastnosti služby, které lze specifikovat až ve fázi konfigurace a sestavování
 +
** komponenta (''component'') - komponenta vzniká ze služby (service) zadefinováním konkrétních uzlů pro všechny reference a nastavením všech vlastností služby (properties)
 +
** modul (''module'') - funkční element, který vznikne sestavením několika spolupracujících komponent, zadefinováním služeb dostupných zvenku (''Entry points'') a závislostí modulu (''External services''). Modul potom funguje jako černá skříňka komunikující pouze přes tyto body.
 +
** sestavování komponent (assembly) - může být realizováno na dvou úrovních:
 +
**# sestavování komponent do modulů
 +
**# sestavování modulů do větších funkčních celků (subsystémů)
 +
** vazby (''bindings'') - vazby, definující příslušný přístupový mechanismus (typicky k modulu) pro přístupu "z venku", tedy z prostředí mimo SCA kontejner. Př: modul poskytuje jeden ze svých Entry pointů jako webovou službu
 +
 +
Implementace:
 +
* Apache Tuscany
 +
 +
Výhody:
 +
* výrazná znovupoužitelnost, komponenty jen aplikační logika
 +
* přímočaré odstínění implementátora aplikační logiky a sestavovatele aplikace (komponent)
 +
 +
 +
=== BPEL (''Bussiness Process Execution Language'') ===
 +
Jazyk vyšší úrovně pro formální popis bussines procesů. Je prostředkem pro programování ve velkém - nepopisuje konkrétní algoritmy, ale spíš interakci mezi samostatně běžícími procesy, službami.
 +
 +
Spuštění BPEL skriptu zavádí tzv. abstraktní proces - ten komunikuje s okolními službami (procesy), ke komunikaci se využívá webových služeb.
 +
 +
BPEL skripty jsou serializovány (zapsány) v XML souborech a interpretovány některým z BPEL enginů, viz např http://en.wikipedia.org/wiki/List_of_BPEL_engines.
 +
 +
 +
 +
=== Software ===
 +
 +
==== Open-ESB ====
 +
* https://open-esb.dev.java.net/
 +
* implementace ESB postavená na JBI
 +
* "nadstandardní vlastnosti (oproti [http://jcp.org/en/jsr/detail?id=208 JSR 208]):
 +
** Centralizovaná správa: Standard JSR 208 (tedy definici JBI) definuje JBI kontejner jen v rámci jedné JVM. Open-ESB rozšiřuje tento koncept, více instancí Open-ESB lze sjednotit do tzv. metakontejneru (''meta-container''). Ten se potom tváří transparrentně jako jeden monolitický celek. Výhoda oproti explicitnímu propojení více fyzických JBI kontejnerů (přes vnější rozhraní, tedy spojením Binding component <-> Binding component) je přinejmenším v možnosti centralizované správy a administrace (CAS - ''Central Administration Server'').
 +
 +
==== Celtix ====
 +
* http://celtix.objectweb.org
 +
* mladá open-source implementace ESB
 +
* částečná možnost spolupráce s JBI
 +
* umožňuje využívat některých nadstandardních vlastností, jako třeba callbacků
 +
* s čím Celtix pracuje:
 +
** Bindings (serializují data do formátu vhodného pro přenos):
 +
*** SOAP
 +
*** XML (vlastní well-formed XML formát)
 +
** Transports (protokoly používané pro komunikaci):
 +
*** JMS
 +
*** HTTP
 +
 +
 +
==== Petals ====
 +
* http://petals.objectweb.org/
 +
* JBI kontejner
 +
* orientován na distributivitu (podobně jako Open-ESB) a clusterování.
 +
 +
==== Mule ====
 +
* http://mule.codehaus.org/
 +
* ESB kontejner
 +
* přístup velice podobný SCA, Mule se však k SCA nijak nehlásí
 +
* explicitní podpora pro integraci do JBI prostředí
 +
* komponenty (nazývané UMO - ''Universal Message Object'') jsou obyčejné javové objekty (POJO - ''Plain Old Java Object'') s vlastnostmi JavaBeans. Neobsahují žádný kód specifický pro Mule, řeší pouze aplikační logiku.
 +
* nad UMO komponentami je potom deklarativně (serializace do v XML) zavedena síť tzv. ''endpointů'', které definují jak spolu komponenty mají komunikovat (jedna komponenta může být nastavena více způsoby a vystupovat tak ve více rolích).
 +
* Mule pro ně vytváří kontejner, běhové prostředí. Zajišťuje management komponent i celého kontejneru, směrování a doručování zpráv.
 +
* Více fyzických kontejnerů lze sjednotit do jednoho virtuálního a to transparentně vzhledem ke komponentám.
 +
* lze spouštět samostatně, nebo v aplikačním serveru (Geronimo, JBoss, Weblogic)
 +
* výhody
 +
** dobrá dokumentace
 +
** dobrá integrace s frameworky webových služeb:
 +
*** [http://ws.apache.org/axis Apache Axis]
 +
*** [http://www1.webmethods.com/docs/glue/guide/index.html Glue]
 +
*** [http://xfire.codehaus.org/ XFire]
 +
* nevýhody
 +
** negarantuje spolupráci s aplikačními servery Sunu ([http://www.sun.com/software/products/appsrvr/index.xml Sun Java System Application Server], projekt [https://glassfish.dev.java.net/ GlassFish])
 +
 +
==== Apache Tuscany ====
 +
* implementace SCA
 +
* mladý projekt, v inkubátoru Apache
 +
 +
 +
==== Apache Axis ====
 +
* framework na webové služby
 +
* objekt (Java Bean) + jednoduchý XML popis
 +
* Axis zajistí "všechno kolem"

Verze z 8. 8. 2006, 01:25

Cíl práce

Na bázi současných enterprise trendů poskytnout technické zázemí pro Waste Site Energy Management Calculator.

Přehled zvažovaných entreprise technologií

SOA (Service Oriented Architecture)

SOA je softwarová architektura postavená na využití služeb jako elementárních funkčích komponent. Služby navíc sami popisují svoji funkcionalitu (self-describing), jsou tak samostatnými a navzájem nezávislými elementy. Komunikují s okolím prostřednictvím rozhraní ve standardizovaném formátu. Používají při tom běžné protokoly, z pohledu klienta je tak používání služeb naprosto nezávislé na platformě či programovacím jazyku.

Komunikační vrstva SOA se obecně nazývá middleware.

Výhody použití SOA:

  • robustnost (výpadek jedné služby neovlivní zbytek systému)
  • udržovatelnost (konkrétní implementace je pro klienta nepodstatná a může být transparentně nahrazena jinou)
  • platformní nezávislost (služby poskytují funkcionalitu definovanou rozhraním nehledě na platformě, na níž běží)
  • škálovatelnost (možnost distribuovat služby)

Odkazy:

  • http://www.soamodeling.org/ - Rozcestník, který má pomoci v orientaci ve světě SOA. Web není ještě úplně hotov. V každém případě je zde k dispozici:
    • referenční model architektury SOA - vyvinutý OASIS, k dispozici samotný dokument, WIKI, UML model
    • katalog standardů, návrhových vzorů, protokolů, technologií, produktů


ESB (Enterprise Service Bus)

Ne konkrétní software nebo standard, ale komunikační vrstva v architektuře SOA (s o něco méně obecnýn významem než middleware).

Zajišťuje komunikaci mezi službami v SOA, umožňuje jim pracovat nezávisle na konkrétních komunikačních metodách a protokolech. V ideálním případě vytváří ESB prostředí, ve kterém je používání SOA transparentní (komunikace např. realizována jako běžné "lokální" volání metod nějakého rozhraní).

V nejjednodušším případě se ESB stará jen o směrování požadavků na služby (tedy např. HTTP požadavek v Internetu).

Sofistikovanější je potom např. využití webových služeb, s rozhraním popsaným pomocí jazyka WSDL (Web Services Definition Language), a protokolu SOAP (Simple Object Access Protocol) nad HTTP.

Lze využít i komplexnějších ESB, jako třeba JBI nebo SCA.

Zdroje:


JBI (Java Bussines Integration)

  • komplexní řešení ESB
  • definivána specifikací JSR 208 (http://jcp.org/en/jsr/detail?id=208) v rámci Java Community Process
  • standard pro integraci systémů v rámci SOA
  • reakce na mnoho komerčních/uzavřených middlewarů a jejich komplikovanou vzájemnou integraci
  • standardní infrastruktura, do ní jsou proprietání (uzavřené, nestandardní) systémy "připojeny" pomocí plug-inů
  • hodně informací bude doplněno v brzké době

Konkrétní implementace:

  • Petals
  • Open ESB (implementace ESB od Sunu založená na JBI)

Zdroje:


SCA (Service Components Architecture)

  • způsob řešení middlewaru
  • definováno OSOA Collaboration - OSOA - Service Component Architecture Specifications
  • vývoj systému ve dvou krocích:
    1. implementace komponent
    2. sestavení (assembly) systému kombinací příslušně nakonfigurovaných komponent
  • komponenty úplně odstíněné od "distributivnosti", pouze aplikační logika.
  • komunikační partneři = rozhraní
  • konfigurace komunikačních partnerů, komunikačnách metod (webové služby, messages, lokální objekt žijící ve stejné JVM) a nastavení deklarativně (v XML)
  • detailněji:
    • služba (service) - entita poskytující operace definované rozhraním
    • rozhraní (interface) - rozhraní definující operace služby
    • reference - při implementaci komponenty lze využít referenci jako handle (ručku:-) na jinou službu
    • vlastnosti (properties) - vlastnosti služby, které lze specifikovat až ve fázi konfigurace a sestavování
    • komponenta (component) - komponenta vzniká ze služby (service) zadefinováním konkrétních uzlů pro všechny reference a nastavením všech vlastností služby (properties)
    • modul (module) - funkční element, který vznikne sestavením několika spolupracujících komponent, zadefinováním služeb dostupných zvenku (Entry points) a závislostí modulu (External services). Modul potom funguje jako černá skříňka komunikující pouze přes tyto body.
    • sestavování komponent (assembly) - může být realizováno na dvou úrovních:
      1. sestavování komponent do modulů
      2. sestavování modulů do větších funkčních celků (subsystémů)
    • vazby (bindings) - vazby, definující příslušný přístupový mechanismus (typicky k modulu) pro přístupu "z venku", tedy z prostředí mimo SCA kontejner. Př: modul poskytuje jeden ze svých Entry pointů jako webovou službu

Implementace:

  • Apache Tuscany

Výhody:

  • výrazná znovupoužitelnost, komponenty jen aplikační logika
  • přímočaré odstínění implementátora aplikační logiky a sestavovatele aplikace (komponent)


BPEL (Bussiness Process Execution Language)

Jazyk vyšší úrovně pro formální popis bussines procesů. Je prostředkem pro programování ve velkém - nepopisuje konkrétní algoritmy, ale spíš interakci mezi samostatně běžícími procesy, službami.

Spuštění BPEL skriptu zavádí tzv. abstraktní proces - ten komunikuje s okolními službami (procesy), ke komunikaci se využívá webových služeb.

BPEL skripty jsou serializovány (zapsány) v XML souborech a interpretovány některým z BPEL enginů, viz např http://en.wikipedia.org/wiki/List_of_BPEL_engines.


Software

Open-ESB

  • https://open-esb.dev.java.net/
  • implementace ESB postavená na JBI
  • "nadstandardní vlastnosti (oproti JSR 208):
    • Centralizovaná správa: Standard JSR 208 (tedy definici JBI) definuje JBI kontejner jen v rámci jedné JVM. Open-ESB rozšiřuje tento koncept, více instancí Open-ESB lze sjednotit do tzv. metakontejneru (meta-container). Ten se potom tváří transparrentně jako jeden monolitický celek. Výhoda oproti explicitnímu propojení více fyzických JBI kontejnerů (přes vnější rozhraní, tedy spojením Binding component <-> Binding component) je přinejmenším v možnosti centralizované správy a administrace (CAS - Central Administration Server).

Celtix

  • http://celtix.objectweb.org
  • mladá open-source implementace ESB
  • částečná možnost spolupráce s JBI
  • umožňuje využívat některých nadstandardních vlastností, jako třeba callbacků
  • s čím Celtix pracuje:
    • Bindings (serializují data do formátu vhodného pro přenos):
      • SOAP
      • XML (vlastní well-formed XML formát)
    • Transports (protokoly používané pro komunikaci):
      • JMS
      • HTTP


Petals

Mule

  • http://mule.codehaus.org/
  • ESB kontejner
  • přístup velice podobný SCA, Mule se však k SCA nijak nehlásí
  • explicitní podpora pro integraci do JBI prostředí
  • komponenty (nazývané UMO - Universal Message Object) jsou obyčejné javové objekty (POJO - Plain Old Java Object) s vlastnostmi JavaBeans. Neobsahují žádný kód specifický pro Mule, řeší pouze aplikační logiku.
  • nad UMO komponentami je potom deklarativně (serializace do v XML) zavedena síť tzv. endpointů, které definují jak spolu komponenty mají komunikovat (jedna komponenta může být nastavena více způsoby a vystupovat tak ve více rolích).
  • Mule pro ně vytváří kontejner, běhové prostředí. Zajišťuje management komponent i celého kontejneru, směrování a doručování zpráv.
  • Více fyzických kontejnerů lze sjednotit do jednoho virtuálního a to transparentně vzhledem ke komponentám.
  • lze spouštět samostatně, nebo v aplikačním serveru (Geronimo, JBoss, Weblogic)
  • výhody
  • nevýhody

Apache Tuscany

  • implementace SCA
  • mladý projekt, v inkubátoru Apache


Apache Axis

  • framework na webové služby
  • objekt (Java Bean) + jednoduchý XML popis
  • Axis zajistí "všechno kolem"