удований найпростіший лексичний аналізатор. Це завдання було вирішене, не вдаючись до жодних формальним методам, шляхом аналізу послідовності символів, що утворюють лексичні одиниці. Модуль захоплює перший символ, що визначає початок лексичної одиниці (букву, цифру і т.д.) а потім переглядає рядок остаточно елемента лексики (ідентифікатора, константи). Деякі лексичні одиниці при цьому мають ще й власне значення, яке виходить за рамки алгоритму розпізнавання. Наприклад, для ідентифікатора і константи важливий не тільки факт їх розпізнавання, але і їх значення, укладену в ланцюжку символів. Тому аналізатор перед початком чергового циклу фіксує початок розпізнаваної послідовності символів, для збереження її значення. У процесі розбору запитів строітcя дерево лексем, яке надалі передається для подальшого аналізу запиту та обробки повертаються процедурою даних відповідно з цим запитом.
Модулі, що містять процедури і функції бізнес-логіки, виконані в даній програмі у вигляді підключаються бібліотек DLL, що експортують функції і процедури по імені. У процесі виклику використовується угоду про виклики CDECL, яке дозволяє коректно очищати стек у разі передачі невірних параметрів при виклику процедури або функції, що забезпечує додаткову безпеку.
Кількість процедур і функцій, до яких користувачі здійснюють SQL-запити, може бути велике, тому для економії часу обробки запитів і пам'яті, що виділяється для роботи сервера додатків, ці процедури і функції будуть викликатися динамічно, звільняючи пам'ять відразу після повернення результату своєї роботи. Статично завантажується тільки одна функція, яка по вхідному параметру - імені процедури і функції, до якої виконується запит, повертає адресу відповідної процедури і функції бізнес-логіки в подключаемом модулі. Ця функція містить список всіх можливих процедур і функцій бізнес-логіки, здійснює звичайний перебір і знаходить потрібну. В іншому випадку, сервер додатків адресує свій запит безпосередньо до бази даних. Плагін містить також допоміжні процедури та функції, які допомагають сформувати набір даних, враховуючи всі додаткові критерії запиту. Схема алгоритму роботи сервера додатків представлена ??на малюнку 2.6.
2.3.2 Розробка інтерфейсу сервера додатків
Побудова триланкової архітектури в Delphi 7 може бути реалізовано за допомогою різних технологій DCOM, MTS, CORBA, SOAP. При розробці сервера додатків була використана технологія DCOM (Distributed Component Object Model). Технологія DCOM є розвитком базової технології COM корпорації Microsoft. Її безумовним гідністю є близькість з операційною системою Windows і простота реалізації, тому що основні інструменти цієї технології являють собою невід'ємні частини ОС Windows, в якій і планується експлуатація розроблюваної системи. Технологія DCOM найкращим чином підходить для реалізації поставленого завдання, тому що вона акцентує уваги на ключових моментах зв'язку між клієнтом і сервером додатків.
Рисунок 2.1 - Схема алгоритму роботи сервера додатків
Сервер додатків є DCOM-компонентом. Компонент TRemoteDataModule служить основою для створення сервера додатків, що використовує технологію COM/DCOM. Сервер додатків подібно сервера бази даних може одночасно обслуговувати декількох користувачів. Для кожного запиту клієнта створюється свій екземпляр об'єкта TRemoteDataModule, що виключає конфлікти в багатокористувацької середовищі. За допомогою майстра модуля можна уточнити взаємодія сервера додатків з безліччю користувачів. Можна вибрати режим спадкування і модель потоків команд.
Сервер додатків інкапсулює інтерфейс IAppServer, методи якого використовуються в механізмі віддаленого доступу клієнтів до сервера БД. Обмін даними сервера програми з клієнтами забезпечує динамічна бібліотека MIDAS.DLL, яка повинна бути зареєстрована на комп'ютері сервера програми.
Інтерфейс IAppServer є основою механізму віддаленого доступу клієнтських додатків до сервера додатки. Набір даних клієнта використовує його для спілкування з компонентом-провайдером на сервері докладання. Набори даних клієнта отримують екземпляр IAppServer від компонента з'єднання в клієнтському додатку.
При створенні вилучених модулів даних кожному такому модулю ставиться у відповідність новостворюваний інтерфейс, предком якого є інтерфейс IAppServer. Розробник може додати до нового інтерфейсу власні методи, які, завдяки можливостям механізму віддаленого доступу багатоланкових додатків, стають доступні додатку-клієнта.
За замовчуванням інтерфейс є несохраняющейся стан (stateless). Це означає, що виклики методів інтерфейсу незалежні і не прив'язані до попереднього викликом. Тому інтерфейс IAppServer не має властивостей, які б зберігали інформацію про стан між викл...
