Новини освіти і науки:

G+

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

Переваги розробки тришарових програм

· Зменшення установки - драйвери бази даних і ядро встановлюються на сторону сервера. Це зменшує робоче навантаження.

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

· Безпека забезпечується установкою брандмауерів. Це дозволяє обмежити доступ до захищених даних.

· Ресурси сервера доступні у вигляді так званої сукупність ресурсів, що прискорює доступ.

· Застосування архітектури до бази даних зменшує з'єднання і кількість необхідних ліцензій.

· Кожен шар може мінятися без звернення до інших.

· Моніторинг вельми простий. Помилки і вразливі місця легко виявляються. Перевантаження одного шару не впливає на інше.

Недоліки тришарових програм

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

· Збільшена вартість підтримки програм.

· Великий код.

· Останній недолік - реалізація взаємозв'язку шарів.

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

Серверні програми - завдання і ролі

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

Головними ролями серверних програм є:

· забезпечення стандартами безпеки;

· забезпечення мережевими ресурсами;

· багатозадачність;

· обслуговування розподілених систем.

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

Таблиця 9.9.4. представляє декілька серверних програм:

Таблиця 9.9.4. Серверні програми.

9. Cервіс-орієнтована архітектура (СОА)

Для того, щоб будувати сучасні і гнучкі розподілені програми, слід задовільняти наступні вимоги:

· інтеграція ресурсів ПЗ вимагає початкової слабкої зв'язаності;

· зв'язок повинен грунтуватися на широко відомих стандартах інтернету;

· інтерфейси послуг повинні бути добре описані і загальнодоступні.

Вимоги не повинні бути пріоритетом, але їх застосування буде корисним:

· ми можемо використовувати інші засоби для розробки програм;

· ми можемо використовувати функціональність компаній третьої сторони, що зменшить вартість і збільшить продуктивність;

· ми можемо продавати або ділитися сервісним ПЗ. Наприклад, ми можемо створити компонент про аукціон і продати його як сервісне ПЗ, а не програму.

Архітектура під назвою "сервіс-орієнтованная архітектура" задовольняє ці вимоги. Це дозволяє створювати динамічні, слабо зв'язані розподілені програми.

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

СОА має три головні ролі:

1. Постачальник послуг - це вузол (у інтернеті або інтранеті), який дає доступ до даного бізнес-компоненту з потрібною функціональністю.

2. Споживач послуг - використовує видалений компонент для створення власних програм. У СОА клієнт і споживач - вузли.

3. Оцінювач послуг - вузол мережі є сховищем описів послуг, на зразок жовтих сторінок. Творець компонентів розміщує інформацію разом з оцінювачем послуг, і клієнт може знайти ці послуги.

Малюнок 9.10.1. Архітектура СОА.

Взаємозв'язки між вузлами:

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

· Знаходження. Клієнти знаходять послуги, що знаходяться в сховищі.

· Скріплення. Клієнти встановлюють зв'язок з послугою. Це вимагає авторизація.

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

Мережеві послуги, як реалізація СОА

Середовищем для СОА є інтернет. Там може бути знайдений кожен вузол. Зв'язок відбувається по протоколах TCP/IP, або HTTP - у вищих рівнях взаємодії відкритих систем.

· Реалізація - XML веб-сервер-сервіс. Приклад реалізації СОА зображений на малюнку.

Малюнок 9.10.2. Реалізація СОА з використанням веб-сервісів.

· Оцінювач послуг як веб-сервіс. Оцінювач послуг - вузловий сервер - UDDI (Universal Description, Discovery and Integration, універсальний опис, пошук і взаємодія). UDDI - це каталоги бізнес-компонентов, готових до використання.

· Постачальник послуг - вузол, що надає мережеві XML веб-сервіси. Мережеві послуги надаються www-сервером (Apache або інформаційні інтернет-послуги).

· Споживач послуг як веб-сервер-сервіс - вузол, який може бути зв'язаний через HTTP або SOAP, розуміє інтерфейс послуги, яку хоче використовувати, надає інструменти авторизації.

Як працюють інтернет-послуги?

Опис XML веб-сервісов.

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

Клієнти знаходять потрібну послугу в UDDI. Якщо відома адреса, файл WSDL з технічною специфікацією може бути завантажений. Всі платформи дозволяють створювати Proxy, заснований на WDL. Ідея полягає в тому, щоб заховати складність WDL і показати простий інтерфейс. Клас проксі містить список методів, які повертаються разом з своїми параметрами і типами.

Малюнок 9.10.3. Крок 1. Створення класу проксі, заснованого на WSDL.

Тепер у нас є вся інформація, потрібна для використання даного інтернет-сервісу. Мова програмування не має значення. Клас проксі дозволяє викликати видалені сервіси. Клас транслює повідомлення в повідомлення SOAP, яке зрозуміле для мережевої служби. Остання повертає відповідь у форматі SOAP і посилає її назад клієнтові. Все робиться за допомогою HTTP без потреби в постійному з'єднанні (запит/відповідь).

Малюнок 9.10.4. Крок 2. Зв'язок з мережевою службою через SOAP.

10. Короткий звіт

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

X. Реалізація

1. Характеристики етапу реалізації

За етапом розробки йде етап реалізації. Ця стадія виробництва ПЗ увійшла до ери автоматизованого виробництва ПЗ. Тут використовуються такі інструменти, як швидка розробка програм (Rapid Application Development, RAD) і мови високого рівня.

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

Малюнок 10.2.1. Етап реалізації.

2. Надійність програмного забезпечення

Надійність стає найголовнішим чинником створення ПЗ.

Вимоги клієнтів зазвичай ростуть швидше, ніж вимоги до апаратури. Різноманітність ПЗ дуже велика і воно стає все складнішим.

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

Надійність програмного забезпечення повинна бути взята до уваги на початку його розробки. Несподівані помилки і важкість у видаленні їх в ПЗ повинні бути взяті до уваги на ранніх стадіях.

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

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

Основними методами збільшення надійності є:

· запобігання помилкам;

· визначення погрішності помилок.

Запобігання помилкам

Неможливо уникнути всіх помилок. Уникнення помилок:

· Не використовувати методи з великою вірогідністю помилок (наприклад, використання вказівників і т.п.);

· Використання принципу обмеженого доступу (інкапсуляція, розділення пам'яті і т.д.);

· Використання мов і компіляторів з перевіркою відповідності типів;

· Використання мов високого рівня;

· Строго визначати інтерфейси користувача;

· Приділити увагу виключенням (порожні множини, порожні цикли, нульові значення, змінні, що не ініціалізували, і т.д.);

· Використання готових компонентів (бібліотеки, класи і т.д.);

· Мінімізація відмінностей між абстрактною моделлю і моделлю реалізації.

Небезпека техніки

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

Але методів з більшою вірогідністю помилки слід уникати. Але іноді їх дійсно необхідно застосувати. У таких випадках методи обробки помилок і контролю результатів повинні розроблятися дуже ретельно.

Найнебезпечнішою технікою програмування є:

· Використання команди "go to". Ця команда може призвести до труднощів розуміння програм і їх підтримки (внесення пізніших змін).

· Використання чисел з плаваючою крапкою. Числа мають обмеження по точності, і обчислення можуть накопичувати відхилення від реальних чисел.

· Використання вказівників і адресної арифметики з їх використанням. Вказівники виключно небезпечні. Вони дозволяють проникнути в пам'ять і провести в ній абсолютно будь-які зміни. Вони заслуговують особливої уваги.

· Паралельне обчислення. Паралельні обчислення призводять до складної залежності часу і так званому галопуванню (залежить від випадкових результатів деяких потоків). Їх важко перевірити.

· Використання виключень і переривань. Використання цієї техніки веде до паралелізму і провокує такі ж проблеми. Так само це може "підвісити" програму.

· Використання рекурентних співвідношень. Програму з рекурентними співвідношеннями важко зрозуміти і трасувати.

· Використання динамічного розподілу пам'яті. Динамічний розподіл пам'яті без збірки сміття може призвести до витоків пам'яті і "підвісити" програму.

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

· Не вказані, несподівані побічні ефекти у функціях і процедурах

· Використання складних привласнень без дужок. Таке відбувається, коли програмісти покладаються на пріоритет операторів і уникають дужок. Це не веде до збільшення продуктивності. Але підхід може викликати багато помилок і труднощів в управлінні.

· Обробка даних багатьма процесами без синхронізації (блокування, транзакції). Деякі з методів корисні, але повинні використовуватися обережно.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Безпека	\|	Принцип обмеженого доступу

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.007 сек.