SOALIB - SOALIB

tento článek vyžaduje pozornost odborníka na výpočetní techniku. Přidejte prosím důvod nebo a mluvit parametr k této šabloně pro vysvětlení problému s článkem. Výpočet WikiProject může pomoci s náborem odborníka. (Leden 2009)

Knihovna architektury orientovaná na služby (SOALIB) se používá k distribuci opakovaně použitelných architektura orientovaná na služby Software (SOA)^[1][2] podobným způsobem jako jiné výpočty knihovny. SOA se skládá z volně vázané interoperabilní služby, které využívají zprávy založené na obou Simple Object Access Protocol (SOAP) a Převod reprezentativního státu (ZBYTEK). A knihovna ve výpočetní technice je sada kompilovaných modulů, které jsou testovány a připraveny k opětovnému použití. Podobný koncept se používá pro SOA, protože jakákoli technologie použitá k vývoji služby může být také distribuována ve formě knihovny. A Jáva knihovna SOA založená na bázi může být distribuována v Webový archiv (VÁLKA) nebo Enterprise Archive (EAR) formáty souborů. C, C ++, a .SÍŤ aplikace mohou být distribuovány jako a sdílený objekt (v Unix a Linux ), a Knihovna dynamických odkazů (ve Windows) nebo jako spustitelný soubor.

Dějiny

Architektura orientovaná na služby je obvykle vázána na redesign celého softwarového systému a určuje, jak rozložit jednu softwarovou jednotku na volně spojené komponenty, ve kterých každá volně spojená komponenta funguje jako interoperabilní služba. Takový úkol je obrovský a může trvat značně dlouho, zatímco je na atomové úrovni (kde atom je definována jako jedna volně spojená služba, která je samostatná), většina služeb je opakovaně použitelná bez ohledu na aplikaci. Jako příklad lze uvést, že veškerá hmota je postavena z atomů, přesto jsou všechny hmotné věci odlišné. Na atomové úrovni však vypadají jednotně. Podobně může být veškerý software postaven na volně vázaných službách, které slouží jako „atomy“ procesu redesignu. Protože je těžké určit uvolněnou spojku, opak není pravdou. To znamená, že je snazší vybudovat kompletní softwarový systém pomocí dostupných volně vázaných služeb.

Vytvářením knihoven architektury orientovaných na služby, z nichž každá je volně vázanou službou, lze pomocí těchto služeb vyvíjet složité aplikace. Protože nové aplikace závisí na všech volně vázaných službách, pokud se člověk drží volné vazby, konečná aplikace je také volně spojená. I když je pravda, že konečná aplikace závisí na mnoha hierarchických volně vázaných systémech, zůstává volně vázaná, protože celá hierarchie je založena na atomových službách.

Cíle

Budování SOA vyžaduje volné spojení služeb jako výchozí bod. Jsou označovány jako atomový služby. Prvním krokem je určení atomových služeb. Pak vytvořte tyto atomové služby pro opětovné použití. Mohlo by být vytvořeno velké množství takových atomových služeb, na nichž budou postaveny složené služby. Složená služba jsou služby, které jsou postaveny pouze na atomových službách.

Kroky

• Identifikujte, sestavte a otestujte volně spojené atomový služby.
• Identifikujte, sestavte a otestujte volně spojené kompozitní služby, kde každá složená služba je tvořena pouze atomovými službami.
• Vytvářejte integrované služby, kde každá z integrovaných služeb je tvořena složenými a atomovými službami.
• Vybudujte složitý softwarový systém pomocí opětovného použití atomových, kompozitních a integrovaných služeb. Tento složitý systém zůstává volně spojený.

Nezávislost platformy

Úvaha o napříč platformami je důležité. V současné době existuje mnoho způsobů, jak zajistit, aby byla hostitelská platforma služeb nezávislá na platformě. Příkladem jsou stavební služby v Javě, kde JVM je k dispozici pro hostitele, na kterém bude server spuštěn jako služba. Alternativy jsou vytváření aplikací s úplnou shodou s ANSI C / C ++ takže žádná z komponent kódu není závislá na knihovnách třetích stran. To obvykle znamená vytváření aplikací C / C ++ pomocí GNU nástroje a překladače GNU C, protože překladače GNU jsou portovány na většinu operačních systémů a platforem. Další alternativou je použití C # .SÍŤ jako jazyk webové služby, kde Common Language Runtime ^[3] je portován na cílový operační systém a platformu. K dispozici je mnoho dalších možností, ale nejběžnější přístupy k nezávislosti na platformě již byly zmíněny.

Kroky

• Plná nezávislost na platformě v maximální možné míře.
• Automatické testy na každé platformě.

Databáze více dodavatelů

Rozsah knihovny je omezený, pokud nemá podporu pro databáze. Složené a integrační služby by měly být postaveny tak, aby využívaly volně vázané atomové služby, které fungují na databázích. Jakmile je přidána podpora pro přístup k databázi, a metadata vrstva by měla být přidána k mapování různých druhů datových formátů v databázi do jednotné sady datových typů, které budou mít stejný význam pro všechny databáze. Toto je obtížná část, ale v tuto chvíli JDBC,^[4] ODBC, ADO a další standardní databázové ovladače již část úkolu dělají. Každá databáze může ukládat data v různých formátech. Některá data mohou být šifrována, jiná mohou být uložena v malém endianu Endianness, nebo jiní ve velkém endianu atd. Proto musí být data v určitém okamžiku transformována službami a musí být provedena za běhu kvůli měnící se povaze dat. Všechny databáze jsou odlišné, proto ani jedna API může využívat všech funkcí všech databází. Služby by proto měly používat také funkce specifické pro databázi.

Kroky

• Plná podpora pro všechny hlavní databáze - mobilní, PC a serverové.
• Vytvoření vrstvy metadat pro jednotný přístup k datům.
• Veškerý přístup k databázi prostřednictvím knihoven služeb.
• Automatická runtime transformace dat.
• Podpora specifických funkcí interní databáze.

Synchronizace dat

Jakmile jsou podporovány databáze více dodavatelů, lze přidat služby, aby se každá databáze mohla synchronizovat s jakoukoli jinou databází. To bude nyní možné, protože všechna data nyní procházejí datovou vrstvou a data jsou reprezentována v nějaké přechodné formě. Mezilehlá forma může být jakékoli nativní formy a nemusí být založena na standardech. Nativní forma by obvykle měla být přenosná, to znamená, že ji zastupuje XML může být nejlepší přístup. Protože velikosti dat bývají velké, měla by být také přidána detekce přírůstkových změn.

Kroky

• Libovolná synchronizace.
• Změňte zachytávací modul.
• Jednosměrná a obousměrná synchronizace dat.
• Vlastní mapování s referenční integritou.
• Heterogenní synchronizace.

Bezpečnostní

Všechny knihovny musí být zabezpečené. Pokud mají knihovny implementaci SOA jako webové služby, pak by to mělo být WS-Security,^[5] WS-politika^[6] a další soulad s normami typu WS. Pokud je založen na REST nebo jiných protokolech, měl by se řídit příslušnými standardy. Všechny knihovny musí alespoň podporovat SSL.

Kroky

• Podpora všech hlavních bezpečnostních architektur založených na standardech.
• Podpora Secure Socket Layer.
• Možnost šifrovaného úložiště na serveru.

Interoperabilita

Interoperabilita je jedním z nejdůležitějších důvodů, proč je SOA tak důležitá. Knihovna SOA musí také obsahovat požadované API, které lze použít pro rychlý vývoj specifický pro platformu.

Kroky

• Podpora všech hlavních programovacích jazyků: Jáva, Java ME, C, C ++, C # .NET,^[7] VB.NET.,^[8] PHP^[9]
• Dodáváno se všemi potřebnými klientskými API.
• Všechna rozhraní API musí být testována na závazné služby SOA.

Vytváření aplikací atom po atomu

Atomová služba je volně spojená služba, která je nezávislá na jakýchkoli předpokladech, naprosto předvídatelná a nemá žádné další závislosti na službách nebo jiných atomových službách. Jako příklad lze operaci se souborem disku považovat za atomovou službu, ve které jsou jedinými operacemi prováděnými službou operace čtení, zápisu, mazání nebo připojení souborů. Protože jedinou informací, kterou by soubor na disku potřeboval, je úplná cesta k souboru a případně některé přístupové parametry (například uživatelské jméno a heslo), neexistovaly by žádné další závislosti. Pokud je složená služba navržena na základě atomových služeb, je stále volně spojená, ale nikoli atomová služba. Každá integrovaná služba pak může být vytvořena společně, aby vytvořila větší aplikaci SOA. Budováním vrstvy po vrstvě lze vytvořit velkou aplikaci SOA, která zůstane volně spojená.

Obecné pokyny

Udržet volně spojené integrované služby by vyžadovalo, aby všechny služby byly postaveny na atomových a složených službách. Jakmile integrovaná služba používá jinou službu, která je poněkud pevně spojena, celá aplikace služby se pevně spojí. Je to analogické s tím, jak se atomové struktury „nabijí“, pokud chybí jen jeden elektron. Z tohoto důvodu musí návrhář při používání služeb třetích stran zajistit, aby služba zůstala volně spojená.

• Pokud je služba závislá na službách třetích stran, musí být tyto služby také volně spojeny.
• Pokud třetí část nabízí atomové služby, pak mohou být složené služby vytvořeny smícháním knihoven architektury orientovaných na služby a atomových služeb třetích stran.
• Pokud je některá ze služeb považována za úzce spojenou, což může být nezbytné, pokud se jedná o průmyslové zařízení (např. Robotická ramena, spotřební zařízení atd.), Měla by to být konečná služba a od nich by neměla být odvozena žádná služba . Pokud jsou další služby postaveny na úzce vázaných službách, jsou odvozené služby také pevně vázané. Tyto odvozené služby mohou být použity ve specializovaných aplikacích, kde je vyžadována těsná vazba (např. V přesných strojích).

Následuje hierarchie, ve které by měly být navrženy všechny aplikace orientované na služby.

Hierarchie

V ideálním případě by měl být přístup k návrhu aplikace SOA následující:

• Integrované služby - založené na složených a atomových službách
  • Složené služby - založeno pouze na atomových službách
    • Atomové služby - žádná závislost, tato služba je atom

Struktury, kterým je třeba se vyhnout

V některých případech nemusí být možné volné spojení kvůli spoléhání se na hardware, mechanické systémy nebo speciální nástroje. Například pokud existuje služba postavená na pohybu robotického ramene, monitorování průmyslových generátorů nebo pohotovostního nemocničního vybavení. Poté jsou vyžadovány úzce spojené služby. Úzce spojené služby by měly být v hierarchii na vrcholu, aby žádná jiná služba nemusela znovu používat těsně spojené služby, pokud je to možné. Pokud existují odvozené služby založené na úzce vázaných službách, pak se všechny odvozené služby také stávají těsně vázané. Takový systém, pokud je navržen, by měl být omezen na rozsah účelu aplikace.

Viz také

• Volné spojení
• webová služba
• Atomový provoz

Reference

externí odkazy

• Specifikace webových služeb Aktuální informace o specifikacích webových služeb
• Převod reprezentativního státu Architektonické styly a design síťových softwarových architektur, disertační práce, Dr. Roy Thomas Fielding