návrh rozhraní a komponent

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é