Komponentový návrh SW

Komponentový návrh SW

• Komponenty jsou kompletně specifikované pomocí interface

• Jejich funkčnost je nezávislá na programovacím jazyku a mohou být integrované do toho samého systému

• Poskytují velké množství standartních služeb, tak aby další vývoj byl co nejvíc minimalizovaný

• Mnoho standartů podporující komponenty: EJB, COM, .NET, CORBA CCM

• V praxi těžko proveditelné aby např. .NET a J2EE spolupracovali dohromady

• => proto komponenta jako služba (SOA)

Charakteristiky komponent

• Standardized - musejí dodržovat standart (metadata, interfaces, dokumentace, nasazení)

• Independent - mělo by být možné sloučit a nasadit komponentu bez nutnosti dalších komponent

• Composable - interakce přes interface, externí přístup k informacím o sobě samém

• Deployable - operuje jako samostatná entita • Documented – musí být plně dokumentovaná

Komponenta jako service povider

• Komponenta je nezávislá funkční entita, nemusí být kompilovaná před tím, než je použitá

• Všechny služby komponenty jsou nabízené prostřednictvím interface a všechny interakce jsou prováděné pomocí interface

• Interface je realizované pomocí parametrizovaných operací a vnitřní stav není nikdy dostupný

Charakteristiky komponent

Komponenty mají 2 interfacy: • Provides - služby nabízené komponentou (API) • Requires – služby, které musí být poskytnuté jinými

komponentami • Komponenty jako služba jsou samostatné entity ->

nemají required interface

Modely komponent

• Komponentový model je definice standartů pro implementaci komponenty, dokumentaci a nasazení

• INTERFACES - Model specifikuje jak mají být definované interfacy a elementy, které mají být součásti definice interface

• USAGE – vzhledem k tomu, že komponenty budou distribuované a přístup vzdálený – musejí mít unikátní název, definice poskytovaných služeb

• DEPLOYMENT – specifikace jak mají být komponenty nasazené tak, aby byly nezávislé entity

Middleware

• Model komponent je základem pro middleware, který dodává veškerý support pro běh. Implementace komponentového modelu poskytuje: – Služby dané platformy, které umožňují komponentám

komunikovat

– Podpůrné služby využíváné různými komponentami

• Komponenty jsou nasazované v tzv.containeru – to je množina interface

CBSE procesy

Hlavní rozdělení:

• Vývoj pro znovupoužití (for reuse) – vývoj komponent nebo služeb, které budou znovupoužité jinými systémy

• Vývoj s znovupoužitím (with reuse) – vývoj nových aplikací s využitím existujících komponent a služeb

CBSE pro znovu-použití

• Vývoj komponent • Komponenty pro specifické prostředí musejí

být většinou zoobecněné, aby mohli být znovu-použíté

• Komponenty jsou znovu-použitelné většinou tehdy, když jsou asociované s nějakým stabilním business objektem

• Čím více je interface obecné, tím více se může znovupoužít, ale tím hůř je také použitelné

Změny pro znovupoužití

• Odstranit metody, které se příliš týkají dané aplikace

• Změnit názvy a udělat je více obecné • Přidat metody, které rozšíří pokrytí jednotlivých

použití • Udělat konzistentní řešení vyjímek • Přidat konfigurační rozhranní pro nastavení

komponenty • Integrovat vyžadované komponenty tak, aby se

zredukovali závislosti

Řešení výjimek

• Komponenta by neměla zpracovávat výjimky sama, protože každá aplikace může mít jiné požadavky na jejich řešení

• Raději definovat jaké vyjímky mohou nastat a ty publikovat

• V praxi je potřeba najít rozumný kompromis, aby interface nebylo moc komplikované

Komponenty z původních systemů

• Existující systémy, které řeší nějaký problém nemusejí být nutně přepracovány, ale pokud dobře fungují mohou být využity jako komponenta

• Využití wraperu a implementování provides a requires interface

• => ušetření nákladů

Znovu-použitelné komponenty

• Vývoj -> dražší • Mohou být větší, než specifická komponenta a také mohou

spotřebovat více výpočetního času

Správa komponent: • Předem je potřeba se rozhodnou, zda komponenta má být

ve formě služby nebo raději jako „balíček“ • Udržovat informace o použití komponenty a jejích verzích • Certifikace komponent (někdo jiný, než vývojář ověří

kvalitu)

CBSE s znovu-použitím

• Snaží se nalézt a integrovat znovupoužitelné komponenty • Většinou hlédá kompromis mezi ideálním splněním

požadavků a službami nabízenými komponentami

Kroky: • Obecné požadavky • Hledání komponent a úprava požadavků podle dostupné

funkcionality • Znovu hledání, jestli neexistují lepší komponenty splňující

upravené požadavky • • „Spojování“ komponent tak aby vytvořili požadovaný

systém

Identifikace vhodných komponent

• Důvěryhodnost – důvěryhodný dodavatel

• Požadavky

• Validace – specifikace komponenty nemusí být dostatečná

– Nechtěná funkcionalita

– Proto je potřeba vytvořit několik test case pro danou komponentu

Typy kompozice komponent

• Sekvenční – komponenty pracují sekvenčeně – využíváme provides interface každé komponenty

• Hierarchická – jedna komponenta volá služby jiné – využíváme requires interface

• Doplňková – interfacy několika komponent jsou spojeny a je vytvořená nová komponenta – využíváme provides i requires

Nekompatibilní interface

• Parametry - operace mají stejný název, ale jiné parametry

• Operace – názvy operací v propojovaných interface jsou různé

• Nekompletnost operací – provides interface jedné komponenty je podmnožinou requires interface jiné

Problém nekompatibility zkoušíme vyřešit tak, že se

pokusíme sladit jednotlivé interface komponent - adaptér

SOA – Service oriented architecture

Web services: • Poskytovatel web.služby má možnost vyvinout

specializované služby a ty nabízet různým uživatelům a organizacím

• Podstata je v nezávislosti aplikace a web.služby

SOA • Distribuované systémy, kde komponenty jsou samostatné

služby • Služby mohou pracovat na různých platformách u různých

providerů • Pro komunikaci slouží standartní protokoly

SOA – Service oriented architecture

Výhody SOA

• Služby mohou být provozovaní lokálně nebo outsourcované externím providerům

• Služby jsou nezávislé na program.jazyku

• Je možné využít vyvinuté systémy a udělat z nich WS - $$$

• a další …

Důležité standardy SOA

• SOAP (Simple Object Access Protokol) – Standard pro výměnu zpráv, který podporuje komunikaci služeb

• WSDL (Web Service Definition Language) – Standard pro definovaní interface služeb a jejich bindování

• WS-BPEL (WS-Business Process Execution Language) – Standard pro workflow jazyky používaný pro kompozici služeb

WSDL

• Které operace jsou poskytovány, formát jejich zpráv

• Přístup k službě – mapování abstraktního interface na konkrétní protokol

• Kde se služba nachází, URI (Unified resource identifier)

RESTful web services

• Současné standardy pro web.služby jsou kritizované pro tězkopádnost

• • REST (Representational State Transfer) je arch. styl založený na přenosu reprezentace zdrojů ze serveru na klienta

• GET, PUT, POST, DELETE

• Jednoduší než SOAP/WSDL, jediný standard je HTTP

Nalezení kandidáta na WS

• Je služba asociována s jednou logickou entitou, která je používaná ve více business procesech?

• Je úkol v rámci organizace vykonáván více lidmi?

• Je služba nezávislá?

• Udržuje služba svůj stav? Vyžaduje databázi?

• Může být služba využívaná mimo organizaci?

• Mají uživatelé služby různé nefunkční požadavky?

Problémy testování WS

• Externí služby mohou být modifikovány providerem -> nevalidní testy

• Ne-funkční chování služby se může lišit podle zátěže

• Pokud se platí za využití služby – testování může být drahé