Засобів адміністрування MS SQL SERVER.

 

Інструменти MS SQL SERVER

 

Служби MS SQL SERVER.

 

З’єднання з БД SQL SERVER

 

Архітектура додатків БД на базі DataSnap

 

Особливості використання сервера DataSnap

Сервер додатків інкапсулює більшу частину бізнес-логіки розподіленого додатку і забезпечує доступ клієнтів до бази даних.

Основною частиною сервера додатків є віддалений модуль даних.

По-перше, подібно звичайному модулю даних він є платформою для розміщення невізуальних компонентів доступу до даних і компонентів-провайдерів. Розміщені на ньому компоненти сполук, транзакцій і компоненти, інкапсулюющі набори даних, забезпечують трехзвенное додаток зв'язком з сервером БД. Це можуть бути набори компонентів для технологій ADO, BDE, InterBase Express, dbExpress.

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

До складу Delphi входять віддалені модулі даних. Для їх створення використовуйте сторінки Multitier, WebSnap і WebServices Репозиторія Delphi

1. Remote Data Module - віддалений модуль даних, що інкапсулює сервер Автоматизації. Використовується для організації з'єднань через DCOM, HTTP, сокети

2. Transactioiial Data Module - віддалений модуль даних, що інкапсулює сервер MTS (Microsoft Transaction Server).

3. SOAP Server Data Module - віддалений модуль даних, що інкапсулює сервер SOAP (Simple Object Access Protocol).

4. WebSnap Data Module - віддалений модуль даних, що використовує Web-служби і Web-браузер в якості сервера.

Крім віддаленого модуля даних невід'ємною частиною сервера додатків є компоненти-провайдери TDataSetProvider. З кожним компонентом, інкапсулюють набір даних, призначеним для передачі клієнту, в модулі даних повинен бути пов'язаний компонент-провайдер.

Механізм зворотного виклику DataSnap

 

Керування службами сервера додатків в DataSnap

 

Механізм віддаленого доступу DataSnap

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

Різні типи з'єднань, що дозволяють налаштувати транспорт і почати передачу і прийом даних, інкапсульовані в кількох компонентах DataSnap. Для створення з'єднання з тим або іншим транспортним протоколом розробнику досить перенести відповідний компонент на форму і правильно налаштувати декілька властивостей. Нижче розглядаються варіанти настройки транспортних протоколів для компонентів, що використовують DCOM, сокети TCP / IP, http.

Провайдери даних-брокери з’єднань DataSnap

 

Web-додатки та інтерфейси. Особливості розробки програмного забезпечення для Інтернет

 

Сервери додатків. Реалізації додатків. Переваги та недоліки додатків

 

Особливості взаємодії частин архітектури «клієнт сервер»

 

Модель FS (файл-сервер). Модель ROA (віддаленно)

 

16. Модель BDS (БД серверів). Модель AS (сервери додатків)

 

Методи доступу до даних. Об’єктні моделі доступу до віддаленнях даних

 

Зовнішні засоби інтеграцій додатків до БД

 

19. Базова технологія СОМ, СОМ+

COM (Component Object Model) — платформа компонентно-орієнтованого програмування розроблена в 1993 році компанією Microsoft; дозволяє використання міжпроцесної взаємодії (inter-process communication) та динамічного створення об'єктів у будь-якій мові програмування, що підтримує технологію. Використовується переважно у ОС Windows, хоча була реалізована на декількох платформах.

Основним поняттям, яким оперує технологія COM, є COM-компонент. Програми, побудовані на технології COM, фактично не є автономними програмами, а є набором COM-компонентів, що взаємодіють між собою. Кожен компонент має унікальний ідентифікатор (GUID) і може одночасно використовуватися багатьма програмами. Компонент взаємодіє з іншими програмами через COM-інтерфейси — набори абстрактних функцій і властивостей. Кожен COM-компонент має, як мінімум, підтримувати стандартний інтерфейс «IUnknown», який надає базові засоби для роботи з компонентом.

Windows API надає базові функції, що дозволяють використовувати COM-компоненти. Бібліотеки MFC і, особливо, ATL/WTL надають набагато гнучкіші і зручніші засоби для роботи з COM. Бібліотека ATL від Майкрософт досі лишається найпопулярнішим засобом створення COM-компонентів. Але, часто, COM-розробка залишається ще досить складною справою, програмістам доводиться вручну виконувати багато рутинних завдань, пов'язаних з COM (особливо це помітно у разі розробки на C++). Згодом (у технологіях COM+ і особливо.NET) Майкрософт спробував спростити завдання розробки COM-компонентів.

У складі Windows 2000 була випущена технологія COM+, яка розширювала можливості розробників COM-компонентів, надаючи їм деякі готові послуги, наприклад:

покращену підтримку нитей;

доступ до контексту, в якому виконується компонент (наприклад, компоненти, використані в ASP, можуть з цією можливістю дістати доступ до внутрішніх об'єктів тієї сторінки, на якій вони виконуються).

COM+ об'єднує компоненти в так звані застосунки COM+, що спрощує адміністрування і обслуговування компонентів. Безпека і продуктивність — основні напрями удосконалень COM+. Деякі ідеї, закладені в основу COM+, були також реалізовані в Microsoft.NET.

Технологія MIDAS, CORBA

Технологія MIDAS (Multi-tier Distributed Application Services Suite, Сервіс для створення багаторівневих розподілених додатків) була запропонована фірмою Borland вже досить давно, перший додаток з її використанням я написав ще в 98 році, на Delphi 4. І з тих пір практично всі програми для роботи з базами даних створюються мною саме на основі MIDAS. Про переваги, думаю, говорити не треба - навіть просте розділення програми на дві частини, одна з яких працює з базою даних (сервер додатків), а інша забезпечує інтерфейс користувача, створює значні зручності як при розробці програми, так і при його використанні.

CORBA (англ. Common Object Request Broker Architecture — загальна архітектура брокера об'єктних запитів) — це запропонований консорціумом OMG технологічний стандарт розробки розподілених застосунків.

Технологію MIDAS варто застосовувати в середніх і великих додатках, база даних яких налічує десятки і сотні таблиць. Саме в цьому випадку застосування MIDAS дає значні переваги в розробці та супроводі додатки. Які ж переваги дає використання MIDAS:

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

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

· Незалежність від конкретної СУБД. Дійсно, на робочих станціях не потрібно встановлювати клієнтську частину сервера баз даних, з'єднання з сервером додатків забезпечується однією бібліотекою midas.dll. При переході на інший сервер БД достатньо переписати тільки сервер додатків, не зачіпаючи клієнтську частину. Може виявитися корисним додавання ще одного шару абстракції даних між сервером додатків і сервером БД, що забезпечує просто доступ до елементів бази. У цьому випадку при переході на інший сервер БД потрібно переписати тільки окремі модулі, не зачіпаючи сервер додатків в цілому. Необхідно також враховувати, що при груповій розробці додатків зазвичай частина програмістів спеціалізується на базі даних, інша частина - на інтерфейсі користувача. При цьому кожна група програмістів може працювати над своєю частиною додатки, не відволікаючись на особливості роботи іншої групи.

· Значно спрощується синхронізація роботи користувачів, яку тепер забезпечує сервер додатків.

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

CORBA об'єднує програмний код в об'єкт, що містить інформацію про функціональність та інтерфейси доступу. Готові об'єкти можуть викликатися з інших програм або розташованих у мережі об'єктів CORBA.

CORBA використовує мову опису інтерфейсів OMG IDL для визначення протоколів взаємодії об'єктів із зовнішнім світом. Стандарт CORBA описує правила відображення IDL у мову реалізації об'єкта: Ada, C, C++, Lisp, Smalltalk, Java, COBOL, Pl/i і Python. Також існують нестандартні відображення у Perl, Visual Basic, Ruby і Tcl, які реалізовані розробленими для них засобами ORB.