DP/xschrein

Z FI WIKI
Přejít na: navigace, hledání

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 - SOA systém je tedy kolekce služeb, které spolu navzájem komunikují. Služby navíc sami popisují svoji funkcionalitu (self-describing), jsou tak samostatnými elementy. Komunikují s okolím prostřednictvím rozhraní ve standardizovaném formátu. Služba, reprezentovaná rozhraním, je pak k dispozici svému okolí - tedy ostatním službám, které pak v roli konzumenta (service consumer) k takto nabídnuté službě přistupují. 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.

Výrazným rysem SOA pak je, že služba nemusí vědět prakticky nic o svém konzumentovi - to umožnuje vytvářet velice volně vázané a flexibilní systémy.

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.
  • SCA je modelem nezávislým na implementačním jazyku. Neumožňuje ovšem jednoduše spolupracovat např. dvěma komponentám napsaným v různých jazycích, nabízí jen koncept, který může být realizován v libovolném jazyku - to příliš velký trhák není..
  • komponenta nabízí službu definované nějakým rozhraním - rozhraním může být téměř cokoliv: javové rozhraní s příslušnými anotacemi, WSDL, kód v C++ opetřený popisnými metadaty, ... Podpora pro příslušné rozhraní je jednou z možností rozšíření funkcionality SCA.
  • 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)

Nevýhody:

  • slabý koncepty podpory více program. jazyků

Pozn.: vynikající kritika SCA - What's wrong with SCA?

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"