Komponentový návrh SW

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é