Управління додатками IBM Workplace Managed Client, HTML, XML, DHTML, Інтернет-технології, статті

IBM Workplace Managed Client (перш IBM Workplace Client Technology, rich edition) надає альтернативу виконанню Web-додатків IBM Workplace на сервері. Workplace Managed Client підтримує виконання додатків на стороні клієнта, щоб поліпшити продуктивність і функціональність роботи користувача, а також його здатність працювати автономно.


Як випливає з назви, однією з ключових функціональних можливостей Workplace Managed Client є централізоване управління. Адміністратор може на дуже детальному рівні керувати доступом до всіх програм з сервера. Користувачі клієнтських додатків можуть звертатися тільки до додатків, які їм дозволено використовувати. У цій статті ми розглянемо теорію і практику управління доступом в Workplace Managed Client.

Передбачається, що читачі мають досвід адміністрування IBM WebSphere Portal, знайомі з XMLAccess і розуміють основні концепції Workplace Managed Client.


IBM Workplace Managed Client Developer Toolkit


Перед початком роботи витратимо небагато часу на розгляд IBM Workplace Managed Client Developer Toolkit. Це набір інструментальних програм, заснований на Eclipse, який підтримує розробку додатків Workplace Managed Client. Він працює як з Eclipse, так і з IBM Rational Application Developer. Він значно спрощує процес створення додатків Workplace Managed Client. Ви можете протестувати і налагодити ваше клієнтське додаток локально, без сервера. Ви можете також згенерувати “deploy set” (“набір для розгортання”) так, щоб уникнути виснажливої ​​роботи.


IBM Workplace Managed Client Developer Toolkit був розроблений в IBM Dublin Software Lab. Ми використовуємо цей набір інструментальних засобів як стандартну середовище розробки в цій статті.


Приклад програми Workplace Managed Client


Workplace Managed Client має дуже деталізовану систему управління доступом. Він може керувати доступом окремого користувача або групи користувачів до конкретної функції певної програми. Для продовження роботи ви повинні бути знайомі з керуванням доступом в IBM WebSphere Portal.


Тепер давайте розглянемо приклад з реального світу. Припустимо, що у нас є океанська система IBM Workplace Collaboration Services, яка використовується моряками повсюдно. Двома звичайними користувачами цієї системи є Silver Blade (член користувальницької групи Pirate) і Marco Polo (член користувальницької групи Adventurer). Обидва сильно покладаються на Workplace Collaboration Services для досягнення успіху у своїй кар’єрі. На жаль, мобільні мережі на їх кораблях не дуже хороші, і в результаті вони іноді бачать помилку Page Not Found (сторінка не знайдена), лякаючу кожного мореплавця. Щоб її уникнути, Marco і Silver вирішили встановити Workplace Managed Client для використання їх можливостей автономної роботи. На малюнку 1 показаний знімок екрана Workplace Managed Client користувача Marco.


Рисунок 1. Workplace Managed Client користувача Marco Polo
Workplace Managed Client користувача Marco Polo

А на малюнку 2 показаний Workplace Managed Client користувача Silver Blade.


Рисунок 2. Workplace Managed Client користувача Silver Blade
Workplace Managed Client користувача Silver Blade

Вертикальна область в лівій частині інтерфейсу Managed Client представляє собою область перемикання. Кожна піктограма в ній представляє додаток, що працює на Workplace Managed Client. Як ви можете бачити, Marco і Silver мають доступ до Navigate, Logbook, Weather Forecast і Sea Battle. Ми також можемо бачити на малюнку 1, що Marco має винятковий доступ до Adventure Club, тоді як на малюнку 2 показано, що Silver може використовувати Pirate Club для контакту зі своїми друзями-піратами.


Їх привілеї для використання додатків Workplace Managed Client визначаються адміністратором, що використовують управління доступом. Як очікується, ці привілеї узгоджуються з привілеями, використовуваними ними при роботі з браузерами для доступу до додатків Workplace Collaboration Services на сервері Workplace Server. Це дозволяє користувачам використовувати такі самі функції, які вони можуть використовувати через Web-браузер.


Зверніть увагу на те, що на малюнках 1 і 2 та Marco, і Silver вибрали додаток Sea Battle. Проте інтерфейс Marco для Sea Battle відмінний від інтерфейсу Silver. Marco і Silver мають функцію Battle Field Commands, але тільки Marco може використовувати функцію Flee, і тільки Silver має функцію Rob (яка, мабуть, є його коханої). Що цікаво, ці відмінності в коді не реалізуються. Замість цього вони регулюються функцією управління доступом в Workplace Managed Client. Це означає, що розробники мають займатися тільки функціями додатків Workplace Managed Client і залишити контроль доступу адміністраторам. Адміністратори можуть потім вирішити, як надати доступ користувача до додатка Workplace Managed Client. Вони можуть навіть управляти доступом користувача до субфункціям всередині програми. І все це – не змінюючи жодного рядка коду! Дана функціональна можливість звільняє програміста від контролю захисту, поліпшує можливість повторного використання і керованість додатків Workplace Managed Client, роблячи їх більш придатними для використання на великих підприємствах.


У наступному розділі пояснюється робота контролю доступу в Workplace Managed Client.


Контроль доступу в Workplace Managed Client


Workplace Managed Client реалізує деталізований контроль доступу, використовуючи механізм контролю доступу сервера IBM Workplace. Якщо говорити більш конкретно, то Workplace Managed Client для управління своїми додатками використовує настройки контролю доступу для сторінки і портлетів на сервері Workplace.


Кожна програма Workplace Managed Client представляє собою сторінку на сервері Workplace, і схема програми представляється як схема портлетів на сторінці. Кожен вид в додатках Workplace Managed Client може відображатися в портлет на сторінці. Цей портлет повинен забезпечувати таку ж функціональність, що і вид. Тобто, ми маємо програму, що працює і на сервері, і на клієнті.


У нашому прикладі Sea Battle ми використовували портлет “placeholder”. Цей портлет встановлюється на сервері Workplace за замовчуванням. Він тільки генерує RCPML для Workplace Managed Client, тому наш клієнт буде працювати тільки в Managed Client. Однак цього має бути достатньо, для того щоб продемонструвати, як працює управління доступом в Workplace Managed Client.


RCPML (Rich Client Platform Markup Language) – це XML-мова розмітки, що описує схему кожного додатка Workplace Managed Client. Workplace Managed Client використовує RCPML-файл для створення своїх додатків. RCPML, при необхідності, передається з сервера Workplace Collaboration Services.


На малюнку 3 показано, як сторінки, що становлять наші програми Workplace, відображаються в користувальницький інтерфейс Workplace Managed Client користувача Marco. Ми можемо побачити, що кожна сторінка представляє додаток в Workplace Managed Client, за винятком Pirate Club. Ця програма має бути доступне тільки користувачеві із групи Pirate Club. Marco не є членом такої групи, тому він не може бачити його у своєму клієнтові.


Рисунок 3. Відображення сторінки користувача інтерфейсу (сторінка-UI)
Відображення сторінки користувача інтерфейсу (сторінка-UI)

На малюнку 4 показано, як схема сторінки програми Sea Battle відображається в користувальницький інтерфейс програми Sea Battle (Silver).


Рисунок 4. Сторінка-UI відображення програми Sea Battle

Як ви можете помітити, кожен портлет на сторінці Sea Battle відображається в вид програми, але другий портлет пропущений. Причиною цього є те, що користувач повинен бути членом Adventurer Club для використання функції Flee. Silver таким членом не є, тому не може використовувати цей вид. Pirate Club і Adventurer Club – це дві групи користувачів, які ми повинні створити для цього прикладу. Як ви можете побачити, у нас є також два користувача: Silver_Blade, член Pirate Club, і Marco_Polo, член Adventurer Club.


Для пояснення того, як ці відображення пов’язані з контролем доступу в Workplace Managed Client, ми повинні почати з процесу генерування RCPML. Коли клієнт з’єднується з сервером, сервер формує сторінку і генерує RCPML-файл з отриманої сторінки. Потім сервер передає RCPML клієнту, і клієнт формує додаток, слідуючи RCPML.


Ключ знаходиться на першому кроці: коли сервер Workplace формує сторінку, він перевіряє привілеї ініціатора запиту. На одержуваної сторінці можуть знаходитися тільки ті сторінки і притулити, до яких у ініціатора запиту є доступ. Отримана сторінка є джерелом RCPML, тому привілеї клієнта визначають, що буде в RCPML. Отже, вони визначають, який додаток або функція доступні. Керуючи доступом клієнта до наданої сторінці і портлет на сторінці, адміністратори можуть отримати повний контроль над додатками Workplace Managed Client та їх функціями.


Тепер, коли ми знаємо теорію, перейдемо до практики. Ми налаштуємо додаток Sea Battle в покроковому режимі. Перш за все, ми повинні встановити приклад програми.


Установка прикладу програми


Ми будемо встановлювати приклад програми Sea Battle. Він містить деревовидні види і кілька кнопок на кожному з них. Ви можете використовувати IBM Workplace Managed Client Developer Toolkit для їх створення, не написавши жодного рядка коду. Ви можете також використовувати цей набір інструментальних засобів, щоб згенерувати набір для розгортання, що містить всі необхідні файли для розгортання програми на сервері. Ви здивуєтеся, наскільки легко можна створити і розгорнути додаток Workplace Managed Client за допомогою цього фантастичного набору інструментальних засобів. Звичайно, завжди існує кращий спосіб. У нашому випадку набагато більш простим способом є завантаження набору для розгортання. Для завантаження набору для розгортання зверніться до розділу Завантаження, розташованому в кінці цієї статті.


Дотримуючись наведених у файлі інструкцій, розгорнути приклад додатки не важко.


Після успішного розгортання ви готові йти далі. Використовуючи для запуску клієнта обліковий запис адміністратора, ви повинні побачити виконання програми Sea Battle з трьома видами. Однак якщо ви використовуєте обліковий запис, відмінну від адміністраторській, ви побачите тільки піктограму Sea Battle в області перемикання. Але якщо ви натиснете на цю піктограму, програма не запуститься правильно. Не турбуйтеся, це не ваша вина!


Проблема з обліковим записом, відмінній від адміністраторській, полягає в контролі доступу. Нова згенерувала сторінка доступна за замовчуванням для всіх аутентіфіцированний користувачів порталу. Але портлет-заповнювачі на цій сторінці за замовчуванням доступні тільки для групи користувачів wpsadmins. Це означає, що вони можуть використовувати додаток без будь-яких проблем, оскільки адміністратор може отримати все RCPML-файли. Т.к. портлет, генеруючі RCPML для схеми сторінки, відсутні, користувачі не адміністратори можуть бачити тільки піктограму в області перемикання, а додаток працювати не буде. Для вирішення проблеми ви повинні надати користувачеві доступ до портлет-заповнювачів на згенерованої сторінці.


У наступному розділі ми виправимо цю проблему і налаштуємо приклад програми в покроковому режимі.


Установка контролю доступу для програми Workplace Managed Client


У попередньому розділі ми розгорнули Sea Battle на сервері. Тепер ми встановимо контроль доступу для цього прикладу, для того щоб він працював так, як описано в попередньому розділі “Контроль доступу в Workplace Managed Client”.


Зареєструйтеся на сервері Workplace у вашому Web-браузері, використовуючи обліковий запис адміністратора, і знайдіть портлет, чиї назви починаються з “sea_battle”. Ви повинні знайти три портлет: sea_battle.AdventurerView, sea_battle.CommonView і sea_battle.PirateView (див. малюнок 5).


Рисунок 5. Портлет Sea Battle
Портлет Sea Battle


Перший портлет відображається в вид Flee. Мандрівники (adventurer) повинні рятуватися втечею (flee) в певних обставинах, тому додайте Adventurer Club в роль User. Це означає, що Marco може побачити вид Flee в своєму додатку Sea Battle, в той час як Silver не може. Ми можемо також досягти цього, додавши користувача Marco_Polo в роль user. Але в цьому випадку, якщо у вас є інші мандрівники, які теж повинні використовувати цю функцію, вам потрібно додавати їх в роль user по одному. Рекомендується використовувати групу користувачів для управління доступом до додатків Workplace Managed Client.


Другий портлет представляє вид Battle Fields Commands. І пірати, і мандрівники можуть його використовувати, тому ми повинні додати групи користувачів Pirate Club і Adventurer Club в роль User. Це дозволить всім користувачам цієї групи використовувати функції цього виду. Зверніть увагу на те, що члени різних ролей мають різні рівні доступу до ресурсів. В нашому прикладі, це не має ніякого значення, тому ми використовуємо роль user.


Останній портлет відображається в вид Rob. Ми повинні додати Pirates Club в його роль user на тій же основі.


Тепер додаток Sea Battle повинно працювати нормально з користувачами Macro_Polo і Silver_Blade. Але є ще одна річ, яку ми повинні зробити. Надана для програми сторінка доступна для всіх аутентіфіцированний користувачів порталу. Ви можете знайти сторінку в WorkplaceRCPPages; вона має заголовок, аналогічний “sea_batttle”, і унікальне ім’я, що починається з “com.ibm.page …”. Вона за замовчуванням успадковує настройки доступу від її батьківської сторінки. Це означає, що всі аутентифіковані користувачі будуть бачити піктограму для Sea Battle в їх області перемикання, але тільки користувачі з груп Adventurer Club і Pirate Club можуть використовувати їх коректно. Ми хочемо показувати піктограму тільки тим користувачам, які можуть використовувати додаток. Тому нам треба заборонити спадкування установок доступу батьківського сторінки даної сторінкою. Або ми можемо заборонити розповсюдження налаштувань доступу батьківського сторінки. Таким чином, наступні сторінки-спадкоємці більше не будуть успадковувати налаштування доступу. Нарешті, ми додаємо Adventurer Club і Pirates Club в роль user сторінки. Це дозволить тільки піратам і мандрівникам бачити піктограми і користуватися цією програмою.


Ви можете виконати всі ці настройки і через ваш Web-браузер. Але ми розглядаємо управління додатками Workplace Managed Client, тому не будемо заглиблюватися в деталі, як це зробити. Інтерфейс Web-браузера досить дружній і інтуїтивний. Однак якщо ви зіткнулися з певними проблемами, перевірте, чи правильно розгорнуто додаток на сервері за допомогою Workplace Managed Client.


Ми можемо також використовувати XMLAccess-можливості в IBM WebSphere Portal з метою налаштування контролю доступу для додатків Workplace Managed Client. Ми надамо деякі XMLAccess-сценарії, разом з невеликими поясненнями, в наступному розділі.


Використання XMLAccess для настройки контролю доступу


Можливо, ви помітили, наскільки зручно використовувати XMLAccess для роботи з сервером Workplace, коли ми встановлювали приклад програми. Доброю новиною є те, що ми теж можемо використовувати XMLAccess при налаштуванні параметрів доступу для додатків Workplace Managed Client.


Перед початком роботи завантажте два сценарії (addUser.xml і delUser.xml), посилання на які наведені в розділі Download в кінці статті, для створення і видалення двох груп користувачів і двох користувачів, з якими ми будемо працювати. Зверніть увагу на те, що пароль записаний в звичайному текстовому вигляді; завжди хорошою практикою є зміна пароля після створення користувача з використанням XMLAccess.


Далі наведено сценарій, який правильно налаштує наш приклад програми Workplace Managed Client після розгортання. У ньому передбачається, що ми використовуємо портлет-заповнювач за замовчуванням, і що унікальні імена для сторінки і імена для портлетів не були змінені:






xml version = “1.0” encoding = “UTF-8″ ?>
< request
xmlns:xsi = ” http://www.w3.org/2001/XMLSchema-instance”
xsi:noNamespaceSchemaLocation= “PortalConfig_1.2.xsd”
type = “update” >

< portal action = “locate” >
< web-app action = “locate” uid =
“com.ibm.rcp.PlaceHolderPortlet.f04cbd43761200181a76918a71b1e264” >
< portlet-app action = “locate” name =
” sea_battle.pane1.views.Pane1View ” >
< portlet action = “update” active = “true” name = ”
sea_battle.pane1.views.Pane1View.1 ” >
< access-control >
< role actionset = “User” update = “set” >
< mapping subjectid = ” Adventurer Club ” subjecttype = “USER_GROUP”
update = “set” />
< mapping subjectid = ” Pirate Club ” subjecttype = “USER_GROUP”
update = “set” />
role >
access-control >
portlet >
portlet-app >
< portlet-app action = “locate” name =
” sea_battle.pane2.views.Pane2View ” >
< portlet action = “update” active = “true” name =
” sea_battle.pane2.views.Pane2View.1 ” >
< access-control >
< role actionset = “User” update = “set” >
< mapping subjectid = ” Adventurer Club ” subjecttype = “USER_GROUP”
update = “set” />
role >
access-control >
portlet >
portlet-app >
< portlet-app action = “locate” name =
” sea_battle.pane3.views.Pane3View ” >
< portlet action = “update” active = “true”
name = ” sea_battle.pane3.views.Pane3View.1 ” >
< access-control >
< role actionset = “User” update = “set” >
< mapping subjectid = ” Pirate Club ” subjecttype = “USER_GROUP”
update = “set” />
role >
access-control >
portlet >
portlet-app >
web-app >
< content-node action = “update” uniquename =
” com.ibm.page.6c6359e0c3c53dd830b930b9105395878888000 ” >
< access-control >

< role-block type = “inheritance” actionset = “Editor” />
< role actionset = “User” update = “set” >
< mapping subjectid = ” Pirate Club ” subjecttype = “USER_GROUP”
update = “set” />
< mapping subjectid = ” Adventurer Club ” subjecttype = “USER_GROUP”
update = “set” />
role >
access-control >
content-node >
portal >
request >


Якщо ви використовували XMLAccess раніше, то знайдете цей сценарій досить зрозумілим. У ньому присутні три елементи, вони відображаються на три портлет-заповнювача. Портлет ідентифікуються за їх іменами. Ви можете знайти їх імена в сценарії розгортання, який використовували для розгортання програми; вони починаються з імені вашого застосування. Кожен елемент визначає список членів ролі. Кожен елемент видаляє або додає користувача до списку. Атрибут subjectid є ім’ям користувача або ім’ям групи користувачів. subjecttype – може бути USER або USER_GROUP; атрибут update встановлений в “set”, якщо ви хочете додати або видалити користувача зі списку. Ви можете мати стільки елементів, скільки забажаєте.


Ми налаштовуємо сторінку в елементі. Сторінка ідентифікується за унікальним імені. Також можна знайти унікальне ім’я в сценарії розгортання. Як уже згадувалося, за замовчуванням сторінка успадковує контроль доступу, тому нам потрібно спочатку заборонити спадкоємство. Потім ми додаємо Pirate Club і Adventurer Club в роль user, як раніше.


Одним реченням: сценарій просто знаходить портлет і сторінки, а потім оновлює контроль доступу. Ви можете використовувати цей сценарій як шаблон для створення вашого власного. Вам просто потрібно змінити атрибути, виділені жирним шрифтом, налаштувавши їх під ваші вимоги.


Висновок


У даній статті ми розглянули переваги системи контролю доступу Workplace Managed Client. Ми пояснили, як вона працює, використовуючи механізм контролю доступу сервера Workplace Collaboration Services, і розповіли, як налаштувати контроль доступу для додатків Workplace Managed Client. Тепер ви можете оцінити значення набору інструментальних засобів Workplace Managed Client!


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*