Вибір безпечних технологій створення інформаційної системи безпосередньо залежить від вибору архітектури ІС.
Розглядаючи інформаційну систему як сукупність взаємодіючих компонентів, можна розподілити їх за такими фізичним рівнями:
§ апаратний - комп'ютери, периферійні пристрої, мережеве та телекомунікаційне обладнання і т.д .;
§ системний і системно-залежний - операційні системи, мережеві протоколи і т. Д .;
§ прикладної середовища - кошти middleware (CORBA, DCE, Tuxedo і т.д.), DBMS, Intranet, OLAP, комунікаційні інтерфейси;
§ додатки предметної області;
§ загальна інфраструктура - сукупність компонент ІС, придатних для використання в різних предметних областях.
Такими компонентами, наприклад, є:
§ засоби автоматизації бізнес-процесів (атомарних завдань і потоків робіт);
§ засоби управління доступом до інформаційних ресурсів;
§ засоби складання і друку звітів (генератори звітів).
§ компоненти реалізують модель предметної області (
Під проектуванням архітектури взаємодії компонентів інформаційної системи (рівні II-IV) розуміється виділення базових компонентів, розробка їх інтерфейсів, а також визначення правил і принципів взаємодії цих компонентів.
Проектування архітектури взаємодії компонентів ІС - один з найбільш важливих і складних етапів і йому не завжди приділяється достатньо уваги при розробці системи.
При проектуванні архітектури взаємодії розподілених компонентів інформаційної системи розрізняють наступні типи взаємодії:
· Вертикальний - кожен компонентний має унікальний в рамках даної інформаційної системи інтерфейс;
· Горизонтальний - всі компоненти мають один і той же універсальний інтерфейс, що забезпечує межкомпонентное взаємодія;
· Змішаний - всі компоненти мають універсальний базовий інтерфейс, при цьому кожен компонент специфицирует додаткові операції для роботи зі своїм доменом предметної області.
Переваги та недоліки цих типів взаємодії легко простежити на прикладі інтеграції нового завдання в інформаційну систему, що складається з декількох компонентів.
У разі використання вертикального типу взаємодії розподілених компонентів обсяг коду, необхідного для інтеграції, буде визначатися кількістю компонентів системи. Кількість інтерфейсів в цьому випадку буде (N-1) * N, де N - число компонентів. Для впровадження нового завдання буде потрібно 2N + 1 раз розробляти нові сполучні програми. Зазвичай таке рішення є результатом недостатньої уваги, що приділяється проектування архітектур ІС.
У разі горизонтально побудованої системи кількість інтерфейсів (інтеграційного коду) буде мінімальним. Додавання нового компонента потребують реалізувати додатково всього два інтерфейси.
При реальній розробці надзвичайно важко створити однакові інтерфейси для всіх підсистем, тому найкращим для створення розподіленої системи є змішаний тип взаємодії компонентів. В цьому випадку побудована архітектура зберігає властивість універсальності інтерфейсів, але дозволяє додавати специфічні для даного додатка операції. Кількість коду, необхідного для інтеграції нового завдання при такій архітектурі, змінюється в залежності від конкретного проекту від 2 (горизонтальна архітектура) до 2N + 1 (вертикальна архітектура).
Загальні інтерфейси компонентів - ключ до проектування архітектури, що забезпечує успішний розвиток і підтримку системи протягом тривалого періоду.
При проектуванні архітектури додатків першим кроком має бути вибір використовуваних стандартів. Зі збільшенням складності інформаційних систем, важливість відповідності програмного забезпечення стандартам зростає. Стандарти використовуються для досягнення наступних цілей:
· Портіруемость додатків - перенесення додатків на різні апаратні платформи, операційні системи, мережеві протоколи;
· Інтероперабельність (interoperability) - можливість спільного використання інформації та ресурсів компонентами розподіленої системи;
· Зниження вартості системи - інтеграція програмних систем, що підтримують загальноприйняті стандарти, зменшує вартість додатків для кінцевого використання;
· Зниження ризику вибору програмного продукту - використання стандартів звільняє розробника від прихильності до конкретного програмного продукту;
· Збільшення часу життя системи - відповідність стандартам зменшує ризик швидкого старіння системи.