Web 2.0 e-Learning platform

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

Uvažovaná funkcionalita

  • Autentizace uživatelů (do systému a následně v co největší míře i vůči jednotlivým službám)
    • login+heslo, podpora pro OpenID
  • Datové úložiště
  • Organizér
  • Služby pro (ideálně kolaborativní) přípravu dat (wiki, texty, tabulky, prezentace, mindmapy, ...)
  • Služby pro zveřejnění dat (specializované, obecně by toto mělo zajistit už datové úložiště)
  • Služby pro převody mezi formáty (PDF, Docbook, ...)
  • Služby pro validaci (XML, HTML, CSS, domácí úlohy z Javy, ...)
  • Podpora různých forem komunikace mezi uživateli (diskuzní fórum, blog, IM, ...)
  • Práce s RSS/ATOM kanály
    • Přímo?

Pozn.: Obsáhlejší a v rámci možností aktualizovaný přehled zajímavých Web 2.0 služeb a jejich vlastností je k dispozici zde

Technické řešení

Rámcové úvahy

Uživatelské rozhraní

Služby, které hodláme využívat, poskytují svým uživatelům vždy nějaké GUI. To je buď čistě webové, nebo webové v kombinaci s rozšířením webového prohlížeče. Stále častěji se jako doplněk k webovému rozhraní objevují také desktopoví klienti. Snaha o využití stávajícího (webového) GUI integrovaných služeb v naší aplikaci se jeví jako nevhodná hned z několika důvodů:

  • Uvažované služby nejsou pro toto použití v současné době uzpůsobeny ani svým GUI ani na straně API (kde by teoreticky připadalo v úvahu například použití WSRP)
  • Možné konflikty s autorskými právy, respektive s "terms of use" služeb
  • Nutnost přizpůsobovat se změnám uživatelských rozhraní služeb (ty navíc přicházejí relativně často)
  • Problematické zajištění nezávislosti na konkrétní službě

S integrovanými službami bude proto zacházeno čistě jako s poskytovateli funkcionality a uživatelské rozhraní bude mít naše aplikace vlastní.

Služby, které se ke svému fungování potřebují integrovat do webového prohlížeče (tento problém se v současnosti týká pouze služeb služeb pro bookmarking webových zdrojů), je možné využít při akceptování poněkud zvláštního vztahu k naší aplikaci - nové záznamy by uživatel pořizoval prostřednictvím nainstalovaného pluginu služby v prohlížeči a naše aplikace by do hry mohla vstupovat až následně, kdy by jejím prostřednictvím bylo možné s takto pořízenými daty provádět další operace.

Komunikace se službami

Ideální situace je, pokud služba nabízí oficiální API. V opačném případě je (čistě technicky vzato) možné dosáhnout stejného efektu simulací HTTP komunikace z webového uživatelského rozhraní služby. U řady služeb bychom tak ale naráželi na jejich licenční podmínky a také by toto řešení bylo zcela bez záruky na dlouhodobější korektní fungování. Pro zajímavost by ale bylo vhodné i tento přístup prakticky ověřit.

Jako komunikační protokol používají všechna oficiální API HTTP. Z pohledu přenášených dat už se přístupy různí (SOAP, XML-RPC, vlastní XML, Atom, ...). K řadě služeb existují (ať už oficiální, nebo od třetích stran) i knihovny pro Javu.

K otázce uživatelských účtů u využívané služby existují dva možné přístupy:

  1. Používat jediný účet pro všechny uživatele - některé služby sdílení účtů více lidmi ve svých "terms of use" vysloveně zakazují, u některých služeb nemusí existovat vhodný mechanismus k rozlišení dat jednotlivých uživatelů, vyšší nároky na kapacitní a jiná omezení účtu
  2. Používat pro každého uživatele jeho vlastní účet - odpadají výše uvedené problémy, ale každý uživatel si musí nejprve ručně účet založit (strojové zakládání účtů prakticky všechny služby zakazují) a zkomplikovala by se autentizace

V praxi bude možné oba přístupy i kombinovat, ve většině případů ale předpokládáme druhou variantu (každý uživatel používá vlastní účet).

Integrační a komunikační jádro

Jako zajímavá se jeví možnost využití platformy JBI, ačkoliv její primární účel je poněkud jiný. Přínosy použití JBI by byly zejména:

  • Směrování a doručování zpráv
  • Orchestrace služeb (na deklarativní úrovni s využitím jazyka BPEL nebo alternativních formalismů)

Mírnou nevýhodou použití JBI je, že vzhledem ke svému primárnímu určení, kterým je integrační platforma, nepodporuje (bez implementačně-specifických rozšíření) žádný specifický způsob pro komunikaci s "klientskou aplikací". Uživatelské rozhraní by proto muselo s JBI komunikovat stejně jako všechny ostatní služby. Nejjednodušší pro implementaci bude patrně využití standardní SOAP webové služby - klientská aplikace by vystupovala v roli klienta webové služby, poskytované JBI kontejnerem.

V rámci platformy nepředpokládáme existenci adresářové služby, registrující dostupné služby (např. s využitím UDDI). Klientské aplikace budou vždy vyvíjeny s ohledem na aktuální nabídku platformou poskytovaných služeb. Tato nabídka se samozřejmě v průběhu času může rozšiřovat, měla by ale zůstat zpětně kompatibilní ve smyslu zachování funkčnosti a rozhraní dříve poskytovaných služeb.

Vzhledem k charakteru poskytovaných služeb (např. komunikace) nebude na úrovni platformy realizována podpora pro vysokoúrovňové transakce. Pokud to charakter služeb umožňuje, je samozřejmě možné a vhodné implementovat transakční chování na úrovni jednotlivých operací z rozhraní komponent typu Connector nebo Mashup (ve smyslu atomicity, konzistence a trvanlivosti těchto operací - izolaci z principu není možné zaručit).

Vzhledem k charakteru platformy se u veškeré komunikace v rámci platformy i navenek s Web 2.0 službami předpokládá synchronní režim. Asynchronní komunikace prostřednictvím front zpráv by mohla být snad implementována dodatečně jako opatření zvyšující robustnost platformy vůči výpadkům Web 2.0 služeb, respektive spojení s nimi.

Návrh řešení

Typy komponent

  • Connector - komponenty zajišťující vystavení funkcionality konkrétní Web 2.0 služby do prostředí JBI kontejneru. Vystupují tedy jednak jako klientské aplikace vůči dané Web 2.0 službě a druhak jako poskytovatelé funkcionality v rámci JBI. Mohou být realizovány podle potřeby jak samostatnou BC, tak i celým řetězcem spolupracujících SU (jejichž interakce nakonec završí nějaká SU, komunikující přímo s API Web 2.0 služby).
  • Mashup - další typ komponent, poskytujících funcionalitu do prostředí JBI kontejneru. Tentokrát ale ne pouze zpřístupněním konkrétní Web 2.0 služby (jako je tomu u výše zmíněných Connector komponent), ale naopak vhodným nakombinováním funkcionalit několika služeb (samozřejmě prostřednictvím příslušných Connector komponent).
  • Client provider - konkrétní JBI komponenta, zajišťující vystavení funkcionality výše uvedených komponent pro Client application formou webové služby.
  • Client application - aplikace s webovým nebo desktopovým grafickým uživatelským rozhraním, vystupující kvůli zajištění aplikační logiky jako klient webové služby, poskytované komponentou Client provider. Komunikace mezi Client application a Client provider musí být autentizovaná. Při vývoji Client application se vychází ze statické znalosti identifikátorů a rozhraní jednotlivých komponent typu Connector a Mashup.
  • Authentication - konkrétní JBI komponenta, spravující zejména autentizační údaje uživatelů pro přihlašování k jednotlivým Web 2.0 službám

Každá z těchto vysokoúrovňových komponent by měla v rámci JBI tvořit samostatnou SA tak, aby bylo jednoduché jednotlivé komponenty odebírat, přidávat, zaměňovat apod. Výjimkou by mohly být konkrétní komponenty, společně tvořící jádro systému (Authentication, Client provider aj.), které by mohly tvořit společnou SA.

Web2.0 platform components.png

Komponenty "Connector"

Z analýzy používaných způsobů komunikace (a zejména autentizace) vyplynuly tyto požadavky:

  • jedna operace na interním (JBI) rozhraní komponenty může vyústit v provedení více HTTP(S) dotazů
  • potřeba nastavovat HTTP hlavičky (Authorization aj.)
  • potřeba šifrované komunikace přes HTTPS (během vykonání jedné operace může být dokonce potřeba HTTP a HTTPS střídat)

V principu existují dvě možnosti, jak realizovat komponenty typu Connector. Komunikace s Web 2.0 službou a interní logika komponenty (autentizace, zajištění požadovaného odstupu jednotlivých volání API služby, simulace práce s adresáři u "storage" služby, která ji nativně nepodporuje apod.) mohou být buď napsány v Javě jako POJO, EJB nebo webová služba, jejichž rozhraní se následně zpřístupní do prostředí JBI kontejneru, a nebo mohou být řešeny provázáním, tzv. "orchestrací" činnosti několika JBI komponent (s využitím BPEL SE, HTTP BC aj.). Oba přístupy je možné i kombinovat.

Možnosti realizace Connectoru v Javě:

  • POJO (vystavený do JBI prostřednictvím servicemix-bean, servicemix-jsr181, servicemix-cxf-se, petals-se-pojo apod.)
  • EJB (vystavená do JBI prostřednictvím JBI4EJB, v aktuální verzi ale podporuje pouze EJB 2.1)
  • Webová služba (vystavená do JBI prostřednictvím JavaEE SE, HTTP BC, servicemix-http, servicemix-cxf-bc, petals-bc-soap apod.)

JBI komponnety využitelné pro realizaci Connectoru na úrovni konfigurace JBI komponent:

  • HTTP BC, servicemix-http, petals-bc-http apod. pro komunikaci s Web 2.0 službou prostřednictvím čistého HTTP
  • HTTP BC, servicemix-http, petals-bc-soap, servicemix-cxf-bc apod. pro komunikaci s Web 2.0 službou prostřednictvím HTTP/SOAP
  • servicemix-eip, servicemix-camel, servicemix-osworkflow, BPEL SE, petals-se-eip apod. pro realizaci interní logiky komponenty

Ze všech výše uvedených variant se jako optimální jeví využití POJO z těchto důvodů:

  • jednoduchost implementace i integrace do JBI
  • prakticky neomezené možnosti díky plné síle jazyka Java
  • možnost využít existující knihovny pro práci s Web 2.0 službami(!)
  • bezproblémová možnost komunikovat v případě potřeby během zpracování s jinou JBI komponentou

Poznámky k ostatním variantám:

  • nastavování HTTP hlaviček příslušné BC nepodporují - pracují podle instrukcí pro WSDL 1.1 HTTP resp. SOAP binding. U servicemix-http BC je možné problém vyřešit implementací vlastního marshalleru, u ostatních HTTP BC by patrně jedinou možností byla úprava jejich zdrojového kódu.
  • komunikace přes HTTPS pro příslušné BC problém není, pro střídání HTTP a HTTPS by ale musely existovat dvě samostatné konfigurace pro BC

Složitost komponent typu Connector se může velmi lišit. Jedním extrémem může být například služba pro posílání e-mailů, která bez nutnosti jakékoliv autentizace nebo předzpracování poskládá z obsahu obdržené zprávy e-mail a odešle ho. Může jít ale i o komplikovanou komponentu řešící část aplikační logiky, autentizaci vůči Web 2.0 službě, session pro komunikaci s Web 2.0 službou během opakovaných interakcí, zajištění korektního chování vůči službě (např. rozestupů jednotlivých volání), kešování pro omezení přístupů k Web 2.0 službě, robustnost vůči výpadkům Web 2.0 služby apod. Z těchto důvodů je prakticky vyloučeno se na úrovni platformy snažit o unifikaci vnitřní struktury nebo vnitřního fungování komponent typu Connector a omezíme se proto pouze na poskytnutí určitých služeb, které umožní komponentám typu Connector jejich jinak veskrze autonomí fungování.

Komponenty "Mashup"

Komponenty typu Mashup jsou klíčové pro univerzálnost použití navrhované platformy. Vzhledem k tomu, že není žádoucí ani možné předjímat všechny možné způsoby využití platformy, nabízejí se v principu dvě varianty, kde princip kombinování základní nabízené funkcionality řešit - buď až v klientské aplikaci a nebo ještě v rámci JBI. Pro druhou variantu jsme se rozhodli zejména kvůli využitelnosti Mashup komponenty ve všech potenciálních klienských aplikacích a také kvůli možnosti vytvářet tyto komponenty deklarativním způsobem bez nutnosti implementace. Na druhou stranu toto řešení klade větší nároky na vývojáře, protože ti musí dokázat vytvořit SA. Tato vstupní bariéra je z části odstranitelná kvalitní dokumentací.

Autentizace uživatelů vůči systému i vůči jednotlivým službám

  • Při vytvoření účtu sdělí uživatel komponentě Authentication všechny potřebné údaje pro přihlašování do systému i pro autentizaci vůči Web 2.0 službám
  • Jako reakci na úspěšné přihlášení do systému obdrží Client application od komponenty Authentication jednoznačné SessionID, kterým se bude následně prokazovat při každém volání Client Provideru
  • Pokud vznikne potřeba autentizovat uživatele vůči některé Web 2.0 službě, dotáže se příslušný Connector na potřebné údaje komponenty Authentication
Web 2.0 platform authentication.png

Otevřené otázky

  • Bude potřeba řešit session ještě někde jinde, než v Connectorech (u těch je to žádoucí už kvůli tomu, aby se nemuselo opakovaně autentizovat před každým voláním)

Zhodnocení terms-of-use uvedených služeb

Kritéria - Business model

  • Poskytuje služba i placenou variantu, pokud ano tak v čem se liší?
  • Omezuje služba zakomponování svého GUI do jiné aplikace?

Kritéria - Aplikační rozhraní

  • Omezuje služba automatizovaný přístup ke svému uživatelskému rozhraní?
  • Poskytuje služba oficiální aplikační rozhraní (API), pokud ano pokrývá API kompletně nabízenou funkcionalitu?

Kritéria - Data

  • Je omezován charakter vkládaných dat?
  • Je podporováno omezování přístupu k vloženým datům, pokud ano s jakou granularitou (v určení dat i přistupujících)?
  • Jakými pravidly (případně jakou licencí) se řídí nakládání s vloženými daty?

Výsledek zhodnocení je dostupný zde

Dílčí cíle

  • Identifikovat typy služeb (podle nabízené funkcionality), které by bylo vhodné využít [OK]
  • Provést rešerši "terms-of-use" služeb po stránce jejich zakomponování do dalších systémů, automatizovaného přístupu apod. [OK]
  • Najít v každé tematické oblasti (viz. bod 1) vhodné kandidáty pro integraci z pohledu technického řešení i licenčních podmínek
  • Identifikovat potřebnou technologickou výbavu pro aplikaci integrující Web 2.0 služby (na straně serveru/na straně klienta)