CZ20004081A3 - Systém klient-server pro udržování nastavení aplikace v hierarchické datové struktuře podle kontextu uživatele a skupiny uživatelů nebo terminálu a skupiny terminálů - Google Patents

Abstract

V systému se sítí (100) propojující server (110) a množství uživatelských stanic systémový administrátor (108) modeluje uživatele systému, nebo skupiny uživatelů, terminály a skupiny terminálů, jako hierarchii a nastavuje pracovní plochu a nastavení uživatelské aplikace pro každou skupinu a pro jednotlivé uživatele zvlášť. Pro zvolený kontext skupiny, například skupinu všech uživatelů systému, nebo některou Jř, podskupinu pod skupinou, která reprezentuje všechny uživatele, je určena výchozí skupina nastavení pro zvolenou uživatelskou aplikaci. Výchozí skupina je pak upravena nastavením, které je specificky určeno ve zvolené skupině. Toto nastavení může být pak opět upraveno skupinou nastavení, která patří specificky uživateli.

Description

SYSTÉM KLIENT-SERVER PRO UDRŽOVÁNÍ NASTAVENÍ APLIKACE V HIERARCHICKÉ DATOVÉ STRUKTUŘE PODLE KONTEXTU UŽIVATELE A SKUPINY UŽIVATELŮ NEBO TERMINÁLU A SKUPINY TERMINÁLŮ

Oblast techniky

Vynález se obecně týká oblastí osobních počítačů a sítí. Podrobně se týká nové a rozvíjející se oblasti počítačových sítí, ve kterých uživatelé pracovních stanic používají osobní počítač, eventuálně bezdiskový, připojený k síti jako je firemní intranet, Internet, nebo k síti nebo poskytovateli internetových služeb (ISP) pro získání přístupu k aplikacím, které jsou pak spuštěny na stolním počítači. Podrobněji se vynález týká serverového úložného prostoru s nastavením softwaru (konfiguračními daty) pro software získávaný ze serveru a běžící na stolním počítači.

Dosavadní stav techniky

Oblast počítačů v síti je nyní ještě v plenkách. Očekává se však její rychlý rozvoj, zejména v prostředí firem, z několika důvodů. Očekává se, že jakmile společnosti a eventuálně jednotliví uživatelé dosáhnou bodů aktualizace hardwaru a softwaru, bude účinnější a levnější přesun do této nové oblasti, spíže než aktualizovat tradičním způsobem s diskem vybavenými počítači a lokálně uloženými a spravovanými softwarovými aplikacemi. Například v prostředí společností může být uživatel připojen k intranetu společnosti, například pomocí internetových protokolů TCP/IP

80 754 • · *

Λ» · ♦ « • · * · « » • » · · • 9 9 ♦ » « · · · • · · 9 (ί · «· a HTTP a stahovat programové aplikace podle potřeby přímo ze síťového serveru na stolní počítač. Aplikaci spustí na pracovním počítači tradičním způsobem uživatel, aby prováděla užitečnou práci. Výhoda této konfigurace je ta, že počítače v síti jsou podstatně levnější, než tradiční diskem vybavené počítače. Mohlo by také být levnější koupit požadovaný počet programových licencí pro uživatele, spíše nežli kupovat jednotlivé kopie softwaru pro každého uživatele. Samozřejmě problémy se správou softwaru, které doprovází velký počet uživatelů firmy, se podstatně sníží. V současnosti je každý uživatel diskem vybaveného počítače nebo pracovní stanice často vlastně svým systémovým administrátorem, což je role, která často spotřebovává více prostředků kvůli nedostatku zkušeností. Očekává se, že je velkou výhodou odstranit tento problém účinným odlehčením problému na malý počet expertů pro správu serveru, spíše nežli nechat mnoho uživatelů bojovat s problémy instalace softwaru, aktualizací a správy počítačů.

Jak bylo uvedeno výše, tato vize budoucích osobních počítačů je momentálně v plenkách. Následkem toho existuje momentálně mnoho problémů a nedostatků u existujících systémů.

Typicky v systémech síťových počítačů administrátor vytváří uživatelské profily, které jsou uloženy na síťovém serveru. Profily mohou obsahovat různé typy informací, jako například nastavení uživatelské plochy a práva uživatele pro přístup k různým programovým aplikacím, které se mohou nacházet na serveru. Jakmile se uživatel přihlásí do systému, identifikuje se na serveru, server pro něj najde profil a přenese jej na jeho počítač, kde se použije ke konfiguraci počítače a ke generování pracovní plochy.

·

Pracovní plocha může obsahovat mnoho ikon představujících aplikace, ke kterým má uživatel pravděpodobně přístup. Profil pravděpodobně také obsahuje jiné atributy počítače a pracovní plochy, jako například barvu, pozadí pracovní plochy, nebo písma a velikosti písem v bodech, použitých na pracovní ploše, nebo seznam prohledávaných míst k souborům (seznam cest) atd., které jsou pro uživatele jedinečné. Profily mohou být upravitelné uživatelem nebo neupravitelné.

V prostředí, ve kterém mohou uživatelé měnit své vlastní profily, je upravený profil nahrán zpět na server v době odhlášení, kde je uložen pro získání při příštím přihlášení uživatele. V některých systémech podle předchozího stavu techniky, podle nejnovějších poznatků, mohou uživatelé generovat na svých pracovních plochách jakoukoli kombinaci aplikačních ikon, kterou chtějí, ať už existují či neexistují na serveru, a ať už má či nemá uživatel skutečně povolení k přístupu k aplikaci na serveru. Systém Lotus Workplace Desktop (předtím nazvaný Koná Desktop) je příkladem tohoto typu práce. V jiných systémech server nabídne uživateli seznam všech aplikací, které server má, ze kterých si může vybrat. V tom případě neexistuje záruka, že uživatel má skutečně povolení přístupu k aplikaci, která je zvolena ze seznamu pro zahrnutí na pracovní plochu. Systém Sun Hot Java Views je příkladem tohoto typu systému. Jinými slovy systémy z předchozího stavu techniky nesledují vztah mezi tím, co uživatel smí nastavit pro skupinu aplikačních ikon na ploše, a aplikacemi, ke kterým má uživatel skutečně právo přistupovat. V tom případě jakmile uživatel klepne na ikonu pro spuštění aplikace, může se objevit chybové hlášení (jako například zpráva o neoprávněném přístupu) pokud není povolení k přístupu přítomné, nebo v horším případě se • · • ·

• · · φ

• · * ♦ • « · 4 • · · ·

Φ · ♦ Φ • · Φ · počítač uživatele může vyhroutit.

Jiné omezení v existujícím oboru je to, že je použita plochá datová struktura k modelování uživatelů, skupin uživatelů, terminálů a skupin terminálů. Po vzoru běžného schématu správy přístupu uživatelů k počítačovým prostředkům, implementují známé počítačové implementace (např. Lotus Administration Facility for Desktops, profily a pravidla Microsoft Windows NT Profiles and Policies a Sun Hot Java Views) plochou strukturu skupin na serveru pro správu programových nastavení (nebo atributů) v různých kontextech. Kontext, tak jak je zde použit, označuje jednotlivého uživatele, skupinu uživatelů, terminál, nebo skupinu terminálů. Jakákoli struktura seskupování pro správu nastavení softwaru na serveru umožňuje administrátorovi definovat atributy nastavení pro různé skupiny uživatelů a také pro jednotlivé uživatele. Ploché systémy jsou ale neflexibilní v mnoha prostředích, zejména v prostředích, která mají velký počet uživatelů. Je žádoucí zajistit administrační nástroj podporující organizaci informací s nastavením do hierarchické struktury.

Jiné omezení existujících systémů je, že jsou omezeny tak, že administrátoři a uživatelé musí provádět uživatelská nastavení pracovních ploch pracovní stanice. Po administrátorech se například momentálně vyžaduje konfigurovat uživatelské nastavení pomocí konfiguračních programů, které jsou oddělené od uživatelské aplikace, ale přidružené k uživatelské aplikaci. Je žádoucí, povolit prodejcům poskytnout pouze jednu aplikaci. Aby bylo možné vyžadovat pouze koncovou uživatelskou aplikaci od prodejce, je nutné, aby byla funkce centrální správy schopna spustit koncovou uživatelskou aplikaci v kontextu uživatele nebo • · • · · · · · • » · · · • » · · ·· 4»· « · ♦ • · « skupiny uživatelů. Předchozí stav techniky neumožňuje tuto administrační flexibilitu práce. Jinými slovy, v předchozím stavu techniky podle posledních poznatků nemá administrátor možnost spustit uživatelskou aplikaci v kontextu uživatele pro nastavení možností pro daného uživatele a aplikaci. Dále v současném stavu techniky nemůže administrátor spustit uživatelskou aplikaci k nastavení možností v kontextu skupiny uživatelů.

Další omezení předchozího stavu techniky známé vynálezcům je způsob, kterým předchozí stav techniky dělí trvalý úložný prostor serveru, aby se zajistilo vyhrazení jedinečného prostoru k uložení uživatelských nastavení týkajících se různých aplikací na serveru. Podle znalostí vynálezců, problém zabraňování kolizí v úložném prostoru informací s nastavením pro různé aplikace v objektově orientovaných systémech, ve kterých objekt může být dotazován na svůj úplný název třídy, který jej jednoznačně identifikuje a odlišuje od jiných tříd, je řešen tak, že první centrální orgán přidělí jedinečné označení, které se týká prodejce a pak druhý orgán u prodejce přidělí druhé označení vzhledem k prvnímu označení pro každou aplikaci Například prodejci A by mohlo být přiděleno prodejceA od prvního orgánu a je zaručena jedinečnost tohoto označení v architektuře, pro kterou je první orgán činný. Druhý orgán u prodejce A pak přidělí druhé označení pro každou z jeho aplikací v této architektuře. Například jedna aplikace prodejce A může být označena prodejceA.Appl; další může být označena prodejceA.App2. Tato technika mapuje jedinečné označení pro každou aplikaci v systému místu v trvalém úložném prostoru systému tak, aby zajistila, že data s nastavením pro různé aplikace v úložném prostoru nekolidují. Aplikace, jakmile prodej ce, označení

běží, informuje síťový počítačový server o svém jedinečném úložném místě a je zodpovědností serveru rozdělit oblast na počátečním místě podle kontextu (uživatel, skupina uživatelů, terminál nebo skupina terminálů) pro uložení informací s nastavením tak, aby nekolidovaly s informacemi s nastavením v jiném kontextu. Samozřejmě tento způsob správy úložného prostoru je nešikovný a nežádoucí. Je žádoucí vyvinout způsob automatického generování jedinečných míst v úložném prostoru pro ukládání informací s nastavením pro výše uvedené objektově orientované aplikace, bez nutnosti požadavku, aby centrální orgány přidělovaly jedinečná označení pro účely zabránění kolizí v úložném prostoru informací s nastavením a bez zakódování informací o umístění úložného zařízení do aplikace.

Další omezení v oboru spočívá v nedostatku jakéhokoli opatření pro přesun existujících aplikací a hardwaru do nového prostředí centrálně spravovaného světa síťových počítačů aniž by se vyžadovaly změny existujícího hardwaru a aplikací. Existující hardware, například terminál v síťovém prostředí, získá své informace o konfiguraci při zavedení systému ze souboru ve specifickém formátu umístěném na serveru. Terminál je naprogramován tak, aby věděl, jak přistupovat ke svému konfiguračnímu souboru. Terminál používá jedinečný identifikátor pro přístup k souboru ze serveru. Jedinečný identifikátor je často řídící přístupová adresa média (MAC adresa) terminálu. V novém centrálně spravovaném prostředí obsahujícím protokoly a API, které jsou jiné než ty, pro které je terminál navržen, však nemůže terminál přistupovat k informacím s nastavením v novém prostředí, terminál může přistupovat pouze ke svému konfiguračnímu souboru způsobem, pro který je navržen. To je vážný problém, protože se používá mnoho takových • · · · · * • · · · 9 · «· existujících zařízení. Nemožnost použít je v nových systémech zabraňuje podstatně v motivaci uživatelů na přechod na nové systémy.

Další omezení v předchozím stavu techniky uvažuje rozhraní mezi administrátorem a systémem správy konfigurace. Pokud se konfiguruje software v administračních prostředcích pro nakonfigurování informací s nastavením pro různé uživatele a skupiny uživatelů a terminály terminálů, administrační software se spustí skupiny uživatelů, terminálu nebo skupiny nastaveném administrátorem, který spouští a skupiny v kontextu (uživatele, terminálů) prostředky. Jakmile administrátor změní kontext, ve kterém aplikace běží, je třeba znovu spustit zavedení informací s nastavením pro nový kontext, nového spuštění softwaru po každé změně kontextu administrátora časové náročné a nepohodlné, v systémech s mnoha uživateli.

očekává, že administrátor změní kontexty mnohokrát při konfiguraci aplikace.

aplikaci kvůli

Proces je pro zejména

V těchto systémech se

Podstata vynálezu

Podle jednoho hlediska tento vynález poskytuje v síťovém systému obsahujícím síť propojující server a množství uživatelských stanic, kde server ukládá množství uživatelských aplikací pro stažení na uživatelské stanice, způsob správy uživatelského nastavení konfigurace pro aplikace spouštěné na uživatelské stanici, přičemž způsob obsahuje kroky: reprezentace všech uživatelů systému ve stromové hierarchii skládající se ze skupinového uzlu

AllUsers, obsahujícího všechny uživatele systému, a množství synovských skupinových uzlů, přičemž každý obsahuje zvolené z uživatelů, které patří do skupiny reprezentované synovským skupinovým uzlem, přičemž každý uzel obsahuje nastavení konfigurace pro zvolené z aplikací dostupných v systému; přidělení pořadí priorit skupin pro každého uživatele, který je členem více než jedné skupiny; vzhledem k jakémukoli danému uživateli požadujícímu spuštění zvolené aplikace, určení pořadí priorit skupin pro uživatele; a sestavení skupiny nastavení konfigurace ze stromu určením první skupiny ze seznamu priorit skupin, ze které lze odvodit skupina nastavení pro zvolenou aplikaci; sloučení nastavení do skupiny pro zvolenou aplikaci procházením stromu od skupinového uzlu AllUsers k první skupině; sloučení nastavení určeného v každém uzlu pro zvolenou aplikaci; a úprava shromážděného nastavení při průchodu každého uzlu nastavením určeným v tomto uzlu pro zvolenou aplikaci.

Podle druhého hlediska poskytuje tento vynález v síťovém systému obsahujícím síť propojující server a množství uživatelských stanic, kde server ukládá množství uživatelských aplikací pro stažení na uživatelské stanice, zařízení pro správu uživatelského nastavení konfigurace pro aplikace spouštěné na uživatelské stanici, přičemž zařízení obsahuje: prostředky pro reprezentování všech uživatelů systému ve stromové hierarchii skládající se ze skupinového uzlu AllUsers, obsahujícího všechny uživatele systému a množství synovských skupinových uzlů, přičemž každý obsahuje zvolené z uživatelů, které patří do skupiny reprezentované synovským skupinovým uzlem, přičemž každý uzel obsahuje nastavení pro zvolené z aplikací dostupných v systému; prostředky pro přiřazení pořadí priorit skupin pro každého uživatele, který je členem více než jedné skupiny; vzhledem β ·

k jakémukoli danému uživateli požadujícímu spuštění zvolené aplikace, prostředky pro určení pořadí priorit skupin pro uživatele; a prostředky pro sestavení skupiny nastavení konfigurace ze stromu určením první skupiny ze seznamu priorit skupin, ze kterých může být odvozena skupina nastavení pro zvolenou aplikaci; sloučení nastavení do skupiny pro zvolenou aplikaci procházením stromu od skupinového uzlu AllUsers do první skupiny; shromažďování nastavení určených v každém uzlu pro zvolenou aplikaci; a upravení shromážděného nastavení při průchodu každým uzlem nastavením určeným v tomto uzlu pro zvolenou aplikaci.

Podle třetího hlediska tento vynález poskytuje počítačový programový produkt uložený na počítačem čitelném úložném médiu pro, pokud je spuštěn na počítači, provádění v síťovém systému obsahujícím síť propojující server a více uživatelských stanic, kde server ukládá množství uživatelských aplikací pro stažení na uživatelské stanice, způsob správy uživatelského nastavení pro aplikace spouštěné na uživatelské stanici, přičemž způsob obsahuje kroky: reprezentování všech uživatelů systému ve stromové hierarchii skládající se ze skupinového uzlu AllUsers, který obsahuje všechny uživatele systému, a množství synovských skupinových uzlů, přičemž každý obsahuje zvolené z uživatelů, které patří do skupiny reprezentované synovským skupinovým uzlem, přičemž každý uzel obsahuje nastavení konfigurace pro zvolené z aplikací dostupných v systému; přiřazení pořadí priorit skupin pro každého uživatele, který je členem více než jedné skupiny; vzhledem k jakémukoli danému uživateli požadujícímu spuštění zvolené aplikace, určení pořadí priorit skupin pro uživatele; a sestavení skupiny konfiguračního nastavení ze stromu určením první skupiny ze seznamu priorit skupin, ze které může být skupina • · · · · · • ♦ ·

4 4 nastavení odvozena pro zvolenou aplikaci; sloučení nastavení do skupiny pro zvolenou aplikaci procházením stromu od skupinového uzlu AllUsers do první skupiny; shromažďování nastavení určeného v každém uzlu pro zvolenou aplikaci; a úprava shromážděného nastavení při průchodu každým uzlem nastavením určeným v tomto uzlu pro zvolenou aplikaci.

Zde popsaný systém poskytuje společné úložiště pro konfigurační informace pro uživatele a aplety v prostředí klient-server. To se označuje jako správa klientských profilů. Systém umožňuje uživatelům měnit počítače (roamovat), to znamená přihlásit se kdykoli z libovolného počítače v systému a nechat jej nastavit automaticky za běhu podle nastavení uloženého pro uživatele na serveru. Upřednostňované provedení je systém založený na Jávě (Java je ochranná známka firmy Sun, lne.) a klientské počítače používají rozhraní webovského prohlížeče uspořádané ke spouštění Java aplikací. Tudíž v upřednostňovaném provedení se předpokládá, že uživatelské aplety a aplet pracovní plochy jsou Java aplety. Není však úmyslem omezit vynález na prostředí Jávy. Nastavení pro lokálně uložené aplikace by mohly být uloženy lokálně tradičním způsobem, zatímco nastavení pro serverové aplety by mohlo být ošetřováno zde popsaným způsobem.

Vynález umožňuje systémovému administrátorovi modelovat uživatele systému, nebo skupiny uživatelů, terminály a skupiny terminálů jako hierarchii, a nastavovat pracovní plochu a nastavení uživatelských aplikací pro každou skupinu a pro jednotlivé uživatele odděleně. Pro zvolený kontext skupiny, řekněme skupinu všech uživatelů systému, nebo nějakou podskupinu, která obsahuje skupinu zvolených uživatelů, je určena výchozí skupina nastavení pro zvolený • 9

9 9 9 • 9 9 9

· 9 9·· • 9 · 9 9 • · · · · 9 9 9 • 99 · • 9 « 9 · · uživatelský aplet. Výchozí skupina je pak upravována podle nastavení, která jsou specificky uvedena ve zvolené skupině. Toto nastavení je pak opět upraveno skupinou nastavení, která patří specificky uživateli.

V upřednostňovaném provedení jsou všichni uživatelé systému reprezentováni ve stromové hierarchii skládající se ze skupinového uzlu AllUsers obsahujícího všechny uživatele systému a množství synovských skupinových uzlů, přičemž každý z nich obsahuje skupinu zvolených uživatelů, které patří do skupiny reprezentované synovským skupinovým uzlem. Každý uzel také obsahuje konfigurační nastavení pro zvolené z aplikací, které jsou dostupné v systému. Administrátor přidělí pořadí priorit skupin pro každého uživatele, který je členem více než jedné skupiny. Jakmile je aplikace spuštěna uživatelem, aplikace požaduje svá nastavení ze serveru. Nejdříve se určí pořadí priorit skupin pro uživatele. Pak se sestaví skupina nastavení konfigurace ze stromu určením první skupiny ze seznamu priorit skupin, ze které lze odvodit skupinu nastavení pro zvolenou aplikaci a pak se sloučí nastavení do skupiny pro zvolenou aplikaci. Slučování se provádí procházením stromu od skupinového uzlu AllUsers do první skupiny, přičemž se shromažďuje nastavení určené v každém uzlu pro zvolenou aplikaci a upravuje se shromážděné nastavení při průchodu každým uzlem nastavením určeným v tomto uzlu pro zvolenou aplikaci.

Vynález poskytuje mnohem více organizační flexibility a možností administrace, než může nabídnout nehierarchická struktura. Hierarchická struktura může přesněji popsat organizaci většiny společností. Čím větší je modelovaná společnost, tím důležitější je schopnost organizovat hierarchicky.

Přehled obrázků na výkresech

Vynález bude blíže vysvětlen prostřednictvím konkrétních příkladů provedení znázorněných na výkresech, na kterých představuje vzorová síť a uživatelské stanice, obsahující stanici administrátora, na které lze vynález provést vzorový blokový diagram stanice administrátora v komunikaci se serverem a administrátora a server centrální správy profilů nastavení komponenty stanice pro poskytování a administrace obr. 3 vzorová hierarchická organizace skupin uživatelů a uživatelů systému. Vzorová hierarchická organizace by také mohla obsahovat jednotlivé terminály a skupiny terminálů; ty jsou však kvůli zjednodušení vynechány obr. 4 jeden vzorový seznam jednotlivých uživatelů a pořadí priorit skupin, které se používá k určení skupiny nastavení z hierarchické organizace z obr. 3, které se týkají uživatele a určité aplikace spuštěné uživatelem obr. 5 podrobnější pohled na stanici administrátora a server z obr. 2;

obr.

vzorový pohled na terminálu uživatele, aplikaci a komponenty,

softwarové objekty na obsahujícím uživatelskou API mezi aplikací a jinými které spolupracují pro založení uživatelskOho nastavení během provádění aplikace na terminálu uživatele;

obr. 7 až 8 vzorové operace jak na terminálu uživatele, tak na serveru pro přihlášení uživatele a počáteční založení pracovní plochy uživatele, včetně nastavení uživatele;

pracovní plochy, na terminálu obr. 9 až 11 vzorové terminálu, administrátorově pro přihlášení pracovní operace jak na tak na serveru užívatele-administrátora, založení plochy administrátora, a například zvolení aplikace a kontextu pro konfiguraci; příklad také znázorňuje změnu kontextu během konfigurace pracovní plochy uživatele a výsledné operace; a obr. 12 až 24 různé skutečné zachycené obrazovky administrátora v různých fázích správy aplikace, včetně sestavení hierarchie, pro kterou ukazuje obr. 3 reprezentaci příkladu, vytváření a odstraňování uživatelů, atd. založení aplikačních nastavení pro aplikace, a změny kontextu při zakládání nastavení.

Příklady provedení vynálezu

Zde popsaný systém poskytuje společné úložiště pro ·· 4··

informace o konfiguraci pro všechny uživatele a aplety v prostředí klient-server. To se nazývá správa klientských profilů. Systém umožňuje uživatelům měnit . stanice (roamovat), to znamená přihlašovat se kdykoli z libovolného počítače v systému a nechat jej automaticky nastavit při spuštění podle nastavení uloženého na serveru. Upřednostňované provedení je systém založený na Jávě (Java je ochranná známka Sun, lne.) a klientské počítače používají rozhraní webovského prohlížeče uspořádané tak, aby v něm běžely Java programy.

Termíny aplet a serviet jsou známé termíny z oblasti programovacího jazyka Java a budou zde používány, protože tyto termíny mají pro odborníky význam. Aplet označuje nezávislý softwarový modul, který běží ve webovském prohlížeči se schopností provádět Java kód. Serviet označuje softwarový modul, který se nachází na webovském serveru s podporou Jávy. Rozumí se, že použití termínů aplet a serviet zde není žádným způsobem zamýšleno k omezení vynálezu. Slovní spojení konfigurační aplet zde označuje softwarový modul používaný ke konfiguraci nastavení pro programovou aplikaci koncového uživatele, jako je textový procesor, databázový správce, atd. Protože programové aplikace jsou, také aplety v prostředí Java, slovní spojení uživatelský aplet nebo jen aplet je zde použit k označení koncové uživatelské aplikace.

V upřednostňovaném provedení se předpokládá, že uživatelské aplety a aplet pracovní plochy jsou Java aplety. Rozumí se však, že vynález není omezen na prostředí Java. Vynález může být použit v libovolném systému klient-server. Například, pokud je to žádoucí, by mohl být systém navržen tak, aby používal vlastní komunikační protokoly a aplikace • · · · · 9 ·

• · · · · ······ • · · · · · · 9 · ·· · 9· · · · · · · ·* napsané a zkompilované v libovolném požadovaném programovacím jazyce. Dále, i v upřednostňovaném prostředí založeném na Jávě, by mohly diskové počítače přistupovat k některým aplikacím lokálně a k jiným apletům ze serveru. Nastavení pro lokálně uložené aplikace by mohlo být uloženo tradičním způsobem lokálně, zatímco nastavení pro serverové aplety by se mohlo ošetřovat zde popsaným způsobem. Přednostně je však nastavení pro lokálně uložené aplikace uloženo na serveru používajícím Profile Management Properties API (API pro správu profilů) navíc kromě nastavení pro serverové aplety zde popsané.

Jednoduché aplikační programové rozhraní (API) umožňuje apletům napsaným pro API snadno ukládat a získávat data s nastavením jakmile je aplet spuštěn uživatelem nebo administrátorem. Práva k apletu a uživatelské nastavení může být definováno na základě členství ve skupinách a identity jednotlivce.

Správa klientských profilů obsahuje následující služby:

Podpora přihlašování - namapování na profil uživatele;

Podpora uživatelů - schopnost administrátora vytvářet identifikace uživatelů a poskytovat služby a nastavení přímo uživatelům;

Podpora skupin uživatelů - schopnost administrátora vytvářet hierarchické skupiny uživatelů a poskytovat služby a nastavení na základě členství ve skupině;

Transparentnost kontextu uživatelského apletu automatické určení kontextu spuštění uživatelského apletu. To znamená, určení profilů uživatele a/nebo skupiny, které se týkají spuštění uživatelského apletu a automatického založení prostředí profilu;

Úložiště nastavení uživatelských apletu kontextové • tt · · · · • · · • tt tt • · tt • · · serverové úložiště pro data s nastavením uživatelských apletů;

Dynamická dědičnost nastavení uživatelských apletů hierarchické slučování nastavení uživtelského apletů při zavádění objektově orientovaným principem dědění; a

Řízení přístupu k uživatelským apletům - řízení spouštění uživatelských apletů na základě standardních práv díky členství ve skupině. Administrátor může překrýt standardní skupinové nastavení a povolit nebo odepřít další práva k přístupu jednotlivým uživatelům.

Správa profilů poskytuje rámec, kterým se tyto akce provádějí. Některé akce jsou podporovány přímo správou profilů, např. správa uživatelů/skupin, seznamu apletů, přepínání kontextu, dědění nastavení, atd., zatímco konfigurační služby specifické pro uživatelské aplety jsou obvykle podporovány zvláštními konfiguračními aplety vyvolanými administrátorem systému v prostředí správy klientských profilů. Některé koncové uživatelské aplety mohou poskytovat schopnost konfigurace jako část koncového uživatelského apletů. Pokud se jedná o tento případ, může administrátor spustit koncový uživatelský aplet (jako protiklad zvláštního konfiguračního apletů) v kontextu jednotlivých uživatelů a skupin k nastavení konfiguračního nastavení pro tyto uživatele a skupiny.

Obr. 1 ukazuje jedno hrubé zobrazení navrhovaného prostředí pro provedení vynálezu. Síť 100 je opatřena pro propojení množství uživatelských stanic, jako jsou stolní osobní počítače 102, mobilní počítače laptop 104, pracovní stanice 106 (např. počítače RISC), administrátorské stanice 108 a serveru 110. V jednom provedení by síť 100 mohla být lokální síť. V dalším provedení by mohla síť 100 •0 0000 • · · • 00

0 0

0 0

0 • 0 00 00

00 0 00 0

0 0 0 0 0

0 0 0 0 0 0

0 0 0 0 0

000 000 0· ·· obsahovat komunikaci v rozlehlé síti pro entity jako například společnosti, které mají zeměpisně od sebe dále rozmístěné pobočky, které jsou stále zahrnuty v systému. Není úmyslem omezit prostředí, ve kterém může být vynález proveden; ve skutečnosti se předvídá síť libovolného typu, která propojuje mnoho typů stanic.

Hrubý diagram pracovního prostředí pro správu profilů je ukázán na obr. 2. Administrační klientský síťový počítač 200 je znázorněn vlevo na obrázku a server 202 pro systém je vpravo. Klient a server komunikují sítí znázorněnou jako 203. Konkrétní příklad z obr. 2 předpokládá, že klientský počítač je počítač systémového administrátora.

Správce 206 profilů na straně klienta umožňuje administrátorovi nastavit konfiguraci uživatelských apletů jak na úrovni uživatele, tak na úrovni skupiny. Administrátor může vytvářet nové uživatele a hierarchie skupin, přidávat uživatele do různých skupin, zadávat práva k apletům pro každou skupinu a pro jednotlivé uživatele. A administrátor může konfigurovat aplety v kontextu jednotlivého uživatele nebo skupiny. Administrátoři mohou přidávat, odstraňovat a nulovat hesla pro uživatele. Podpora správy profilů je pro obecného uživatele transparentní. Administrátor může vyvolat správce 206 profilů v kontextu libovolného uživatele nebo skupiny. Pouze administrátor se ze svého kontextu pro správu klientů skupin. Server nedovolí uživateli bez administračního oprávnění přepnout kontext. Jakmile přijde na server požadavek, dotáže se na ověřené ID uživatele, který se snaží přistupovat k této funkci. Pokud uživatel nemá administrační oprávnění, (tj. není členem skupiny AllUsers.Administrátor), serviet 214 správce profilů může přepnout (uživatelů) a

214 požadavek odmítne.

Správce 206 profilů vyvolá jiné aplety, jako například appletl 208, jak je ukázáno na obr. 2. V tomto příkladě by mohl být appletl administrační aplet pro konfiguraci nastavení týkajícího se pracovních ploch uživatelů. Nebo by mohl být appletl konfigurační utilita svázaná s koncovým uživatelským apletem, jako například editory, textové procesory, databáze, atd. Upřednostňuje se, ale nevyžaduje, aby konfigurační aplety jako například 208 existovaly jako moduly odděleně od jejich odpovídajících uživatelských apletů. V kontextu na obr. 2, je Appletl typicky konfigurační aplet pro uživatelský aplet; administrátor spustí konfigurační aplet appletl pod skupinovým kontextem pro nastavení skupinového nastavení a výchozích práv nebo v kontextu uživatele k přizpůsobení konfigurací uživatelských apletů pro jednotlivce. Implementováním apletu appletl jako modulu odděleného od jeho uživatelského apletu se zlepší výkonnost, protože konfigurační aplet appletl bude pravděpodobně menší v porovnání s uživatelským apletem. Oddělené konfigurační aplety umožňují také administrátorovi řídit možnost koncových uživatelů konfigurovat uživatelský aplet.

Tradiční samostatné počítače ukládají informace s nastavením uživatelských apletů lokálně . ve spojení s uživatelským apletem. Tradiční samostatné na Jávě založené počítače ukládají informace s konfiguraci uživatelských apletů ve formátu poskytovaného třídou java.util.Properties. Obě uspořádání vyžadují, aby uživatelský aplet určoval název lokálního souboru, do kterého se mají uložit informace s konfigurací týkající se uživatelského apletu. Jinými slovy se vyžaduje vztah mezi počítačem a uživatelským apletem

zavedeným na něj. Správa profilů jak je zde popsána, poskytuje důvěrně známé funkce skutečného objektu java.util.Properties plus další funkce podporující roamování uživatelů a možnost použití jako doplňku ve výkonném administračním rámci (Správce profilů).

ProfileManagementProperties P 210 je objekt vlastností pro appletl a poskytuje API mezi apletem Appletl a serverem, který umožňuje serveru určit, kam uložit informace s nastavením pro appletl v kontextu uživatelů a skupin. Třída objektů ProfileManagementProperties poskytuje veškerou funkčnost třídy java.util.properties s další schopností zajistit vytvoření, uložení a získání konfiguračních informací pro software z trvalého úložného prostoru. Uložení těchto informací na centrální místo umožňuje správu uživatelských a skupinových konfigurací.

Jakmile je uživatel v roli administrátora, umožní ProfileManagementProperties 210 administrátorovi nakonfigurovat uživatelský aplet podle konfiguračního apletu appletl, nebo nakonfigurovat appletl pokud je appletl koncový uživatelský aplet, a uložit konfigurační informace na správné místo na server ve správném kontextu. To umožňuje založení vztahu mezi uživatelským apletem a uživatelem, spíše nežli mezi uživatelským apletem a počítačem jako v tradičních systémech. ProfileManagementProperties 210 je doplněk třídy java.util.Properties. Tento doplněk umožňuje přidružit dvojice klíč/hodnota s informacemi o nastavení objektu Properties ke klíči, narozdíl od proudu, jako u java.util.Properties. To zase umožňuje vývojářům aplikací použít klíč k určení jedinečného umístění vzhledem ke kontextu pro informace s nastavením, spíše než pomocí názvu souboru a cesty. ProfileManagementProperties 210 určí • · · · klíč automaticky. Generování nového klíče je popsáno více u obrázků 8 a 9. Modelováním ProfileManagementProperties 210 po třídě java.util.Properties může mít systém výhodu dědění nastavení rekurzivním . vyhodnocováním výchozího nastavení tříd. Tato rozšířená třída tudíž nabízí funkci standardní nastavení skupiny akumulováním nastavení počínaje na aktuálním kontextu, jak bylo popsáno u obr. 3, a procházení vzhůru kontextovou hierarchií a hledání výchozího nastavení.

Server uživatelská uživatelské

202 obsahuje databázi 212, která ukládá data a skupinová data, jako například a skupinové nastavení a práva přístupu k uživatelským apletům. Webovský server 218 representuje typický webovský server s podporou Java apletů. Serviet 214 správce profilů přiřazuje identifikace uživatelů a skupin k datům s nastavením. Také udržuje řídící seznam přístupů pro správu přístupů uživatelů k aplikacím na serveru.

Nastavení uživatelů a skupin jsou ukládány ve stromové struktuře jak je ukázáno systému automaticky patří na obr. 3. Všichni uživatelé do vrchní skupiny AllUsers. Všichni uživatelé patří do skupiny AllUsers; tato skupina obsahuje výchozí nastavení pro některé nebo všechny uživatelské aplety na serveru. Na obr. 3 se předpokládá, že server obsahuje alespoň čtyři uživatelské aplety, označené jako App3, App4, App5 a Αρρβ. Jak je uvedeno ve skupině AllUsers, standardní pozadí (BG) pro App3 je modré, BG = blue. Jiné vzorové nastavení označené jako x, y a z je ukázáno tak, aby mělo výchozí hodnoty 1, 2 a 3, v uvedeném pořadí. Termíny x, y a z mají reprezentovat libovolné požadované nastavení a hodnoty 1, 2 a 3 jsou libovolné a použité pouze k vysvětlení principu. Nastavení x by mohlo být například písmo použité na obrazovce na ploše; hodnota

χ = 1 by mohla ukazovat na výchozí písmo Times-Roman. Podobně standardní nastavení pro App4 pro všechny uživatele je BG = grey, x = 2 , y = 2 a z = 2.

Výchozí hodnoty ve skupině AllUsers mohou být měněny jakýmkoli požadovaným způsobem pro jiné kontexty, jako například pro jiné uživatelské skupiny a jednotlivé uživatele. Jako příklad, navíc ke kontextu AllUsers na obr. 3, jsou ukázány čtyři jiné skupiny (GroupX, GroupY, GroupYl a GroupY2). Navíc, jsou ukázáni dva uživatelé Userl a UserN. Uživatelé mohou být členové více než jedné skupiny. Na obr. 3 je uživatel Userl členem skupin AllUsers, GroupX a GroupYl; Uživatel UserN je členem skupin AllUsers a GroupY2. Pokud je uživatel členem více než jedné skupiny (jiné skupiny kromě AllUsers), pak jsou skupiny seřazeny podle priority kvůli zvolení nastavení pro daný aplet pro daného uživatele. Administrátor nastavuje priority skupiny pro uživatele. Priorita skupiny je znázorněna na obr. 4. Na obr. 4 má uživatel Userl skupinu GroupX (označenou úplným svou skupinu s nejvyšší Userl s další nejvyšší (AllUsers.GroupY.GroupYl).

názvem AllUsers.GroupX jako prioritou. Skupina uživatele prioritou je skupina GroupYl

Skupina s nejnižší prioritou uživatele Userl je skupina AllUsers. Jakmile uživatel, např. Userl, požaduje spuštění apletu, například App3, nastavení se sloučí ze stromu z obr. 3 podle skupiny nebo skupin, do kterých uživatel patří, a uživatelský aplet je podle toho nakonfigurován na ploše uživatele.

První krok ve shromažďování nastavení pro libovolný kontext je získat výchozí hodnoty. Výchozí hodnoty pro uživatele, pokud existují, je sloučená skupina nastavení pro aplet ze skupiny s nejvyšší prioritou, ze které lze získat • · · · • · · <

• · · « • · · · 1 • · · «

Φ · • · β φ informace s nastavením pro aplet. Výchozí nastavení pro skupinu, pokud existuje, je sloučená skupina nastavení pro (tj. skupina AllUsers je rodič Pokud skupina nemá rodičovskou AllUsers na nejvyšší úrovni), aplet od rodiče skupin skupiny AllUsers.GroupX) skupinu (tj. skupina neexistují žádné výchozí hodnoty pro tuto skupinu. Při slučování nastavení pro aplet v kontextu, přepisuje nastavení pro aplet explicitně uložené v kontextu, výchozí nastavení pro aplet pro kontext. Tudíž pro shromáždění nastavení do výchozí skupiny pro aplet v kontextu skupiny se provádí rekurzivní volání z každého uzlu skupiny směrem vzhůru ke skupině AllUsers, přičemž se požaduje po každém rodičovském uzlu skupina nastavení pro aplet. Následující příklad je znázorněn na obrázku 3. Pokud je například kontext Allusers.GroupY.GroupYl, provede se volání rodiče GroupYl, což je GroupY, přičemž se požaduje jeho výchozí nastavení pro aplet: GroupYl provede rekurzivní volání svého rodiče, což je AllUsers.

Skupina AllUSers nemá žádné rodičovské skupiny, takže AllUsers vrátí svou skupinu nastavení pro aplet na volání ze skupiny GroupY. Tato skupina nastavení je změněna nastavením uloženým ve skupině GroupY pro aplet, pokud nějaké existuje. To je nyní výchozí skupina nastavení pro aplet pro kontext skupiny GroupYl. Tato skupina výchozího nastavení je vrácena skupině GroupYl jako výchozí hodnoty rekurzivního volání ze skupiny GroupYl skupině GroupY, a jsou upraveny o nastavení ve skupině GroupYl pro aplet, pokud nějaké existuje, čímž se stane aktuální skupinou nastavení, které se má použít v této instanci. Skupina nastavení pro kontext uživatele je sestavována stejným způsobem, kromě toho, že skupina s nejvyšší prioritou, ze které lze získat informace s nastavením pro uživatele, je použita nejdříve k založení kontextu skupiny, ze kterého budou získány výchozí hodnoty. Pak se použije výše popsaná rekurzivní procedura k sestavení aktuální skupiny nastavení pro uživatele a aplet požadovaný uživatelem.

Následující příklady znázorňují výše uvedené slučování nastavení a patří k obr. 3.

Příklad 1: Administrátor spustí konfigurační aplet pro App3, aby nastavil nastavení pro skupinu AllUsers.GroupX.

Pro nastavení konfigurace pro App3 v kontextu Allusers.GroupX je nutné zjistit přítomnou skupinu nastavení. Skupina AllUsers.GroupX požaduje výchozí hodnoty pro svou rodičovskou skupinu AllUsers. Protože AllUsers je skupina na nejvyšší úrovni, vrátní své nastavení pro App3 skupině GroupX. To jsou výchozí nastavení pro App3 v kontextu GroupX. Protože GroupX nemá žádné nastavení pro App3, výchozí skupina od Allusers je skutečná skupina nastavení, která se má použít. V tomto příkladě jsou tato nastavení ze skupiny AllUsers následující: BG=Blue, x=l, y=2, z=3. Administrátor může nyní upravovat pomocí konfiguračního apletu sloučené nastavení jakýmkoli požadovaným způsobem.

Příklad 2: Uživatel Userl požaduje spuštění aplikace com.ibm.App3. Nastavení musí být sloučeno pro com.ibm.App3 v kontextu uživatele Userl.

Obr. 4 ukazuje, že skupina s nejvyšší prioritou pro uživatele Userl je skupina AllUsers.GroupX; tato větev hierarchie skupin bude ověřena nejdříve co se týče informací s nastavením týkajících se App3. Odtud je příklad v podstatě

stejný jako výše uvedený příklad 1, kromě toho, že shromážděná skupina nastavení je použita k nastavení App3 na pracovní stanici uživatele. Nastavení pro aplikaci App3 pro uživatele Userl jsou: BG=Green, x=l, y=2, z=3 protože nastavení BG=Green uložené v kontextu uživatele Userl pro App3 převáží výchozí nastavení BG=Blue získané z větve AllUsers.GroupX stromu s nastavením.

Příklad 3: Slučování nastavení pro com.ibm.App6 v kontextu uživatele Userl.

Tento příklad znázorňuje situaci, kdy skupina s nejvyšší prioritou neobsahuje žádné sloučené nastavení pro kontext uživatele Userl. Skupina s nejvyšší prioritou pro uživatele Userl je opět skupina GroupX. Tato skupina a její rodičovská skupina AllUsers neobsahují žádná nastavení pro App6. Tudíž se hledá v další skupině s další nejvyšší prioritou. Další skupina s nejvyšší prioritou pro uživatele Userl je skupina GroupYl. Skupinu nastavení lze získat z této skupiny pro App6. Slučování nastavení pokračuje podle popisu z příkladu 1. Rekurzivní volání se provádí ze skupiny GroupYl směrem vzhůru stromem do kořenové skupiny AllUsers a jsou vraceny skupiny nastavení zpět dolů rekurzivními voláními a měněny cestou tak, aby vytvořily výchozí skupinu. Výchozí skupina je pak upravena nastavením uloženým ve skupině GroupYl tak, aby se vytvořila sloučená skupina nastavení, která se použije na tento kontext. Stručně řečeno, skupina Allusers vrátí prázdnou skupinu nastavení, protože nemá žádná nastavení pro App6. Skupina GroupY upraví tuto prázdnou skupinu o hodnoty a=l a b=2 a vrátí tuto skupinu skupině GroupYl jako standardní skupinu. Skupina GroupYl upraví výchozí skupinu o a =33. Tato skupina je vrácena do kontextu uživatele Userl pro použití jako její φφφφφφ β * · · · · • * φ « φ *· · · · ♦ ♦ φ φ φ · · · · * φφφ φ φ φφφφφφ φφφ φ φ φφφφ φ φ φ φφφ φφφ φφ φφ výchozí skupina. Protože neexistuje žádné nastavení pro App6 uložené v kontextu Userl, výchozí hodnoty získané z větve GroupYl stromu s nastavením reprezentují úplně shromážděnou skupinu nastavení pro App6. Skutečná skupina nastavení bude tudíž v tomto kontextu a=33, b=2.

Výše uvedené 3 příklady popisovaly slučování nastavení odezvou na provedení load() (zavedení) určitého softwarového celku. Pokud jsou informace s nastavením uloženy pro softwarový celek, libovolné nastavení, které bylo explicitně zapsáno v ukládaném kontextu, se uloží do datového úložného prostoru 212 na místo určené kombinací kontextu, ve kterém se software spouští, a klíče pro software, jehož nastavení se ukládá.

Práva fungují podobně: nová skupina má přístup ke všem apletům povoleným samotnou skupinou a také ke všem apletům povoleným jejími nadřazenými skupinami. Avšak právě tak jako Java umožňuje programátorovi překrýt metodu nadřazené třídy, umožňuje správce profilů systémovému administrátorovi možnost převážit zděděné právo. To se nazývá převážení práva.

Jako je tomu u formy dědičnosti v Jávě, nazývá se forma dědičnosti u správy profilů nastavení a práv jednoduchá dědičnost. Jednoduchá dědičnost znamená, že každá skupina ve správě profilů může mít pouze jedinou nadřazenou skupinu (přestože libovolná daná nadřazená skupina může mít více podskupin).

Uživatelé správy profilů (koncové uzly) mohou vyžadovat členství ve více skupinách, takže je požadavek na funkci omezení dědičnosti nastavení na jednu hierarchickou skupinu

999 · • · 9 1 v · · « • · · ι · · « • · 9 9 kvůli minimalizaci pravděpodobnosti porušených konfigurací kvůli zavedení neslučitelných podskupin proměnných zavedených křížovým slučováním ze skupin. Tím, že se umožní stanovit priority členství uživatelů ve skupinách, může správa profilů sledovat pořadí vyhledávání při hledání nastavení týkajícího se konkrétního apletu. Jinými slovy počínaje skupinou s nejvyšší prioritou, zastaví se hledání na první skupině, u které byla nalezena konfigurační data pro aplet, který se pokouší zavést své nastavení.

Uživatel dědí práva k softwaru ze členství ve skupinách. S pečlivým namodelováním společnosti může administrátor přidělit přístup k softwaru mnoha uživatelům bez nutnosti procházet panely po jednom uživateli. Správa profilů řídí přístup naprogramováním webovského serveru tak, aby povoloval/odpíral přístup k apletům. Webovský server vynucuje řízení přístupu. Serviet správce profilů je také chráněný tak, že Webserver požaduje ID uživatelů a hesla, které se mají poslat na webovský server kvůli ověření. Vyzývat podle potřeby uživatele k zadání hesla je standardní funkce prohlížeče.

Obr. 5 ukazuje podrobněji systém z obr. 2. Konfigurační aplet Appletl je vyvolán . administrátorem v rámci správy profilů. Aplet Appletl může implementovat aplikační programové rozhraní 515 (API) pro dotazování informací o jeho pracovním prostředí (např. kontext dotazů, kontext měněné události, dotazování řídícího seznamu přístupů na tento kontext, atd.) kvůli těsnější integraci v rámci správy profilů, ale to není požadavek pro konfigurační aplet. Při jakékoli události potřebuje návrhář apletu appletl rozumět pouze základním metodám API: enablePersistence(), load() a savé(),kromě základních metod objektu java.util.Properties φφφφφφ φ · ·· ·· • φ φ φ φ φφ φφφφ φφφ φ · φφφφ použitých k získávání informací s nastavením do objektu a z objektu java.util.Properties. API 515 navíc poskytuje metody list() a getContext(). Aplet appletl potřebuje pouze registrovat u třídy ProfileManagementProperties a podle potřeby tyto metody volat. Metoda load() může být zavolána k získání současného stavu nastavení pro uživatelský aplet, který je konfigurován v kontextu uživatele nebo skupiny zvolené administrátorem. Administrátor může pak upravit nastavení podle potřeby a uložit je pomocí funkce uložení konfigurace poskytované apletem, který používá metodu save() svého objektu ProfileManagementProperties. Podobně pokud aplet appletl potřebuje seznam uživatelských apletů oprávněných pro přístup uživatelem, může použit metodu list() k získáni seznamu ze serveru. Metoda getContext() může být použita apletem k zobrazení názvu kontextu, ve kterém běží, nebo dokonce k zajištění toho, že běží pouze v jistém kontextu (tj. pokud aplet chtěl nakonfigurovat službu na serveru, který používá exportního agenta, může dovolit běh sama sebe pouze v kontextu AllUsers, protože exportované informace jsou specifické pro server narozdíl od situace, kdy jsou specifické pro uživatele. Aby mohl aplet appletl běžet v rámci správy profilů, vše co se pro aplet požaduje je, registrovat se u ProfileManagementProperties 210 a implementovat třídu ProfileManagementProperties, rozšíření třídy java.util.Properties.

Správce 506 profilů také poskytuje API 516 pro změnu kontextu pro konfigurační aplety. Aplet appletl může implementovat posluchače 512 události změny kontextu. API 516 a posluchač 512 události umožňují administrátorovi měnit kontexty (uživatele nebo skupiny) za běhu konfiguračního apletu, bez nutnosti zastavit a znovu jej spustit. Například při nastavování uživatelského nastavení apletu pravděpodobně ·9

I 9 9 4 » 9 9 I • · 9 99 9

9 9

9 9 administrátor mnohokrát během konfigurace kontexty změní.

registrován jako posluchač 506 profilů jej upozorní

Pokud je konfigurační aplet takovýchto událostí, správce o změně kontextu prostřednictvím API 516. To umožňuje apletu appletl obnovit své nastavení ze serveru pro každý nový kontext. Bez API posluchače událostí by aplet appletl musel být ukončen administrátorem a znovu spuštěn po zvolení nového kontextu kvůli odkázání na existující informace s nastavením pro nový kontext a aby se nemusel zastavovat a znovu spouštět apletem správce profilů. Pro registraci aplet appletl zavolá metodu na ProfileManagementProperties addContextChangeListener (API

Jakmile administrátor nastaví svém objektu s vlastnostmi 510, tj.

516) kvůli své registraci, kontext, nový kontext, provede správce 506 profilů volání nastavení kontextu (API 516) na objekt 510, které zase zavolá metodu reload (API 516) na posluchači 512 událostí. Posluchač 512 událostí nyní provede volání zavedení vlastností na svém objektu s vlastnostmi 510 k získání nových dat s nastavením ze serveru pro nový kontext a způsobí, že aplet appletl aktualizuje GUI a vnitřní proměnné tak, aby zohledňovaly nové informace s nastavením.

Výše uvedené funkce zamezují možnosti, aby síťový administrátor načetl data z jednoho kontextu, změnil kontext a nechtěně jej přepsal pomocí save() jakmile chce provést load() před vytvořením změn v konfiguraci v novém kontextu.

Aplety, které se neregistrují jako posluchači, budou zastaveny, zničeny, znovu zavedeny a znovu spuštěny apletem správce profilů jakmile administrátor vynutí změnu kontextu.

Správa profilů také poskytuje službu export ·· ·· • · « » · * I

vlastností, která umožňuje snadnou dodatečnou montáž existujícího hardwaru a softwaru do tohoto prostředí správy profilů. Služba exportu vlastností umožňuje správci profilů 506 podporovat uživatelské stanice (fyzický hardware) a také uživatele, skupiny a uživatelské aplikace. Protože existující pracovní stanice neví o ProfileManagementProperties 510, umožňuje exportní služba prodejcům pracovních stanic vytvářet konfigurační aplety pracovních stanic, které určí vyvolání exportního agenta 520 na serveru jakmile aplet prodejce uloží své informace s nastavením. Exportní návěští způsobí vytvoření instance prodejcem dodané třídy (objekt exportní agent 520) a vyvolání exportní metody na objektu, aby se určilo, že se má konfigurace pracovní stanice uložit v libovolném vlastním formátu souborů a místa souborů, která jsou vyžadována konfigurovanou pracovní stanicí.

Předpokládejme, že aplet appletl je konfigurační aplet poskytnutý prodejcem pro existující terminál, který je neslučitelný s tímto systémem pro správu profilů. Prodejce také dodává exportního agenta 520. Administrátor může nakonfigurovat terminál na práci v tomto systému spuštěním správce 506 profilů, nastavením kontextu na konfigurovaný terminál, spuštěním prodejcem dodaného konfiguračního apletu appletl a nakonfigurováním tohoto apletu. Jakmile administrátor uloží konfiguraci, část informací, která je přenesena na server, je jednoznačný identifikátor, který označuje konfigurovaný terminál. Typicky to je MAC adresa (řízení přístupu k médiím) terminálu. Serviet 514 správce profilů detekuje, že exportní agent je zadán při uložení. Serviet 514 správce profilů to detekuje z jednoho z uložených nastavení, které určuje potřebu exportního agenta. Nastavení udává exportní návěští ve formě klíčové ·· ···· φ φ Φ· ·Φ ·· · ·· ·« 9 9 9 9

9 9 9 Φ · φ Φ Φ ··· · · ······ ··· · · 9 9 9 9

9 999 999 ·Φ ·· dvojice hodnot

XXXXEXPORT_AGENTXXXX={úplný název třídy exportního agenta}

Metoda export(Context context, config properties) exportního agenta je volána servletem 514 správce profilů k vytvoření jednoho nebo více souborů 522 na serveru z uložených informací s nastavením. Konkrétní soubor nebo soubory jsou identifikovány jedinečným identifikátorem terminálu, který přišel s informacemi o vlastnostech od apletu appletl. Jakmile později terminál zavede systém, použije svůj jednoznačný identifikátor k nalezení a získání svých informací s konfigurací ze souborů 522 na serveru stejným způsobem, jako vždy, nezávisle na systému správy profilů.

Obrázek 6 znázorňuje aplet applet2 běžící na klientském počítači. Aplet applet2 by mohl být koncový uživatelský aplet, jako například textový editor. V každém případě má aplet applet2 přístup k některým ze stejných API metod jak je ukázáno značkou 515 na obr. 5, pokud to potřebuje. Aplet applet2 používá metodu load k získání nastavení a metodu savé k uložení jakéhokoli nastavení, které mohl koncový uživatel změnit. EnablePersistence inicializuje objekt s vlastnostmi správy profilů (Profile Management Properties) pro aplet applet2 kontextem pro uživatele a generuje jedinečný klíč pro identifikaci úložného místa informací s nastavením na serveru jak bylo popsáno výše u administrátora.

Obr. 7 ukazuje situaci uživatele vyvolávajícího svou pracovní plochu. Uživatel na klientovi 700 ukáže ve svém prohlížeči na URL apletu pracovní plochy na serveru a

00

0 0

0 0

0 0 » 0 0 0

00

0000 v kroku

704 pošle zprávu http://server/Desktop.html).

Protože Desktop.html je soubor, který server chrání, výzva je poslána zpět na webovský prohlížeč na klientovi v 706. Webovský prohlížeč na klientovi odpoví vyzváním uživatele k zadání uživatelského ID a hesla. Klient pak pošle uživatelské ID a heslo odesilateli v kroku 7 08. Uživatelské ID a heslo jsou ukázány tučně v kroku 708 na obr. 3, aby se znázornilo, že jsou webovským prohlížečem, jiných místech ke tyto informace poslány samotným Tento typ pojmenování je použit na znázornění stejné věci. Protože pravděpodobně má uživatel oprávnění ke spuštění apletu pracovní plochy, požadavku bude vyhověno.

Probíhá několik interakcí mezi klientem a serverem (není ukázán) kde kód pro aplet pracovní plochy je zaveden desktop na klienta ze serveru. Objekt pracovní plochy je vytvořen a začne se provádět v kroku 712. Objekt pracovní plochy potřebuje své informace s nastavením (tj. konfigurační informace), aby mohl přizpůsobit pracovní plochu pro koncového uživatele, který ji vyvolává. Za tímto účelem jako část procesu inicializace objektu pracovní plochy, vytvoří pracovní plocha objekt ProfileManagementProperties P v kroku 714, který se používá k zavedení, získání, zachycení v mezipaměti, nastavení a uložení kopie informací s nastavením uživatele ze serveru pro aplet pracovní plochy. Objekt pracovní plochy pak provede API volání P.enablePersistence(desktopObject (applet)) v kroku 716, který v kroku 1) 716, inicializuje objekt ProfileManagementProperties P s URL servietu 214 správce profilů. Toto URL je odvozeno od URL apletu pracovní plochy, který byl zaveden předtím ze serveru. Objekt ProfileManagementProperties P pošle požadavek 718 servietu

214 správce profilů k získání kontextu pro uživatele • Β ·»· · » · · I » · · « • · ♦ · spouštějící aplet pracovní plochy. V tom případě se kontext skládá ze dvou komponent, názvu kontextu, což je ID a z typu kontextu, což je v tomto uživatele uživatel.

případě

Serviet správce profilů získá ID uživatele z požadavku 718 a vrátí kontext V kroku 2 ze 716

ProfileManagementProperties je

P uživatele v kroku 719. inicializován objekt s kontextem uživatele spouštějícího pracovní plochu. V kroku 3 ze 716, objekt ProfileManagementProperties P generuje jedinečný klíč pro program pracovní plochy dotázáním objektu javovské pracovní plochy P na jeho úplný název třídy. Všechny javovské objekty znají svůj název třídy. Tento jedinečný klíč je zkombinován s informacemi o kontextu uživatele, aby se zajistil parametr, který určuje jednoznačné umístění v databázi 212 pro uložení informací s nastavením specifickým pro uživatele pro aplet pracovní plochy. Lze použít libovolnou požadovanou metodu k namapování řetězce skládajícího se z úplného názvu třídy a informací o kontextu uživatele na místo uložení dat. Dále je poslán požadavek 720 servietu 214 správce profilů na získání informací s nastavením, přizpůsobeným pro uživatele, pro aplet pracovní plochy. Kontext a klíč jsou poslány jako část požadavku 720 kvůli identifikaci požadovaných informací s nastavením. Serviet 214 správce profilů odpoví požadovanými informacemi s nastavením v kroku 722, které jsou zachyceny v objektu ProfileManagementProperties P 604.

Další popis se týká obr. 8, v kroku 800 objekt pracovní plochy přečte své informace s nastavením ze svého objektu ProfileManagementProperties P a začne podle nich aktualizovat pracovní plochu (tj. mohl by například nastavit barvu obrazovky na modoru, získat informace o pozici ikon, atd.). Objekt pracovní plochy zavolá metodu svého objektu ProfileManagementProperties P kvůli získání seznamu

softwaru, ke kterému má uživatel právo přístupu. Objekt ProfileManagmentProperties P požaduje informace v kroku 802 od servietu 214 správce profilů, který generuje odezvu s požadovanými informacemi v kroku 804. Pro každý takový aplet, ke kterému má uživatel přístup, obsahují informace popisný uživatelský název, URL apletu, URL ikony pro aplet, atd. (informace, které jsou vyžadovány k tomu, aby mohla pracovní plocha zobrazit aplet a zavést a spustit jej) a další volitelné informace, které nejsou pro vynález důležité. Tyto informace jsou uloženy v objektu ProfileManagmentProperties object P a vráceny objektu pracovní plocha. V kroku 806 objekt pracovní plochy použije informace apletu k sestavení složky pro aplety a ke generování okna zobrazujícího ikony a popisný název pro každý aplet, ke kterému má uživatel přístup.

Předpokládejme, že v předchozím spuštění pracovní plochy uživatelem uživatel přetáhl ikony pro nějaké programy zobrazené v právě popsané složce. Je možné, že momentálně již uživatel nemá přístup k apletům, které byly přetaženy ze složky na pracovní plochu. Tyto objekty pracovní plochy by však normálně byly částí uživatelského nastavení, které bylo uloženo během posledního spuštění, a byly by stále zobrazeny na pracovní ploše. Aby se zamezilo této situaci, prozkoumá plocha své nastavení od svého objektu ProfileManagmentProperties P a zjistí aplety, které jsou nastaveny tak, aby se objevovaly vně okna, které je generováno pro zobrazení všech apletů, ke kterým má uživatel přístup. Obr. 8 předpokládá, že se generuje pouze jeden aplet vně okna s aplety. Pokud by existoval více než jeden takový aplet vně okna s aplety, následující procedura by se procházela ve smyčce pro každý takový aplet. V kroku 810 pracovní plocha ověří každý z těchto apletů, který se • · • · · <

• · • · objevuje vně okna s aplety oproti seznamu apletů ze serveru, ke kterým má uživatel přístup. Pokud je aplet v seznamu přítomen, ikona pro aplet je umístěna na plochu v kroku 812 na stejnou pozici jako předtím. Pokud uživatel již nemá k apletů přístup, aplet se odstraní z nastavení plochy v kroku

814 odstraní z objektu

Pokud jsou nějaké aplety

ProfileManagmentProperties P. odstraněny jako část tohoto procesu, sdělí plocha objektu ProfileManagmentProperties P, aby uložil nastavení v kroku 816. Objekt ProfileManagmentProperties P pošle požadavek 818 s nastavením, klíčem a kontextem servietu 214 správce profilů, aby se uložilo nové nastavení do databáze 212. Server pošle odezvu 820 objektu ProfileManagmentProperties P a informuje objekt ProfileManagmentProperties P o tom, že byl požadavek úspěšně dokončen.

Obr. 9 znázorňuje situaci administrátora, který spustí konfigurační aplet ke konfiguraci nastavení pro aplet pro jiné uživatele nebo skupiny uživatelů. Rozumí se, že principy zde popsané se také obecně týkají konfigurace terminálů nebo skupin terminálů. Administrátor na klientovi 900 ukáže ve svém webovském prohlížeči na URL apletů 214 správce profilů na serveru, který se má spustit. URL je posláno na server v kroku 904. Protože ProfileManager.html je soubor, který server chrání, výzva 906 je poslána zpět na webovský prohlížeč na klientovi. Webovský prohlížeč odpoví výzvou administrátora k zadání uživatelského ID a hesla. Požadavek na získání ProfileManager.html je pak zopakován v kroku 908 na server s uživatelským ID a heslem zahrnutými do zprávy. Protože pravděpodobně administrátor má právo spustit správce profilů, požadavku je vyhověno a aplet správce profilů je stažen na terminál administrátora v kroku 910. Existuje

• · •	•	• · · · •	• • ·	• • ·	·· •	«	•	• · *
•	•	•	•	•	•	•	•	4
								•
	•	•	•	•	•	•	•	•
• ·		♦	e · ·	·· ·	·*			• ·

několik interakcí mezi klientem a serverem (nejsou ukázány), kde kód pro aplet správce profilů je zaveden na klienta ze serveru. Objekt správce profilů je vytvořen a začíná se provádět v kroku 912.

Objekt ProfileManagementProperties_nonContextFloating je používán správcem profilů místo normálního objektu ProfileManagementProperties. Chová se stejně jako objekt ProfileManagementProperties s jednou výjimkou: když je nastavení zaváděno a ukládáno, zavádí se a ukládá se do a z kontextu administrátora, který spouší správce profilu, narozdíl od zavádění a ukládání do a z kontextu (tj., uživatele nebo skupiny uživatelů) pro který administrátor konfiguruj e.

Objekt s nastavením přizpůsobit administrátor inicializace profilů správce profilů potřebuje své informace (tj. konfigurační informace), aby mohl správce profilů, protože jej vyvolal

Za tímto účelem jako část procesu objektu správce profilů, vytvoří správce objekt ProfileManagementProperties nonContextFloating P_NCF v kroku 914, který se používá k zavedení, získání, zachycení, nastavení a uložení kopie informací s nastavením administrátora ze serveru pro aplet správce profilů. Objekt správce profilů pak zavolá P_NCF.enablePersistence (profileManagerObject (applet)), která v kroku 1 z 916 inicializuje objekt ProfileManagementProperties nonContextFloating P_NCF s URL servietu 214 správce profilů. Toto URL je odvozeno od URL apletu správce profilů. Objekt

ProfileManagementProperties_nonContextFloating P_NCF pošle požadavek 918 servietu správce profilů 214 k získání názvu kontextu (ID) administrátora a typu kontextu (USER). Serviet

správce profilů získá ID administrátora z požadavku 918. Webovský prohlížeč pošle ID administrátora a heslo ve zprávě spolu s informacemi poslanými objektem

ProfileManagementProperties_nonContextFloating P_NCF. Objekt ProfileManagementProperties_nonContextFloating P_NCF je inicializován s kontextem administrátora, který spustil aplet v kroku 2 z 916. V kroku 3 z 916 objekt ProfileManagementProperties_nonContextFloating P_NCF generuje jedinečný klíč pro aplet správce profilů dotázáním objektu Java profileManagerObject (předaného jako parametr ve volání enablePersistence) na (tj. profileManagerObject.getClass().getName()). jedinečný klíč v kombinaci s informacemi administrátora, je namapován tak, aby určoval jednoznačné umístění v databázi 212 pro informace se specifickým nastavením administrátora pro aplet správce profilů.

jeho úplný název třídy Tento o kontextu

Požadavek 922 je poslán do servietu 214 správce profilů na získání informací o nastavení přizpůsobených pro aplet správce profilů jak byl nastaven pro administrátora. Požadavek 922 obsahuje název příslušného kontextu a údaje o typu a klíč k identifikaci příslušných informací Serviet 214 správce profilů odpoví informacemi s nastavením.

požadovanými zachyceny

924 s nastavením, které jsou v objektu P_NCF. s nastavením

ProfileManagementProperties_nonContextFloating Správce profilů přečte své informace z ProfileManagementProperties_nonContextFloating a aktualizuje se podle toho (tj. například nastaví svou barvu pozadí na modrou).

Běh pokračuje na obr. 10. Správce profilů požaduje informace o existujících uživatelích, skupinách uživatelů • · · · • · · ·· · · ♦ * · · ··· · ♦ · ♦ · · « · · · · ······ ··· · · ···· • · · · · · · · · «· · · a softwaru od servietu 214 správce profilů a sestaví strom na levém panelu okna s nastavením správce profilů v kroku 1002. Příklady levého panelu administrátora viz obr.

až 24. V tomto bodě 1004 administrátor zvolí požadovaný kontext pro konfiguraci klepnutím na uživatele nebo skupinu ze stromu na levém panelu. Správce profilů nastaví kontext pro objekty ProfileManagementProperties zavoláním P_NCF.setContext(zvolený kontext). Viz obr. 15 pro zvolený kontext User groups (skupiny uživatelů) , který označuje skupinu všech uživatelů systému, nebo obr. 18, kde je zvolen kontext skupiny Development, nebo obr. 21, kde je zvolen kontext uživatele colleend. Dále, v kroku 1006 administrátor zvolí aplet, který se má zkonfigurovat, ze seznamu všech apletů na serveru. Příklad zvolení apletu viz obr. 17. V kroku 1008 pak administrátor klepne na tlačítko Spustit/Přizpůsobit a spustí aplet zvolený pro konfiguraci.

Tento aplet by mohl být oddělený konfigurační aplet pro koncový uživatelský aplet, nebo by to mohl být samotný koncový uživatelský aplet. Zvolený aplet je požadovaný a zavedený ze serveru v kroku 1009 a 1011. V kroku 1010 je objekt konfiguračního apletu vytvořen a začne se provádět a generovat svůj objekt ProfileManagementProperties P.

Pokud se předpokládá, že aplet je oddělený konfigurační aplet pro koncový uživatelský aplet, pak v kroku 1012 aplet zavolá p.enablePersistence (ObjektKonfiguračníhoApletu,

ÚplnýNázevTřídyKonfigurovanéhoApletu). Na druhé straně, pokud je aplet uživatelský aplet, spíše nežli oddělený konfigurační aplet, volání by bylo p.enablePersistence (ObjektKoncovéhoUživatelskéhoApletu) protože chce nastavit své vlastní informace s nastavením narozdíl od informací s nastavením pro jiný aplet. Aktuální kontext je již znám objektu ProfileManagementProperties P, protože byl předtím • * · • · ♦ fe ·

* · · • · · nastaven administrátorem prostřednictvím objektu ProfileManagementProperties_nonContextFloating PM_NCF administrátora. Umístění servietu 214 správce profilů bylo předtím generováno jakmile bylo zavoláno enablePersistence na objektu ProfileManagementProperties_nonContextFloating PM_NCF správce profilů. V případě konfiguračního apletu nepotřebuje být jedinečný klíč pro aplet generován, protože je předán konfiguračním apletem objektu ProfileManagementProperties P voláním enablePersistence.

V kroku 1014 se konfigurační aplet registruje u svého objektu ProfileManagementProperties P jako posluchač změny kontextu. Jak bylo popsáno výše, to umožňuje objektu ProfileManagentProperties P apletu upozornit aplet pokud administrátor provede změnu kontextu, aby aplet mohl zavést informace s nastavením pro nový kontext a aktualizovat své grafické uživatelské rozhraní tak, aby zohledňoval nové informace s nastavením, aniž by bylo nutné ukončovat a znovu spouštět aplet v novém kontextu.

Běh pokračuje na obr. 11. V kroku 1104 konfigurační aplet sdělí objektu ProfileManagementProperties P, aby zavedl nastavení z aktuálního kontextu pro konfigurovaný aplet. Požadavek 1105 je poslán servietu 214 správce profilů kvůli získání informací s nastavením, přizpůsobených pro kontext předtím zvolený administrátorem, pro nastavovaný aplet. Požadavek 1105 obsahuje příslušný název kontextu (kontextu, který zvolil administrátor) a typ kontextu (USER, USER_GROUP, nebo ALL_USERS_GROUP, podle a informace o klíči, informací s nastavením.

toho co je které udávají místo Serviet 214 správce nastaveno) příslušných profilů odpoví požadovanými informacemi s nastavením v kroku

1106, které jsou zachyceny v objektu

ProfileManagementProperties P. Konfigurační aplet získá nastavení od objektu ProfileManagementProperties P a aktualizuje podle toho své grafické uživatelské rozhraní.

Administrátor konfiguruje aplet v kroku 1107 a uloží upravené nastavení, například klepnutím na tlačítko SAVÉ poskytnuté apletem. Následkem této operace konfigurační aplet zavolá metodu savé() na svém objektu ProfileManagementProperties P. Objekt ProfileManagementProperties P pošle nastavení a jedinečný klíč pro nastavovaný aplet a informace udávající aktuální kontext servietu 214 správce profilů. Serviet správce profilů uloží informace s nastavením do databáze 212 na místo udané kontextem a klíčem.

Krok 1108 je příklad administrátora, který nyní mění kontext, zatímco konfigurační aplet stále běží. Administrátor zvolí nový kontext klepnutím na uživatele nebo skupinu uživatelů (příklady nových kontextů na levém administračním panelu na obrazovce viz obr. 18) . Následkem změny kontextu pošle správce 506 profilů zprávu o nastavení kontextu objektu ProfileMangementProperties P 510 zavoláním P_NCF.setContext(zvolený NOVÝ kontext), což zase způsobí, že objekt P upozorní posluchače 512 událostí o změně kontextu prostřednictvím nového zavedení pomocí API 515. To nastane v kroku 1110. V kroku 1112, posluchač 512 událostí provede vyvolání load() aby získal nastavení pro nový kontext a objekt P je aktualizován novým nastavením v kroku 1118. Admoinistrátor může nyní pokračovat v úpravě nového nastavení pro nový kontext, pokud je to žádoucí, a uložit je v případě potřeby a pak pokračovat zněmou nového kontextu jak bylo popsáno výše.

9999 99 9999 99 • Φ · · · Φ Φ Φ Φ

ΦΦΦ ΦΦΦ ΦΦΦΦ Φ

ΦΦΦ φφφφ φφ φ

ΦΦ Φ ·Φ ΦΦ ΦΦ ΦΦΦ

Zbývající obrázky 12 až 24 ukazují skutečné snímky obrazovky z pracovní stanice administrátora za běhu částí správce 206 profilů.

Hlavní konfigurační okno 1200 je ukázáno na obrázku 12. Panel 1202 se stromovým uspořádáním v levé straně okna znázorňuje správu 1204 profilů jako jednu z několika služeb dostupných na serveru. Jakmile je tato položka 1204 označena jak je vidět na obr. 12, pravý panel 1205 hlavního okna zobrazuje úvodní zprávu pro tuto službu správu profilů. Rozvínovací a svinovací ikony jako například 1208 se používají k ovládání vzhledu vnořených položek pod položkou v levém panelu, pokud nějaké existují. Znak + v 1208 se nazývá rozvínovací ikona a udává, že pod Správa profilů jsou vnořené položky. Administrátor může zobrazit tyto vnořené položky klepnutím na rozvínovací ikonu 1208, ze které se pak stane svinovací ikona

Obr. 13 znázorňuje rozvinutí položky 1208 Správa profilů na obr. 12, která má za následek zobrazení třech standardních vnořených položek na obr. 13 - Aplety 1300, Skupiny uživatelů 1302 a Uživatelé 1304. Rozvínovací ikony udávají, že tyto položky mohou být také rozvinuty. Aplety 1300 umožňují administrátorovi definovat uživatelské aplety dostupné na serveru 202, User groups 1302 umožňují administrátorovi vytvářet a naplňovat strom skupin uživatelů z obr. 3 a nastavovat nastavení skupin. Uživatelé 1304 umožňují administrátorovi vytvářet nové uživatele a nastavovat jejich nastavení nebo měnit nastavení pro existující uživatele. V příkladě z obr. 13 jsou označeny Aplety 1300. Jakmile se tato položka označí, panel 1305 napravo v okně zobrazí seznam 1306 uživatelských apletů, které byly již v systému definovány. Atributy aplikace,

Změna 4.3.2001

• ·	• · · ·	4» ·	444 ·	• · 4
• · ·	• ·	•	4 4 44
• · ·	• · · 4	4 4 4
• ·	•	• · · ·	4 4 · ·

která je zvolena v kroku 1306, jsou ukázány v kroku 1308. Administrátor definuje nový aplet zvolením <NOVÝ> v kroku 1306 a zadáním názvu a umístění požadovaných v kroku 1308. Existující aplet Průzkumník databáze je zobrazen jako označený v kroku 1306. V kroku 1308 zobrazí pole Název apletu název tohoto apletu. Pole URL (Univerzální lokátor zdroje) zobrazí internetovou nebo intranetovou webovskou adresu tohoto apletu na serveru 202. Pole Úplný název umístění html souboru zobrazuje umístění adrtesáře a název souboru apletu v adresářové struktuře na disku serveru 202. Pole Úplný název třídy zobrazuje úplný název třídy apletu. Pole URL ikony zobrazuje webovskou adresu souboru s obrázkem použitým ke generování ikony pro aplet na plochách uživatelů. Zbývající pole jsou pro nepovinné informace, které mohou být vyžadovány softwarem po vyvolání. Tlačítko 1310, Importovat seznam apletů ze souboru, umožňuje administrátorovi napojit definice apletů k existujícímu seznamu 1306 z existujícího textového souboru. Jakmile se klepne na tlačítko 1310, vyvolá se okno ukázané na obr. 14 a umožní administrátorovi zadat umístění a název textového souboru, který obsahuje definice apletů, které se mají napojit. Uložit všechny nevyřízené změny lze tak, že administrátor klepne na Soubor 1312 a pak Uložit (není ukázáno).

V levém panelu položka 1302 Skupiny uživatelů odpovídá skupině AllUsers z obr. 3 (Skupiny uživatelů a AllUsers se zde používají zaměnitelně). Obr. 15 ukazuje pravý panel administrátorské stanice pokud je označena položka 1302 Skupiny uživatelů. Na obr. 15 je zobrazen panel sešitu, který obsahuje tři karty - kartu 1514 Členové, kartu 1516 Podskupiny a kartu 1518 práva k apletům. Na obr. 15 je zvolena karta se členy. Panel Členové obsahuje seznam 1520

Změna 4.3.2001 ·· φφφφ ΦΦ Φ·Φ· ·· ··' · ·· · ·'♦♦ “ “ · t- ··· ··· » ·

Φ·· ··· ···· • •Φ ···· ·· •· φ ·· ·· ·· · přihlašovacích identifikaci všech členů, kteří byli definováni v systému. Pokud chce administrátor vytvořit nového uživatele (který automaticky získá členství do momentálně zvoleného kontextu skupiny - Skupiny uživatelů), zvolí <NOVÝ> ze seznamu 1520, zadá příslušné informace do vstupních polí 1524 napravo od seznamu a klepne na tlačítko 1522 Vytvořit. Pokud je v seznamu 1520 zvolen existující člen, atributy předtím uložené pro tohoto uživatele jsou zobrazeny v 1524. Tyto atributy obsahují úplný název zvoleného členu, systémové ID člena, heslo a libovolný požadovaný komentář. Atributy, kromě ID, mohou být upravovány a změny potvrzeny (ale ne uloženy) klepnutím na tlačítko Upravit 1525, nebo může být uživatel úplně odstraněn ze systému klepnutím na tlačítko 1526 Odstranit. Libovolnou nevyřízenou změnu odstranit označením položky v seznamu 152Q a klepnutím na tlačítko 1528 Zpět.

Obr. 16 ukazuje pravý administrátorský panel, který je zobrazen jakmile je zvolena karta 1516 Podskupiny. Seznam 1620 podskupin ukazuje existující skupiny, které jsou podskupiny položky označené v levém panelu, což je v tomto případě Skupina uživatelů. Tudíž seznam 1620 zobrazuje všechny bezprostřední podskupiny skupiny AllUsers.

Na levém panelu je rozvinuto User groups. Podskupiny ukázané v seznamu 1620 jsou také rozvinuté položky pod User groups v levém panelu. V seznamu 1620 ukazuje stavové pole aktuální stav každé podskupiny, jako například ! odstranit, ! Upravit a !Vytvořit. Prázdné stavové pole v seznamu 1620 udává, že podskupina existuje a žádné akce nečekají na uložení. Symbol ! udává, že stav je nevyřízený (ještě neuložený). Atributy pro podskupinu zvolenou v seznamu 1620 se objevují v 1622. Tyto atributy obsahují název podskupiny a požadované komentáře o podskupině. Pokud

Změna 4.3.2001 φφ φ'φφφ φφ φφφφ φφ φ φ · « φ . φ φ φ φ • · φ φφφφφφφ φφφ ΦΦΦ· φφφφφ chce administrátor vytvořit novou podskupinu, zvolí <NOVÁ> ze seznamu 1620, zadá název podskupiny a požadovaný komentář v kroku 1622, a klepne na tlačítko 1628 Vytvořit. Položka ! vytvořit <název podskupiny> se pak objeví v seznamu 1620 jako nevyřízená akce. Pokud chce administrátor uložit, všechny nevyřízené změny, klepne na tlačítko Soubor v hlavní nabídce a pak na Uložit (není ukázáno).

Obr. 17 ukazuje pravý panel, který je zobrazen pokud je zvolena karta 1518 Práva k apletu. Seznam 1720 ukazuje všechny názvy všech apletů, které byly definovány pro systém a stav práv (povolit nebo odepřít přístup), která jsou přiřazena ke každému apletu pro skupinu nebo podskupinu (aktuální kontext), která je označena v levém panelu. Jako u jiných karet sešitu, které byly popsány, udává vykřičník, že uvedený stav je změna, která čeká na uložení. Na obr. 17 je ve stromu zobrazeném na levém panelu označena skupina Skupina uživatelů, která odpovídá skupině AllUsers zobrazené na obr. 3. Protože všichni uživatelé systému mají členství ve skupině User groups, seznam 1720 zobrazuje globální výchozí práva pro všechny uživatele systému pro každý aplet definovaný pro systém. Například výchozí stav práv pro aplet Průzkumník databáze je permit (což znamená, že je přístup povolen) pro skupinu AllUsers; podobně standardní stav práv pro všechny uživatele k apletu TFTP je zakázán (přístup je odepřen) . Administrátor může změnit stav práv apletu jeho zvolením v seznamu 1720 a klepnout na tlačítko 1730 Povolit skupinový přístup nebo tlačítko 1732 Odepřít skupinový přístup. Dále bez ohledu na stav práv apletu pro zvolený kontext může administrátor zvolit aplet z 1720 a klepnout na tlačítko 1734 Spustit/Přizpůsobit a spustit tak uživatelský aplet pod zvoleným kontextem. Oblast panlu, která předtím zobrazovala

Změna 4.3.2001

0» 0·00 » ·

0

0« '0

•0 0000 «0 · 0 4 0 » 0

0 4 • 4 0

0

0 0 0 0

0 sešit pro aktuální kontext pak bude obsazena spuštěným uživatelským apletem. Pokud je uživatelský aplet náhodou konfigurační aplet pro jiný software, administrátor může pak uložit programová nastavení (pomocí speciálních funkcí konfiguračních apletů k tomu určených) , která pak budou uložena jako výchozí nastavení softwaru pro zvolený kontext. Pokud je aplet koncový uživatelský aplet, jsou funkce stejné kromě toho, že koncový uživatelský aplet zavede a uloží své vlastní nastavení spíše nežli nastavení pro jiný oddělený programový celek.

Obr. 18 ukazuje úplné rozvinutí stromu podskupiny na administrátorském levém panelu pod User groups. Těsně pod User groups jsou dvě. podskupiny Administrátoři, standardní podskupina, kterou nelze odstranit, a podskupina IBM,' což je podskupina definovaná administrátorem.

Podskupina IBM byla také rozvinuta a obsahuje tři a Software. Podskupina obsahuje alespoň jednu Podskupina Development podskupiny Hardware, Služby

Software byla rozvinuta a podskupinu nazvanou Vývoj, obsahuje alespoň jednu podskupinu nazvanou NCoD. Podskupina NCoD obsahuje množství podskupin, jako například ConfigFW 58, která nemá synovské skupiny. Také v tomto příkladě je ve stromu označena podskupina Vývoj. Protože Vývoj není na vrcholu stromové hierarchie (Skupina All Users), sešit zobrazený na pravém panelu je trochu odlišný od sešitu z obr. 15 kdy bylo označeno Skupiny uživatelů, protože všichni uživatelé nejsou automaticky členové skupiny Vývoj, protože jsou členy Skupiny uživatelů. Seznam 1820 zobrazuje přihlašovací systémová ID všech členů systému. Stav vedle každého uživatelského ID v seznamu 1820 ukazuje, zda uživatel vlastní členství v podskupině Vývoj. Stav

Změna 4.3.2001 • · • 9

5 • 9

999 9999 99

9 9 99 99 99 9 ano udává, že uživatel je členem podskupiny Vývoj, ne udává, že uživatel není členem podskupiny Vývoj a zděděný udává, že uživatel dědí členství ve skupině Vývoj tím, že patří do alespoň jedné z podskupin skupiny Vývoj pod ní ve stromu. Stav členství uživatele pro podskupinu je měněn administrátorem označením uživatele v seznamu 1820 a pak klepnutím na tlačítko 1836 Přidat do skupiny nebo tlačítko 1838 Odstranit ze skupiny. Pokud chce administrátor vytvořit nového uživatele systému nebo upravit nebo odstranit existujícího člena, klepne na tlačítko 1840 Vytvořit/Upravit/Odstranit uživatele. Tato akce vyvolá stránku se sešitem zobrazenou na obr. 19. Pravý panel z obr. 19 je podobný panelu z obr. 15 a umožňuje administrátorovi vytvořit nového uživatele systému zvolením NOVÝ v seznamu 1920 a pak klepnutím na tlačítko Vytvořit. Podobně může administrátor upravit nebo odstranit existujícího uživatele systému zvolením příslušného uživatele v seznamu 1920 a klepnutím na příslušné tlačítko Upravit nebo Odstranit. Uživatelé vytvoření v kontextu libovolné podskupiny (např. Vývoj) nezískají pouze požadované členství ve Skupiny uživatelů, ale stanou se automaticky členy zvolené podskupiny. Změny v seznamu uživatelů systému se uloží klepnutím na Soubor v horní liště nabídky na pravém panelu a pak klepnutím na Uložit (není ukázáno).

Obr. 20 ukazuje přímý způsob jak se dostat k seznamu uživatelů systému pro úpravu, jinak nežli cestou skupiny a podskupiny ukázanou na obr. 19. Na obr. 20 se administrátor dostane tak, že například označí Uživatelé 1304 na levém panelu obr. 13. Pak na pravém panelu zobrazeném na obr. 20, může administrátor vytvářet nové uživatele a upravovat a odstraňovat existující uživatele, jak již bylo popsáno, aniž

Změna 4.3.2001 '99 ···· ·· ···· , 99 · • · 9 9 · · · «99 • 9 « 9 9 . 9 - 9 » 9

9'· · 9 · 9 · · · ·

999 9999 99 9 £ · t 9« 9 9 99 99 9 by byl v kontextu skupiny nebo podskupiny.

Na obr. 21 chce administrátor pracovat přímo s informacemi odpovídajícími uživateli, jehož ID je colleend. To udělá například tak, že rozvine Uživatelé na levém panelu obr. 21 a pak označí colleend, jak je zobrazeno. Pak se objeví pravý panel, který se týká systémových informací o uživateli colleend. Pravý panel obsahuje tři karty. První karta Informace o uživateli je označena implicitně. Na této kartě může administrátor upravit název, ID, heslo a komentář, týkající se uživatele colleend.

Obr. 22 ukazuje pravý panel když uživatel označí druhou kartu Členství ve skupinách. Seznam 2220 ukazuje všechny podskupiny, jichž je colleend členem. Podskupiny jsou zobrazeny v tomto seznamu v pořadí priorit podskupin pro uživatele colleend. Administrátor může změnit prioritu podskupin uživatele colleend označením podskupiny a použitím šipek nahoru a dolů napravo od seznamu 2220 k přesunu označené podskupiny nahoru nebo dolů po seznamu podle potřeby. Pokud administrátor klepne na tlačítko 2242 Přidat/Odstranít členství ve skupinách na obr. 22, pravý panel začne ukazovat obsah obr. 23. Obr. 23 pravý panel umožňuje administrátorovi upravovat podskupiny, jichž je colleend členem. Administrátor to dělá klepnutím na příslušné políčko odpovídající požadované podskupině. Pokud je políčko nezaškrtnuté, (což znamená, že colleend není momentálně členem), pak se zaškrtne a tím se přidá colleend do podskupiny. Naopak, pokud je políčko podskupiny již zaškrtnuté, pak se po klepnutí na políčko políčko vyčistí a colleend se odstraní z podskupiny.

Změna 4.3.2001 • · · · · · ·· ···· ·· • · · · 9 9 9 9 9

9 9 9 9 9 9 9

9 9 9 9 9 9 9 9 .· 0 9 9 9 9 9 9 9

Obr. 24 ukazuje pravý panel když je administrátorem vybrána karta Práva k apletům na obr. 22. Na tomto pravém panelu zobrazuje seznam 2420 všechny aplety, které jsou v systému definovány. Administrátor může povolit přístup uživateli colleend k apletu označením apletu v seznamu 2420 a pak klepnutím na tlačítko 2430 Povolit uživateli přístup; nebo může být přístup uživateli colleend odepřen klapnutím na tlačítko 2432 Odepřít uživateli přístup. Administrátor může také spustit aplet v kontextu uživatele colleend klepnutím na tlačítko 2434 Spustit/Přizpůsobit. Pokud se toto provede, aplet označený v seznamu 2420 se spustí na pravém panelu. Administrátor pak může upravit jakékoli nastavení, které aplet umožňuje a uložit nastavení způsobem poskytovaným apletem. Typický scénář je zde pro administrátora pak spustit konfigurační aplet a vyplnit více polí s nastavením. Pokud však není pro uživatelský aplet zajištěna oddělená konfigurace administrátor může spustit uživatelský aplet v kontextu uživatele a nastavit nastavení z uživatelského apletu. Typický scénář zde je pro administrátora označit kontext skupiny nebo uživatele a pak spustit uživatelský aplet jak bylo popsáno výše. Administrátor může pak typicky upravit nastavení z nabídky možnosti a uložit jej libovolným způsobem, který umožňuje uživatelský aplet. Například typicky je uživatelské nastavení ukládáno při zavření dialogu s možnostmi, nebo může uživatelský aplet poskytovat jiné způsoby ukládání nastavení. V každém případě, protože administrátor spouští v tomto příkladě aplet v kontextu uživatele colleend, nastavení založené administrátorem pomocí uživatelského apletu se uloží na server jako kdyby jej uživatel colleend zadal přímo spuštěním apletu.

Na obrázcích není ukázán scénář, kdy může uživatel

Změna 4.3.2001 upravovat některá nastavení, která se týkají uživatelského apletu. Uživatelský aplet může například umožnit uživateli zvolit barvu pozadí okna nebo písma a velikosti písem, takže každý uživatel si může přizpůsobit aplet do jisté míry, jakmile se aplet spustí na ploše uživatele. V tom případě se uživatelem změněné nastavení uloží stejným způsobem, jako kdyby uživatelský aplet spustil administrátor. Jeden rozdíl však spočívá v tom, že administrátor může spouštět uživatelské aplety ke změně nastavení v kontextech skupin, zatímco uživatelé mohou ovlivňovat pouze nastavení svých individuálních kontextů.

Zastupuje:

Dr. Petr Kalenský v.r.

: LAuAA iílr,ΆΆ’ KAi , '' ' n

A ΡΑΑΪΝΕΑΠ i?ií ún Prah;! , Hálkova 2 psKic] i^pnhlHíří

Změna 4.3.2001

dofl

Claims (3)

1. PATENTOVÉ NÁROKY

   JUDr. Petr Kalenský advokát

   120 00 Praha 2, Hálkova 2

   1. Pro použití v síťovém systému obsahující síť propojující server a množství uživatelských stanic, kde server ukládá množství uživatelských aplikací pro stahování na uživatelské stanice, způsob správy nastavení uživatelské konfigurace pro aplikace běžící na uživatelské stanici, přičemž způsob se vyznačuje tím, že obsahuje kroky:

   reprezentování všech uživatelů systému ve stromové hierarchii skládající se z uzlu skupiny AllUsers, která obsahuje všechny uživatele systému, a množství synovských uzlů skupin, přičemž každý obsahuje označené z uživatelů, které patří do skupiny reprezentované uzlem synovské skupiny, přičemž každý uzel obsahuje nastavení konfigurace pro zvolené z aplikací dostupných v systému;

   přiřazení pořadí priorit skupin pro každého uživatele, který je členem více než jedné skupiny;

   vzhledem k libovolnému uživateli požadování spuštění zvolené aplikace, určení pořadí priorit skupin pro uživatele; a sestavení skupiny nastavení konfigurace ze stromu určením první skupiny ze seznamu priorit skupin, ze které lze odvodit skupinu nastavení pro zvolenou aplikaci;

   sloučením nastavení do skupiny pro zvolenou aplikaci procházením stromu od uzlu skupiny AllUsers do první skupiny;

   sloučením nastavení zadaných na každém uzlu pro zvolenou aplikaci; a úpravou sloučeného nastavení při průchodu každého uzlu nastavením určeným na tomto uzlu pro zvolenou

   27 80 754 aplikaci .
2. 2. Pro použití v síťovém systému, obsahujícím síť, propojující server a množství uživatelských stanic, kde server ukládá množství uživatelských aplikací pro stahování na uživatelské stanice, zařízení pro správu nastavení uživatelské konfigurace pro aplikace běžící na uživatelské stanici, přičemž zařízení se vyznačuje tím, že obsahuj e:

   prostředky pro reprezentování všech uživatelů systému ve stromové hierarchii skládající se z uzlu skupiny AllUsers, který obsahuje všechny uživatele systému, a množství synovských skupinových uzlů, přičemž každý obsahuje zvolené z uživatelů, které patří do skupiny reprezentované uzlem synovské skupiny, přičemž každý uzel obsahuje nastavení konfigurace pro zvolené z aplikací dostupných v systému;

   prostředky pro přiřazení pořadí priorit skupin pro každého uživatele, který je členem více než jedné skupiny;

   vzhledem k libovolnému danému uživateli požadujícímu spuštění zvolené aplikace, prostředky pro určení pořadí priorit skupin pro uživatele; a prostředky pro sestavení skupiny nastavení konfigurace ze stromu určením první skupiny ze seznamu priorit skupin, ze kterého může být skupina nastavení odvozena pro zvolenou aplikaci;

   sloučením nastavení do skupiny pro zvolenou aplikaci procházením stromu od skupinového uzlu AllUsers k první skupině;

   sloučením nastavení určeného v každém uzlu pro zvolenou aplikaci; a ·« ··

   I · · · » · · * k 9 9. · • · ♦ · úpravou sloučeného nastavení při průchodu jednotlivými uzly nastavením určeným na tomto uzlu pro zvolenou aplikaci.

   AllUsers množství
3. 3. Počítačový programový produkt uložený na počítačem čitelném úložném médiu pro, jakmile je spuštěn na počítači, provádění v síťovém systému obsahujícím síť propojující server a množství uživatelských stanic, kde server ukládá množství uživatelských aplikací pro stažení na uživatelské stanice, způsob správy nastavení uživatelské konfigurace pro aplikace běžící na uživatelské stanici, přičemž způsob se vyznačuje tím, že obsahuje kroky:

   reprezentování všech uživatelů systému ve stromové hierarchii skládající se ze skupinového uzlu obsahujícího všechny systémové uživatele a synovských skupinových uzlů, přičemž každý obsahuje zvolené z uživatelů, které patří do skupiny reprezentované uzlem synovské skupiny, přičemž každý uzel obsahuje nastavení konfigurace pro zvolené z aplikací dostupných v systému;

   přiřazení pořadí priorit skupin pro každého uživatele, který je členem více než jedné skupiny;

   vzhledem k libovolnému danému uživateli požadujícímu spuštění zvolené aplikace, určení pořadí priorit skupin pro uživatele; a sestavení skupiny nastavení konfigurace ze stromu určením první skupiny ze seznamu priorit skupin, ze kterého může být skupina nastavení odvozena pro zvolenou aplikaci;

   sloučením nastavení do aplikaci procházením stromu AllUsers k první skupině;

   sloučením nastavení určeného na každém uzlu pro zvolenou aplikaci; a skupiny pro zvolenou od skupinového uzlu úpravou sloučeného nastavení při průchodu jednotlivými uzly nastavením určeným v daném uzlu pro zvolenou aplikaci.