Enterprise Application Server: новий підхід до побудови корпоративних інформаційних систем, Комерція, Різне, статті

Інтернет і розвиток глобальних гетерогенних мереж породили принципово нові можливості для ведення бізнесу і виживання у конкурентній боротьбі. Ера електронної комерції зажадала істотних технічних змін в моделях побудови інформаційних систем. Перехід на трирівневу архітектуру став необхідною умовою реалізації сучасних програмних рішень. Багаторічний досвід роботи корпорації Sybase в цьому напрямку вилився у створення лінійки продуктів, центральним серед яких є Enterprise Application Server (EAS).


Черговий виток комп’ютерної революції, що об’єднав в єдині глобальні мережі комп’ютери споживачів та бізнес-партнерів, поставив керівників підприємств перед фактом зміни роль інформаційних систем (ІС) у веденні бізнесу. Якщо раніше інформаційні технології грали хоча й істотну, але все ж другорядну роль у бізнес-структурі підприємства, то тепер вони стають одним з найважливіших інструментів для ведення бізнесу і вирішальним фактором, що визначає перемогу в конкурентній боротьбі за ринок.


Сьогодні інформаційна система підприємства стає невід’ємною частиною взаємодії з клієнтом і надаваних йому послуг (В2С системи) або визначає рівень кооперації з бізнес-партнерами (В2В системи). При цьому рівень розвитку ІС безпосередньо впливає на фінансові результати компанії. Відповідність ІС сучасним вимогам бізнесу багато в чому визначає відповідність самого підприємства рівню розвитку ринку, що фактично є питанням економічного життя або смерті.


До цього моменту серед концепцій побудови ІС превалювала технологія клієнт-сервер. Заснована на використанні мови структурованих запитів (SQL) для зв’язку клієнтського і серверного ПЗ, ця технологія дозволяє формалізувати структуру оброблюваних даних і відокремити їх від зовнішнього інтерфейсу ІС. Використання лінійки серверних продуктів від провідних виробників, що підтримують кілька комп’ютерних платформ, дозволяє при використанні технологією клієнт-сервер (дворівневої моделі ІС) досягнути ще й масштабованості розроблюваного ПЗ.


У міру зростання вимог до збільшення продуктивності виконання бізнес-транзакцій та зменшення витрат на супровід ІС (яке у першу чергу в забезпеченні прозорості реалізованої в ІС бізнес-логіки) виробники ПО прийшли до необхідності перенести акценти в реалізації бізнес-процесів з клієнтського місця на сервер обробки даних. Це проявилося в подальшій еволюції серверів БД і мови SQL. Структура БД була доповнена присутністю збережених процедур (stored procedure), здатних реалізовувати частину бізнес-логіки й гарантувати виконання операції в рамках єдиної бізнес-транзакції.

Рис.1 Дворівнева модель побудови інформаційних систем


Намагаючись залишитися в рамках старої дворівневої моделі побудови ІС, виробники ПЗ стали нарощувати можливості збережених процедур в мові SQL, що дозволило частково розвантажити клієнтський комп’ютер. Але при цьому була загублена сумісність між серверами БД різних виробників, і не задовольнялися вимоги мережі Інтернет до “полегшення” клієнтського ПЗ. Сама поява концепції тонкого клієнта, пов’язаної з наданням послуг через інтернет-інтранет мережі, зробило актуальним повний перехід на трирівневу модель побудови ПЗ, в якій вже вся бізнес-логіка виконується на окремому виділеному сервері.


Трирівнева модель побудови ІС увазі наявність крім сервера БД також виділеного сервера додатків, що інкапсулює в собі основну частину бізнес-логіки системи. В залежності від наданої сервером додатків функціональності виконання бізнес-логіки може бути розділене між сервером додатків і функціонально навантаженим клієнтським ПЗ (“товстим” клієнтом), або повністю покладено на сервер додатків в схемі роботи з “тонким” клієнтом, що здійснюють доступ до ресурсів системи (у тому числі бізнес-логікою) за допомогою інтернет-або інтранет-мереж.


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


Нижче ми постараємося перерахувати основні вимоги до такого серверу додатків, які випливають з умов ведення сучасного бізнесу, і без вирішення яких на поточний момент неможливо створити конкурентоспроможну ІС підприємства, що відповідає вимогам ринку.


Скорочення часу розробки ІС



В сучасних умовах типової комерційний інформаційний проект має реалізовуватися максимум за 2-3 місяці. Звідси випливає необхідність повторного використання наявних в компанії наробітків, а також вимога універсальності і сумісності сервера додатків з використовуваними програмними модулями. Необхідні підтримка програмних комплексів для швидкої розробки систем (RAD технології), а також комплекс заходів, радикально прискорюють процес запуску створеного бізнес-модуля в складі працюючого сервера додатків.


Зменшення витрат на супровід системи та послідовне нарощування її функціональності



Часто вартість супроводу та підтримки вже створених систем сильно перевищує первісну вартість ІС. Тому правильна початкова стратегія проектування системи повинна скоротити наступні витрати. Підтримка сучасних корпоративних стандартів як на етапі розробки модулів сервера додатків (наприклад, Java технології), так і на етапі їх функціонування в рамках працюючої ІС (стандарт CORBA та інші) дозволяє використовувати готові напрацювання третіх фірм, а також скоротити витрати на підтримку і розвиток системи в цілому. Використання об’єктно-орієнтованого підходу вже на рівні організації бізнес-процесів полегшує документування системи та її подальший розвиток.


Забезпечення єдиного транзакційного контексту при роботі з кількома БД



Успадковане багатство існуючих програмних рішень всередині підприємства і накопичених раніше даних роблять вельми актуальною задачу інтеграції інформаційних ресурсів і, зокрема, можливість роботи з декількома серверами БД в єдиному транзакційному контексті. Це ж вимога все частіше висувається через накладення на структуру ІС внутрішньої організації компанії та особливостей ведення бізнесу. Тому підтримка цілісності даних в рамках виконання бізнес-транзакції одночасно на декількох серверах БД – одне з найважливіших вимог до великої інформаційній системі підприємства.


Масштабованість ІС



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


Побудова відмовостійких програмних комплексів



Мережа Інтернет багаторазово збільшила негативний ефект від виходу з ладу комп’ютерних систем. А використання ІВ як інструмента ведення бізнесу тягне за собою реальні фінансові втрати у випадку збоїв роботи системи. Застосування механізмів дублювання або кластеризації укупі з централізованим управлінням концепцією відмовостійкості повинні забезпечити проведення бізнес-транзакцій навіть при виході з ладу частини ІС.


Підтримка розвинених засобів захисту інформації


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


Enterprise Application Server (EAS)


Використовуючи свій багаторічний досвід в області побудови дворівневих і трирівневих систем, корпорація Sybase випустила на ринок продукт EAS, який відповідає всім перерахованим вище вимогам. Він призначений для встановлення і використання в якості сервера додатків підприємства та інтеграції в нього специфічних бізнес-модулів. Ядром EAS є програмний продукт, який реалізує функціональність сервера додатків – Jaguar CTS (Component Transaction Server), який являє собою середу запуску і виконання бізнес-модулів підприємства з підтримкою їх відмовостійкості і контролем за виконанням операцій з БД. Сервер додатків забезпечує організацію сеансу зв’язку з клієнтським ПЗ, під час якої клієнтські запити керують проведенням бізнес-операцій на сервері.

Рис.2 Загальна схема роботи сервера додатків


В якості одиниці програмного коду, що надається клієнту на сервері для виконання бізнес-транзакцій, використовуються компоненти. У термінології сервера додатків поняття компонента відіграє таку ж роль, як і поняття класу в об’єктно-орієнтованих мовах програмування. Кожен компонент, встановлений на Jaguar сервері, має набір підтримуваних об’єктних інтерфейсів. При запиті від клієнтського ПО сервер ініціалізує в пам’яті свого комп’ютера примірник компонента. Надалі клієнтське ПО викликає методи підтримуваного інтерфейсу, використовуючи протокол зв’язку з сервером додатків. Надані в комплекті з сервером Jaguar бібліотеки зазвичай дозволяють самому клієнтського додатку не помічати особливостей виклику серверного компонента. Робота ведеться так, как-будто використовується не віддалений компонент, а самий звичайний об’єкт, що виконується на клієнтській машині.


Кожен екземпляр компонента запускається в окремому завданні і ніяк не може випадково впливати на інші запущені компоненти. Якщо дві різні клієнтські програми одночасно здійснюють запит на роботу з одним і тим же компонентом, то Jaguar сервер створить в пам’яті комп’ютера два примірники компонента, і кожне клієнтське ПО буде працювати тільки зі своїм примірником виконується коду. Таким чином, гарантується ізольованість роботи бізнес-модулів, що виконують запити від різних клієнтів. Така ідеологія роботи сервера додатків увазі відсутність глобального контексту при запуску компонента. Компоненти виконуються виключно в контексті примірника, породженого за запитом клієнтського ПЗ.


Jaguar сервер зберігає інформацію про встановлені на ньому компонентах та параметрах їх завантаження в репозиторії компонентів. У репозиторії всі компоненти згруповані по іменованих контейнерів (package), що дозволяє структурувати схему встановлених компонентів і здійснювати масове встановлення або копіювання компонентів, що знаходяться в одному контейнері. Після установки Jaguar сервера репозиторій вже містить набір службових контейнерів і компонентів, необхідних для доступу та роботи деяких внутрішніх інтерфейсів Jaguar сервера.


Створення компонентів Jaguar сервера


Перерахуємо всі варіанти програмного коду, який може бути використаний як компонента сервера додатків.

Рис.3 Компоненти Jaguar сервера


Невізуальні об’єкти PowerBuilder



Практично будь-який об’єкт, створений у середовищі швидкої розробки PowerBuilder, здатний грати роль компонента Jaguar сервера, якщо він не здійснює візуального взаємодії з користувачем і не вимагає використання глобального контексту програми. Вбудовані в середу PowerBuilder утиліти дозволяють автоматично вибрати і прогрузиться вибрані об’єкти в якості компонентів на сервер додатків. При цьому на сервер буде завантажений не тільки сам об’єкт, але і всі необхідні для його роботи бібліотеки додатки. При породженні декількох компонентів з різних об’єктів однієї програми будуть створені різні компоненти, незалежно запускаються в рамках окремих процесів. У даному пункті мається на увазі використання компілювати в середовищі PowerBuilder машинно-незалежного Р-коду у вигляді PBD модулів. Інструментальна Середа підтримує також прозору налагодження компоненту на самому сервер додатків.


Java класи та компоненти Enterprise Java Beans



Jaguar сервер підтримує роботу в якості компонентів з модулями, написаними на мові Java. Це може бути звичайний Java-клас, або ж серверний компонент, що відповідає стандарту Enterprise Java Beans. В обох випадках гарантується повна машинно-незалежність створених компонент і максимальна масштабованість створеної ІС. Створення компонент на мові Java може виконуватися в будь-якому середовищі розробки, але використання фірмової середовища PowerJ і поставляються з нею утиліт дозволяє автоматизувати процедури створення і завантаження на сервер розроблюваних компонент, значно скорочуючи час розробки.


ActiveX компоненти



Версія сервера додатків Jaguar для операційної системи Windows NT повністю підтримує СОМ технологію компанії Microsoft. Для створення підключаються до сервера COM-об’єктів можна використовувати будь-яку сумісну з технологією Microsoft інструментальну середу.


Програмний код, написаний на мовах С і С + +



При використанні бібліотек, що поставляються з Jaguar сервером, можна скомпілювати код мовами С та С + + у вигляді підключається до сервера компонента. При цьому можна добитися платформонезавісимость на рівні вихідних текстів компонента.


Набір процедур БД, функції Cobol-систем і об’єкти системи управління підприємством SAP R / 3



У комплект продукту EAS входить спеціальна програма Application Integrator, що дозволяє використовувати у вигляді компонентів збережені процедури БД і наявні напрацювання на мовою Cobol. Існує спеціальна версія Application Integrator, яка підтримує роботу з бізнес-об’єктами системи управління підприємством SAP R / 3.


З цього багатого списку видно, що практично всі технології розробки програмних продуктів можуть використовуватися як основа для створення Jaguar-компонентів. Використання технології ActiveX таїть в собі обмеження по масштабованості ІС підприємства, але зате забезпечує сумісність з більшістю інструментальних засобів на платформі Intel і підтримку об’єктів третіх фірм. При переході на трирівневу архітектуру підприємство має можливість повністю використовувати вже наявні в його арсеналі напрацювання, мінімальними зусиллями модифікуючи вже функціонуючу ІВ. Можливість використання в рамках однієї корпоративної системи компонентів, створених в різних інструментальних середовищах, дозволяє здійснювати нарощування ІС із застосуванням найефективніших для конкретного завдання засобів.


Клієнтські програми


Доступ з боку клієнта до встановлених на Jaguar-сервері компонентів здійснюється з використанням CORBA-сумісного протоколу IIOP. Це означає, що якщо ви маєте стандартний ORB-клієнт (Object Request Broker – клієнтська частина, що працює за стандартом CORBA), то ваш додаток вже готово до роботи з Jaguar-сервером. В комплекті продукту EAS поставляється набір власних реалізацій ORB-клієнтів, призначений для вбудовування доступу до Jaguar-серверу в створювані клієнтські програми. У комплект входять бібліотеки класів для мови Java, а також бінарні бібліотеки для підключення на етапі лінковки зі стандартними компільовані додатками. Середа розробки Java-додатків PowerJ містить набір утиліт для автоматичного створення коду виклику Jaguar-сервера.


ORB-брокер вбудований і в середу розробки PowerBuilder. Так само як і в середовищі PowerJ, створення прототипу для доступу до сервера додатків займає кілька хвилин, дозволяючи зосередити зусилля розробника на реалізації бізнес-алгоритмів.


В поставку EAS входить також і спеціальна ActiveX заглушка (stub), що дозволяє реалізувати приєднання до сервера додатків у вигляді зареєстрованих на клієнтській машині СОМ-об’єктів.


Крім протоколу IIOP, Jaguar сервер підтримує для виклику компонентів протокол TDS, що використовується в роботі з корпоративними серверами БД. Це дозволяє викликати методи компонента з усіх програм, здатного звернутися до збереженої процедурою БД. Тільки в цьому випадку як такого “псевдо-сервера БД” виступатиме Jaguar-сервер.


Протокол IIOP (базується на протоколі TCP / IP) призначений для роботи в інтранет-інтернет мережах. Але сучасна структура глобальної мережі Інтернет допускає доступ клієнта до сервера через набір Proxy і Firewall серверів, які можуть забороняти роботу з будь-яким протоколом, що виходять за рамки стандартного web-з’єднання. Тому реалізація ORB-клієнта в продуктах Sybase підтримує також тунелювання протоколу IIOP через стандартний HTTP протокол.

Рис.4 Клієнти Jaguar сервера


Концепція тонкого клієнта


Найбільша завдання, що стоїть перед сервером додатків, – забезпечення роботи з інтернет клієнтами. Можна, звичайно ж, використовувати інтернет та інтранет мережі тільки як комунікаційну інфраструктуру. Але найчастіше сюди додається й ідеологія реалізації клієнтського додатка у вигляді HTML сторінки для перегляду в web-браузері. Така сторінка може містити код, написаний на клієнтських скриптах, або вставлений Java-аплет. При цьому сам аплет (або навіть ActiveX об’єкт) може динамічно завантажуватися по мережі при спробі користувача переглянути HTML сторінку. Таке клієнтське додаток зазвичай перекладає виконання всій бізнес-логіки на плечі серверної частини, яка формує web-документи. Тому в таких системах використання сервера додатків стає нагальною необхідністю.

Рис.5 Реалізація тонкого клієнта на Jaguar-сервері


Як уже згадувалося вище, в якості клієнта Jaguar-сервера можуть виступати Java програми і, зокрема, Java-аплети. Постає питання, яким чином цей аплет повинен доставлятися для запуску на клієнтську машину? Для цього можна використовувати будь-який web-сервер, але є рішення простіше. Сам Jaguar-сервер містить в собі повнофункціональний web-сервер, готовий до зберігання і прогрузки на сторону клієнта як статичних HTML сторінок, так і Java аплетів. Використовуючи інструментальну середу PowerJ (або будь-яке інше засіб для створення Java-аплетів), ви створюєте модуль для приєднання до сервера додатків і управління з боку клієнта виконанням бізнес-логіки.


Але підтримкою завантаження статичних документів можливості Jaguar як web-сервера не обмежуються. Сервер додатків підтримує і сучасні засоби для динамічного створення HTML сторінок. Для повного контроль над створенням динамічної сторінки використовується технологія Java-сервлетов. Це стандарт корпорації Sun для створення Java додатків, що займаються динамічним формуванням відповіді на запит документа по HTTP протоколу. У більш простому випадку, коли необхідно динамічно створити HTML сторінку, досить скористатися технологією Dynamo. Технологія Dynamo являє собою реалізацію серверного мови скриптів JavaScript (стандарт ECMAScript). Починаючи з версії 3.6, сервер Jaguar повністю підтримує Java-технології J2EE для побудови компонент і Java Server Pages (JSP) для використання HTML шаблонів з вбудованими вставками коду мовою Java.


Всі зазначені підходи до створення динамічних HTML сторінок дозволяють легко здійснювати виклик компонентів сервера додатків. Інкапсульовані в компоненти всю необхідну бізнес-логіку, для її управління ви можете використовувати набір статичних або динамічних HTML сторінок. Причому для хостингу використовувати вбудований в Jaguar web-сервер.


За довгі роки розробки та розвитку інструментальних засобів компанія Sybase створила унікальну технологію подання та управління даними DataWindow. Переваги цієї технології визнані у всій індустрії. Вони дозволяють уніфікувати зовнішнє представлення даних і значно скоротити час розробки ПЗ. Практично вся лінійка інструментальних засобів компанії Sybase активно використовує технологію DataWindow. Для роботи ж з тонкими клієнтами пропонується використовувати модифікацію цієї технології – HTML DataWindow. При цьому для візуалізації даних використовується зовнішнє уявлення об’єкта DataWindow, відредагованого в одному з інструментальних засобів компанії Sybase. При генерації динамічної HTML сторінки спеціальні функції генерують HTML код, що відображає дані точно в такому ж вигляді, як якщо б вони виводилися на екран за допомогою самого об’єкта DataWindow. При цьому на клієнтському місці не потрібно встановлювати будь додаткове програмне забезпечення. Описана технологія дозволяє при розробці тонкого клієнта використовувати більшу частину напрацювань від уже створених “повнофункціональних” клієнтів.


Оптимізація роботи сервера додатків


Крім організації зв’язку між клієнтським додатком і компонентом, Jaguar-сервер надає можливості для зменшення часу відповіді на клієнтський запит за рахунок використання пулу об’єктів і з’єднань з БД. Розберемо роботу пулу об’єктів на прикладі циклу життя екземпляра компонента.


Після приєднання клієнта до сервера за його запитом примірник компонента створюється в пам’яті серверної машини. Потім клієнт виконує необхідні дії і дезактивує компонент. При цьому сам примірник компонента не знищується, а поміщається в пам’яті комп’ютера в пул об’єктів. Коли прийде наступний запит від цього чи іншого клієнта на використання компонента, час на створення екземпляра вже не витрачається, а екземпляр компонента буде взято з пулу об’єктів. Утиліта адміністрування Jaguar-сервера дозволяє окремо для кожного компонента налаштовувати розміри пулу і встановлювати таймаут для знаходження в ньому об’єктів.


Аналогічно працює і пул з’єднань до БД. Адміністратор сервера БД налаштовує параметри приєднання до БД і розміри пулу. У міру появи необхідності доступу до даних компоненти будуть користуватися сполуками з пулу, знову економлячи на часі створення.


Наявність пулу об’єктів і з’єднань з БД особливо актуально для побудови серверної частини для тонкого клієнта. HTTP протокол не зберігає інформацію про попередні приєднаннях клієнта. Тому послідовність HTTP запитів виглядає для сервера додатків як потік короткочасних запитів на створення і знищення об’єктів сервера. Технологія використання пулів дозволяє не тільки скоротити час виконання запитів, але і управляти продуктивністю за допомогою адміністрування Jaguar-сервера.


Транзакції і бази даних


Поява поняття транзакції і створення серверів БД, що забезпечують цілісність інформації в рамках однієї транзакції, послужило в свій час важливим стимулом для використання дворівневої архітектури. Тепер вимога наявності єдиного транзакційного контексту є обов’язковим для будь-який бізнес-операції. У той же час, нагальна необхідність об’єднання в одній ИС декількох взаємодіючих серверів БД знову піднімає цю проблему. У трирівневої моделі організації системи основний тягар із забезпечення цілісності даних повинен взяти на себе сервер додатків.


Jaguar сервер підтримує три моделі роботи з розподіленими транзакціями. Перша, фіктивна, практично декларує готовність самого розробника забезпечити транзакційний контекст при модифікації даних у БД. На практиці ця “псевдомодель” використовується в тих випадках, коли бізнес-логіка дозволяє обійтися без одночасної модифікації інформації відразу в декількох БД. В цьому випадку від сервера додатків потрібно тільки максимальну швидкодію без додаткового контролю за кордонами дії проводяться транзакцій.


Дві інші моделі пропонують реальне забезпечення єдиної транзакції при роботі з кількома БД в рамках роботи з Microsoft або UNIX сумісними середовищами. Одна модель забезпечує роботу з Microsoft DTC (Distributed transaction coordinator), інша являє собою Sybase реалізацію розподілених транзакцій по OTS / XA протоколу. Виконання загальної транзакції може управлятися компонентами сервера як з використанням наданого API, так і з використанням стандартних засобів, специфічних для конкретного середовища розробки. Так, у разі застосування компонент JavaBeans, підтримується управління транзакціями відповідно до моделі JavaBeans.


Засоби адміністрування Jaguar-сервера дозволяють здійснювати тонке налаштування ролі встановленого компонента в проведеної транзакції. Компонент може підтримувати або не підтримувати роботу з транзакціями. Використання компонента може вимагати наявності вже розпочатої транзакції, або навпаки автоматично починати транзакцію при першому виклику методу. В залежності від налаштувань, сервер додатків управляє не тільки єдиним транзакційних контекстом, але й часом існування примірника об’єкта. Так, якщо компонент працює в рамках єдиної транзакції, його екземпляр не буде знищений, поки вся транзакція не буде успішно завершена або скасована з іншого компонента.


Забезпечення відмовостійкості


У серйозній ІС питання відмовостійкості виходять на перший план не лише через вимоги працездатності самої корпорації. Коли ІС стає обличчям компанії, зверненим до потенційних клієнтів і бізнес-партнерам, її працездатність стає запорукою загальної довіри до компанії на ринку. Тому корпорація Sybase приділила питанням забезпечення відмовостійкості особливу увагу.


Основоположним для забезпечення відмовостійкості є поняття кластера Jaguar-серверів. При налаштуванні сервера адміністратор має можливість організувати кілька серверів додатків в єдиний кластер. Для такого кластера доступні загальна прогрузки та реєстрація компонентів і забезпечення працездатності системи навіть в умовах виходу з ладу кількох машин. Jaguar-сервер надає можливість автоматичного відновлення працездатності в разі збоїв (automatic failover), замінюючи прозоро для клієнта відключившись примірник компонента примірником компонента на іншому комп’ютері. Така можливість не є “рідний” для всіх програмних модулів і вимагає певної підтримки з боку розробника. Зокрема, для реалізації автоматичного відновлення працездатності можуть використовуватися компоненти без збереження стану (stateless) або компоненти, що підтримують можливість зовнішнього збереження стану (serialization).


Усередині кластера здійснюється контроль за працездатністю кожної окремої машини. У разі виявлення непрацездатності комп’ютера він відключається від кластеру та всі клієнтські запити від нього перенаправляються до працюючих комп’ютерів. Адміністратор може керувати алгоритмом автоматичного балансування розподілу навантаження по машинам в кластері. Таким чином за рахунок використання кластерної архітектури можна домогтися не тільки побудови високонадійних систем (high availability), а й здійснювати поступове нарощування комп’ютерних потужностей у міру збільшення числа працюючих в кластері машин.


Організація безпеки сервера


Умовно структура безпеки Jaguar-сервера ділиться на дві частини: аутентифікація користувача і забезпечення захищеного каналу зв’язку. Для цього активно задіються можливості аутентифікації операційної системи, на якій запущений сервер, і тунелювання комунікаційних протоколів всередині SSL протоколу.


При приєднанні клієнтського ПЗ до сервера додатків відбувається аутентифікація по імені користувача та паролю, або за допомогою пред’явлення електронного підпису SSL сертифікату. Для перевірки пароля користувача можуть бути використані реєстр користувачів самої операційної системи, внутрішня таблиця користувачів Jaguar-сервера або підключається користувальницький компонент, спеціально призначений для аутентифікації.


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


Адміністратору сервера додатків надаються широкі можливості по контролю рівня захисту, на якому здійснюється доступ до контейнера сервера (package), до його компоненті, або, навіть, до окремого методу компоненти. Ієрархічна структура завдання атрибутів захисту дозволяє розробляти повнофункціональні компоненти, контролюючи доступ до частини функціональності вже на етапі завантаження компонента на Jaguar-сервер засобами адміністрування.


Архітектура побудови серверного додатка


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


Крім звичайних компонентів, примірники яких створюються окремо для кожного працюючого клієнта, існують спеціальні колективні (shared) компоненти. Для таких компонентів в рамках комп’ютера існує тільки один запущений екземпляр. Доступ до такого примірника з боку декількох додатків контролюється самим сервером, що гарантує коректність викликів компонента в багатозадачному режимі. Такі Спільні компоненти можна використати для організації глобального контексту для декількох незалежно виконуваних компонентів.

Рис.6 Приклад побудови додатків на базі компонентів


Клієнтський додаток запитує примірник компонента 1 для виконання бізнес-транзакції. Компонент 1 при цьому запитує для своїх потреб примірник компонента 2, і сервер додатково створює його. Одночасно компоненти 1 і 2 звертаються до поділюваного компоненту 3, здійснюючи обмін інформацією між собою та з іншими компонентами. Розділяється компонент 3 здійснює доступ до БД не самостійно, а через функції розділяється компонента 4. Компонент 1 по мірі необхідності викликає і створює компонент 5, що знаходиться вже на іншому сервері додатків. На іншому сервері можуть викликатися як звичайні компоненти, так і колективні (компонент 6).


Передачу інформації між незалежно запущеними компонентами можна організувати і на рівні викликів спеціального API Jaguar-сервера. В цілому, набір встановлених на сервері компонент утворює ціле додаток. Його запуск починається зі звернення клієнтського ПЗ до сервера, що породжує потім цілий ланцюжок взаємодіючих компонент. Така структура дозволяє використовувати при проектуванні ПО добре зарекомендував себе об’єктно-орієнтований підхід, але вже без обмежень на використовувані інструментальні засоби і оперуючи масштабами всієї корпоративної системи, а не декількох комп’ютерів.


Враховуючи, що більшість аспектів взаємозв’язку компонентів і клієнтського ПЗ реалізується самим Jaguar-сервером, а не на рівні розробника, процес проектування всієї системи чітко відділяється від конкретного кодування програмних модулів і асоціюється вже не з конкретним кодом, а з адмініструванням сервера додатків. Налагоджене і працює програма, що складається з декількох компонент, можна потім встановлювати на “бойовий” сервер цілим контейнером (package) разом з адміністративними налаштуваннями.


Висновок


Дана стаття далека від претензій на вичерпне виклад можливостей і внутрішньої архітектури Jaguar-сервера. Автор лише спробував коротко описати той потенціал, який закладений у використанні сервера Jaguar для побудови трирівневої моделі ІС. Потужні можливості продукту в даному випадку одночасно поєднуються з легкістю перших кроків з переведення ІС на трирівневу архітектуру. Рішення, що базуються на підтримку більшості сучасних корпоративних стандартів і стандартів “де-факто”, дозволяють будувати гарантовано сумісні і надійні системи.


За широтою спектра підтримуваних форматів і стандартів серверу Jaguar на ринку зараз немає рівних. Використані рішення і архітектура продукту дозволяють керівникам проектів чітко контролювати процес розвитку та експлуатації ІС. А розробник за рахунок застосування Jaguar-сервера отримує можливість задіяти вже наявний у нього професійний досвід в розрізі нових вимог часу та ринку.


Рішення назрілих проблем на вже наявній базі, що забезпечує економію ресурсів підприємства, – ось те, що дає впровадження Jaguar-сервера, одночасно переміщуючи ІС підприємства в нову площину розподілених обчислень і електронного бізнесу. Постачаються в комплекті з Jaguar сервером адміністративні та сервісні програми, що входять до складу Enterprise Application Server, дозволяють упевнено дивитися у завтрашній день, йдучи в ногу з сучасними вимогами ринку та індустрії.

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


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

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

Ваш отзыв

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

*

*