1.2 Стан корпоративного програмного середовища типовою організації

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

• Основна маса комп'ютерів базується на платформі Intel або AMD, менше на Compaq, Sun і т.п.

• Використовувані операційні системи MS Windows, Linux, інші UNIX-подібні ОС. Основна операційна система, встановлена на робочих місцях користувачів - MS Windows. Більшість серверів працює також під Windows. Часка серверів працює під Linux або іншими UNIX-подібними ОС.

• Основне офісне програмне забезпечення - MS Office.

• Основна поштова програма MS Outlook, MS Outlook Express або спеціальний поштовий клієнт (популярність набирає Mozilla Thunderbird).

• Основний інтернет-браузер MS Internet Explorer (зараз набирає популярність браузер Mozilla Firefox, іноді використовується браузер Opera).

• Основна система документообігу працює на основі Windows і MS Exchange.

• Основний Web-сервер Apache або IIS на платформі UNIX або Windows.

• Основна корпоративна СУБД MS SQL Server або Oracle, також додатково використовується MS Access або інші СУБД, але виключно як локальні. У малих компаніях бувають популярними MySQL і PostgreSQL [1].

1.3 Крос-платформні технології

Крос-платформні технології забезпечують спільну експлуатацію різних апаратних і програмних платформ в інтересах організацій-споживачів.

Основні архітектури програмного забезпечення

Автономні (standalone) програми:

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

Дволанкова архітектура "клієнт-сервер"

Ця архітектура набула поширення з початку 1990-х років на тлі зростання ринку персональних комп'ютерів і зниження попиту на мейнфрейми. В архітектурі "клієнт- сервер" програмне забезпечення розділене на дві частини - клієнтську частину і серверну частину. Завдання клієнтської-частини (програми-клієнта) полягає у взаємодії з користувачем, передачі запиту користувача серверу, отримання запиту від серверної частини (програми-сервера) і подання його в зручному для користувача вигляді. Програма- сервер же обробляє запити клієнта і видає відповіді. Класичні приклади: Web-технології (клієнт-браузер, сервер-Web-cepBep), робота з розподіленими СУБД (клієнт - спеціальна програма, сервер - сервер бази даних). Розвиток архітектури "клієнт-сервер", а особливо поява сучасних графічних інтерфейсів, призвело спочатку до появи різновиду архітектури клієнт-сервер, званої "архітектура з товстим клієнтом". Тут логіка представлення даних і бізнес-логіка розміщуються на клієнті, який (скажімо, в випадку, коли сервером є СУБД) спілкується з логікою зберігання та накопичення даних на сервері, використовуючи мову структурованих запитів SQL. Проте необхідність установки "товстих клієнтів", що вимагають значної кількості спеціальних бібліотек та спеціальної настройки оточення, на велике число користувальницьких комп'ютерів з різними операційними середовищами , як правило викликає масу проблем. Як альтернатива тому виникла також дволанкова архітектура "з тонким клієнтом". При цьому в ідеалі програма-клієнт реалізує лише графічний інтерфейс користувача (GUI) і передає / приймає запити, а вся бізнес-логіка виконується сервером. В ідеалі клієнтом є просто інтернет-браузер, який є в стандартній операційному середовищі будь-якого користувача комп'ютера і не вимагає спеціального налагодження, встановлення спеціалізованого ПЗ і т.п. На жаль, така схема теж не вільна від недоліків, хоча б вже тому, що серверу доводиться брати на себе іноді не властиві для нього функції реалізації бізнес-логіки додатка (наприклад, серверу СУБД доводиться виконувати розрахунки!)

Багатоланкова (multitiered) архітектура

Початок процесу розвитку корпоративного програмного забезпечення в багатоланковій архітектурі було покладено ще в рамках технології "клієнт/сервер". У них поряд з клієнтською частиною програми та сервером баз даних з'явилися сервери додатків (Application Servers). В ідеалі:

• програма-клієнт реалізує GUI, передає запити серверу додатків і приймає від нього відповідь,

• сервер додатків реалізує бізнес-логіку і звертається із запитами до сервера "третього рівня" (наприклад, сервера бази даних за даними),

• сервер третього рівня обслуговує запити сервера додатків.

Програма-клієнт, таким чином, може бути "тонкою". Переваги такої архітектури очевидні:

• зміни на кожному з ланок можна здійснювати незалежно;

• знижуються навантаження на мережу, оскільки ланки не обмінюються між собою великими обсягами інформації;

• забезпечується масштабування і проста модернізація обладнання та програмного забезпечення, що підтримує кожна з ланок, у тому числі оновлення серверного парку і термінального обладнання, СУБД і т.д.;

• Додатки можуть створюватися на стандартних мовах третього або четвертого покоління (Java, C/C + +).

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

Основною проблемою систем, заснованих на дволанковій архітектурі "клієнт- сервер", або тим більше на багатоланковій архітектурі, є те, що від них вимагається мобільність в якомога ширшому класі апаратно-програмних середовищ. Навіть якщо обмежитися UNIX-орієнтованими локальними мережами, в різних мережах застосовується різна апаратура та протоколи зв'язку. Спроби створення систем, що підтримують всі можливі протоколи, призводить до їх перевантаження мережевими деталями на шкоду функціональності. Ще більш складний аспект цієї проблеми пов'язаний з можливістю використання різних представлень даних в різних вузлах неоднорідною локальної мережі. У різних комп'ютерах може існувати різна адресація, подання чисел, кодування символів і т.д. Це особливо істотно для серверів високого рівня: телекомунікаційних, обчислювальних, баз даних.

Спільним рішенням проблеми мобільності такого роду систем є використання технологій, що реалізують протоколи віддаленого виклику процедур (RPC - Remote Procedure Call) стандартизованим і платформно-незалежним способом. При використанні таких технологій звернення до сервісу в віддаленому вузлі виглядає як звичайний виклик процедури (методів віддалених об'єктів). Засоби RPC, в яких, природно, міститься вся інформація про специфіку апаратури локальної мережі та мережевих протоколів, переводить виклик в послідовність мережевих взаємодій. Тим самим, специфіка мережного середовища і протоколів прихована від прикладного програміста.

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