DP:xlastov1

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

Zadání

Cílem práce je podat ucelený náhled na návrhové vzory v servisně orientovaných architekturách. Součástí práce bude i praktická implementace vzorů v ukázkové aplikaci namodelované pomocí UML 2.0.

Pojmy

SOA

Service-Oriented Architecture (Servisně orientovaná architektura)

SOA je koncept používaný k modelování informačních systémů. Vyvinula se postupem času jako odpověď na stále vzrůstající požadavky na podnikové informační systémy. Důraz je kladen především na maximální flexibilitu, schopnost reagovat na změny co nejrychleji a nejefektivněji a přitom udržet co nejnižší výdaje.

SOA je kompozitní architektura, která v sobě soustřeďuje to nejlepší z předchozích kompozitních modelů návrhu aplikací. Modeluje systém jako soubor komponent poskytujících služby, kde službou míníme nezávislou, dobře nadefinovanou a zapouzdřenou funkcionalitu.

SOA není konkrétním produktem ani standardem, ale široce akceptovaným přístupem pro analýzu, vývoj, integraci a provoz informačních systémů. Vhodnou implementací lze dosáhnout následujících cílů:

  • snížit náklady na vývoj a integraci aplikací
  • zefektivnit vývoj a integraci aplikací
  • zhodnotit původní (legacy) aplikace
  • zjednodušit správu a řízení informačních systémů
  • rychle reagovat na změny
  • podnikat v reálném čase

Principy architektury SOA vycházejí z předchozích distribuovaných architektur CORBA, DCOM a webových služeb. Současná SOA stojí na těchto základech:

  • služby jsou volně vázané
  • služby mají hrubozrnné API
  • komunikace mezi službami je asynchronní
  • důsledně se využívají oborové standardy
  • služby jsou znovupoužitelné (v co největší rozumné míře)
  • existuje datové úložiště pro metadata služeb

V současné době se nejvíce rozšířily dvě dominantní technologie, které můžeme považovat za implementaci SOA: webové služby (Web Services) a ESB (viz dále).

SCA

Service Component Architecture (Servisně komponentová architektura)

SCA je množina specifikací, které popisují model pro vývoj aplikací a systémů na základě servisně orientované architektury. SCA rozšiřuje a doplňuje předchozí přístupy k implementaci služeb a staví na otevřených standardech jako jsou webové služby.

SCA je založena na myšlence, že každá podniková funkce je k dispozici jako sada služeb, které společně poskytují řešení sloužící specifickým potřebám podniku. Kompozitní aplikace vycházející ze standardu SCA mohou obsahovat nové služby vytvořené speciálně pro aplikaci stejně jako opětovně použité podnikové funkce z již existujících systémů a aplikací. SCA poskytuje model pro sestavení služeb i pro vytvoření servisních komponent, včetně znovupoužití funkcí existujících aplikací uvnitř SCA komponent.

SCA zahrnuje široké spektrum technologií, mezi nimiž nechybí různé programovací jazyky ani prostředí a rámce, které jsou těmito jazyky běžně používané. Aplikace navržená podle specifikace SCA by měla splňovat následující vlastnosti:

  • měla by oddělovat detaily implementace a návrhu od vlastností infrastruktury
  • měla by být schopna pracovat s velkým množstvím programovacích jazyků včetně C++, Java, COBOL, PHP, XML, BPEL a XSLT
  • je nutné, aby si poradila s různými modely systémů pro zasílaní zpráv
  • vlastnosti infrastruktury jako bezpečnost, řízení transakcí a spolehlivé zasílání zpráv by měly být aplikovány s pomocí metadat
  • data by měla být reprezentována jako SDO (viz níže)
  • komponenty SCA by měly být znovupoužitelné
  • lokální volání služeb by mělo být pevněji vázané, aby se redukovaly režijní náklady

SDO

Service Data Objects

SDO je technologie umožňující uniformní přístup k heterogenním datům. SDO je klíčovou částí servisně komponentové architektury.

SDO jsou navrženy ke zjednodušení a unifikování způsobu zpracování dat v aplikacích. Jejich používáním mohou aplikační programátoři snadno přistupovat jednotným způsobem k různým datovým zdrojům jako jsou relační databáze, soubory XML, webové služby nebo podnikové informační systémy.

Návrh (zjednodušeně): SDO užívají jazykově nezávislé datové struktury, které ulehčují komunikaci mezi různými entitami poskytujícími služby. Používají stromové struktury s kořenovým uzlem a algoritmy procházení stromu pro navigaci mezi elementy. Objekty mohou být statické nebo dynamické.

JBI

Java Business Integration

JBI je specifikace definující přístup k implementaci servisně orientované architektury. JBI je vyvíjená pod JCP (Java Community Process), což je sdružení organizací podílejících se na definování vlastností budoucích verzí produktů na platformě Java.

JBI je budována na modelu webových služeb a poskytuje zásuvnou architekturu pro správu komponent, které produkují a konzumují služby. O správu komponent se stará JBI kontejner. Existují dva způsoby, jak může služba s kontejnerem komunikovat:

  • připojí se pomocí vazebních komponent (binding components, BC), které poskytují rozhraní mezi JBI kontejnerem a okolím
  • služba je integrovaná v kontejneru jako service engine (SE) - funkcionalita je specifikována pomocí Web Services Description Language (WSDL)

Zprávy mezi službami se posílají pomocí centrálního doručovacího mechanismu - normalized message router (NMR). Tento směrovač doručuje normalizované zprávy podle jednoho ze čtyř vzorů pro výměnu zpráv (Message Exchange Pattern, MEP):

  1. In-Only - Standardní přenos zpráv mezi dvěma klienty, kde producent posílá zprávu konzumentovi a ten posílá pouze oznámení stavu.
  2. Robust In-Only - Vzor používaný pro zaručený přenos zpráv mezi dvěma klienty.
  3. In-Out - Standardní dvoucestný přenos zpráv mezi dvěma klienty. Producent zasílá zprávu konzumentovi, který odpovídá další zprávou nebo chybovým hlášením. Producent uzavírá komunikaci stavovým oznámením.
  4. Optional In-Out - Jedná se o dvoucestný přenos zprávy s volitelnou odpovědí.

Rozšíření Java Management Extensions (JMX) se stará o hladký průběh instalace, nasazení a monitorování komponent BC a SE. JBI zajišťuje přenositelnost komponent a jejich snadné použití bez modifikací s jinou implementací JBI díky standardizovanému ukládání komponent do balíků. Kromě toho JBI definuje standardy balení také pro kompozitní aplikace, tedy aplikace složené z producentů a konzumentů služeb. Skupiny komponent jsou shromážděny ve společné jednotce a popsány metadaty - to zajišťuje přenositelnost a snadné nasazení.

Některé implementace JBI:

  • Open-ESB
  • ObjectWeb Petals
  • Apache ServiceMix
  • Bostech Chainbuilder ESB
  • Mule

ESB

Enterprise Service Bus (Podniková sběrnice služeb)

ESB je softwarová architektura umožňující integraci služeb při implementaci servisně orientované architektury v podnikovém prostředí. S pomocí ESB lze služby a data snadno synchronizovat a monitorovat probíhající procesy.

ESB pracuje na principu datové sběrnice, která se stará o doručení zpráv, přičemž využívá mnoha standardů jako SOAP, HTTP nebo JMS (Java Messaging Service). Posílané zprávy většinou využívají formát XML, ale ESB podporuje i jiné modely zpráv. ESB je platformově nezávislá a umožňuje používání webových služeb v koordinaci s ostatními integračními technologiemi a principy servisně orientované architektury.

ESB je zaměřena mimo jiné na podporu synchronních a asynchronních transportních protokolů, směrování, datovou transformaci a překlad protokolů, garantované doručení zpráv, bezpečnost, monitorování, audit, logování a měření.

Výhody:

  • rychlejší a levnější přizpůsobení stávajících systémů
  • vyšší flexibilita - snadnější reakce na změnu požadavků
  • využívání standardů
  • široké spektrum možného uplatnění
  • více konfiguračního a méně integračního kódování
  • žádný centrální řídící systém ani zprostředkovatel

Možné nevýhody:

  • obvykle vyžaduje užití Enterprise Message Model
  • bez dopředného plánování se verzování zpráv mezi systémy může stát pevně vázaným místo zamýšleného volně vázaného
  • závislé na prodejci, k provozu vyžaduje více hardwaru
  • vyžaduje nové schopnosti ke konfiguraci
  • aby mohlo dojít k efektivní implementaci, je nutná mít dobře definovanou podnikovou strategii a vyzrálé IT vedení

Návrhové vzory (Design Patterns)

Návrhové vzory řeší určité často se opakující problémy, které se vyskytují při návrhu softwarových systémů. Návrhové vzory jsou nezávislé na programovacím jazyku. Jejich používáním lze docílit zeefektivnění vývoje, údržby i čitelnosti kódu. Každý návrhový vzor řeší jeden daný problém. Vzory můžeme dále rozdělit do skupin podle typu řešeného problému.

Vzory pro tvorbu objektů

Řeší problémy inicializace a vytváření tříd a objektů.

Zástupci:

  • Abstract Factory
  • Builder
  • Factory Method
  • Prototype
  • Singleton

Vzory pro struktury

Zabývají se skládáním objektů a způsoby jak dosáhnout složením nové funkcionality.

Zástupci:

  • Adapter
  • Bridge
  • Composite
  • Decorator
  • Facade
  • Flyweight
  • Proxy

Vzory řešící chování

Tyto vzory řeší spolupráci a komunikaci mezi objekty.

Zástupci:

  • Chain of Responsibility
  • Command
  • Interpreter
  • Iterator
  • Mediator
  • Memento
  • Observer
  • State
  • Strategy
  • Template Method
  • Visitor