Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:MUMPS СУБД. Практика применения и опыт программирования.pdf
6.4. WEB 441
И, если веб странице для работы необходимо строго работать только
с авторизованным пользователем либо со связанным с ним контекстом,
во всех страницах необходимо это предусматривать. Например, перенаправлять на страницу авторизации, либо возвращать содержание по
умолчанию.
Очевидно, что и вторая и третья проблема протокола HTTP не относятся напрямую к MUMPS системам, и тут могут быть использованы
точно такие же типовые решения проблем, как и при использовании
других веб технологий.
6.4.8 Поверх HTTP
На основе протокола HTTP строится множество дополнительных технологий взаимодействия веб клиентов и сервера. В них используется
тот факт, что если административно настроен канал взаимодействия по
TCP/IP с прохождением HTTP запросов, то поверх HTTP протокола
также строится набор дополнений по передаче параметров и получению
результата и используется в точности та же самая инфраструктура.
К таким технологиям относятся AJAX, SOAP, JSON, XML-RPC и
другие, зачастую не получающие отдельного названия. По сути, все они
построены на том, что создается дополнительный объект HTTP запроса,
через который передаются параметры и полученное содержание анализируется в зависимости от вида технологии. AJAX и SOAP обмениваются
данными в формате XML. Если AJAX передает произвольный XML, то
SOAP дополнительно использует определенную схему определения передаваемого XML, выделяя в ответе определенные теги самостоятельно
как ответ. В определенной мере SOAP можно рассматривать как один
из вариантов, или аналог взаимодействия XML-RPC.
Взаимодействие JSON основано на том, что в качестве ответа сервер
возвращает код на JavaScript, который выполняется непосредственно,
и по правилам JavaScript автоматически создается объект JavaScript.
Вызывающий код уже обращается к его свойствам - атомарным, или
массивам, или спискам.
Пример SOAP-запроса на сервер интернет-магазина:
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetails
xmlns="http://warehouse.example.com/ws">
<productID>12345</productID>
</getProductDetails>
442 ГЛАВА 6. ВНЕШНИЙ МИР
</soap:Body>
</soap:Envelope>
Пример ответа:
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetailsResponse
xmlns="http://warehouse.example.com/ws">
<getProductDetailsResult>
<productID>12345</productID>
<productName>Стакан граненый</productName>
<description>Стакан граненый. 250 мл.</description>
<price>9.95</price>
<currency>
<code>840</code>
<alpha3>USD</alpha3>
<sign>$</sign>
<name>US dollar</name>
<accuracy>2</accuracy>
</currency>
<inStock>true</inStock>
</getProductDetailsResult>
</getProductDetailsResponse>
</soap:Body>
</soap:Envelope>
Для протокола SOAP при его разработке были изначально дополнительно определены средства прототипирования и в нем присутствует
две отдельные части: 1) URL для получения прототипа функции с перечислением параметров и структуры возвращаемого значения и 2) URL
для собственно вызова функции. Наличие прототипов позволяет строить
визуальные средства с возможностью выбора функции и с автоматическими генераторами SOAP запросов, включая парсинг ответа.
Пример JSON ответа:
{
"firstName": "Иван",
"lastName": "Иванов",
"address": {
"streetAddress":
"Московское ш., 101, кв.101",
"city": "Ленинград",
"postalCode": 101101
},
"phoneNumbers": [
6.4. WEB 443
"812 123-1234",
"916 123-4567"
]
}
Для языка JavaScript такой ответ синтаксически является представлением JavaScript объекта с объявлением и одновременно инициализацией полей. В этом примере поля firstName и lastName специфицированы как атомарные строковые, поле address как также объект со своими
полями, и поле phoneNumbers как массив.
В своей технологической основе все эти способы построены на том,
что по HTTP передается набор параметров и принимается ответ, но ответ
отдается парсеру ответа для выделения его фрагментов. В случае AJAX
/ SOAP / XML-RPC ответ парсится как XML, а в случае JSON ответ
парсится как JavaScript. Что интересно, для обмена данными по таким
соглашениям уже не суть важно, какой именно из передающе - принимающих протоколов будет использован - будет это HTTP, или SMTP или
другой.
Несложно также построить такой запрос, чтобы не только вебсервер
отвечал на языке вебклиента, но и чтобы вебклиент отсылал вебсерверу
данные в характерном для него формате. В частности, в SOAP содержание передается как XML. Но вебклиент может также сформировать
содержание HTTP запроса и как JavaScript, и на языке MUMPS, например передавать данные в виде
data(78)
Berlin~Germany~Europe
в теле запроса типа POST или PUT.
Такое содержание на стороне MUMPS процесса может рассматриваться как просто перечисление пар ключ - значение, и расходы на парсинг данных фактически отсутствуют из-за встроенных в язык возможностей косвенности.
Разумеется, при применении такого метода передачи данных сохраняется опасность уязвимости при приеме данных от неавторизованного
источника. Если серверный код примет, например, такие данные:
a($h)
123
и строку с ключем будет использовать как есть, то рискует выполнить
системные функции как побочный эффект конструирования имени.
444 ГЛАВА 6. ВНЕШНИЙ МИР
Конечно, для страховки от такой возможности необходимо поставить
простейшую проверку на допустимость полученного ключа. Например,
применить функции $QS - $QL для проверки синтаксической допустимости имени и не является ли имя глобалом.
Весьма привлекательным выглядит вариант обмена данными в формате, наиболее удобном для принимающей стороны - вебсервер отвечает
вебклиенту на языке JavaScript, как в протоколе JSON, а вебклиент
отправляет данные вебсерверу на языке MUMPS. В этом случае на принимающей стороне не используются громоздкие сторонние библиотеки
парсинга абстрактных форматов данных, а используются встроенные в
язык средства косвенности и использования данных динамически, как
кода или фрагментов выражений. Теоретически, и для вебклиента на
JavaScript, и для вебсервера на MUMPS (или на другой NoSQL СУБД)
передача данных в виде просто пар ключ - значение выглядит более
практичным форматом, чем громоздкая XML разметка.
При передаче, например, онлайн магазину запроса он мог бы выглядеть например так:
function
getProductDetails
productID
12345
Или так:
function("name")
getProductDetails
param("productID")
12345
6.5 Подключаемые DLL (SO)
Большинство современных MUMPS систем, а из промышленно используемых все, допускают подключение и использование внешних динамических библиотек. Это DLL в системах Windows и SO в Linux.
Сама библиотека получается компилирующими трансляторами, обычно это C / C++ / Pascal / ASM. Каждая из MUMPS систем декларирует правила, которым должна соответствовать такая библиотека и какой
программный интерфейс она должна предоставить. У каждой из MUMPS систем такие правила собственные и они не входят в стандартные
соглашения.
6.5. ПОДКЛЮЧАЕМЫЕ DLL (SO) 445
Вызов DLL начинается с вызова специальной или набора специальных расширенных функций MUMPS системы на языке MUMPS, в каждой из систем такой набор собственный, хотя по общей структуре характер вызовов в целом отвечает одним и тем же целям.
На стороне DLL она должна предоставить одну или несколько функций (экспортировать) в соглашениях и в прототипе, объявленном MUMPS системой. При необходимости вызова внешней DLL система определяет, в какой файле находятся необходимые функции, загружает его
динамически и отыскивает в экспортированных функциях специальную,
которая объявляет наличие и способ вызова внутренних функций этой
DLL. Далее отыскивается необходимая, имя которой было указано в MUMPS коде, и она вызывается с передачей ей аргументов и получением
возвращаемого значения.
В зависимости от типа применяемой MUMPS системы начальная
функция DLL, объявляющая поддерживаемые ей функции, может возвращать как набор указателей на функции, так и набор имен экспортированных функций. Для каждой из таких поддерживаемых внешних
функций DLL также должна объявить прототип, количество и, при необходимости, характер передачи аргументов.
Перед вызовом внешней функции MUMPS система преобразует при
необходимости передаваемые функции значения из своего внутреннего
представления в формат для передачи, формирует стек вызова и передает
управление вызываемой функции.
Укрупненно, и в абстрактных обозначениях, это может выглядеть так:
1. MUMPS система выполняет код
$zcalldll("filename","funcname",param1,param2)
2. MUMPS система по параметру filename отыскивает файл DLL и
динамически загружает его.
3. В списке экспорта отыскивается оговоренная этой MUMPS системой специальная функция декларирования поддерживаемых этой
DLL внешних функций, пусть например это будет функция DECLARED.
4. Для такой функции определяется прототип, согласно которому MUMPS система может получить список внешних функций этой
DLL с их прототипами. Пусть для примера эта функция возвращает
список определений для функций "transform", "add" и "remove".
446 ГЛАВА 6. ВНЕШНИЙ МИР
5. MUMPS система просматривает этот список объявлений и находит
необходимую, например, "transform".
6. По объявленному прототипу функции готовит значения параметров
и формирует стек вызова. Значения param1 и param2 переводятся
при необходимости из внутреннего представления в передаваемое
внешней функции. Это может быть строка завершающаяся нулем,
число, структура, или иное.
7. Внешняя функция вызывается и принимается значение возврата.
Это значение преобразуется к внутреннему представлению, используемому MUMPS системой и возвращается как возврат функции
$zcalldll на уровне исполнения языка.
Обычно предоставляется набор вариантов вызова внешней функции:
1. Загрузить DLL, вызвать функцию, выгрузить DLL.
2. Отдельно операции загрузки DLL, возможность вызова функций у
уже загруженной DLL, и операция выгрузки DLL.
3. Загрузка DLL, вызов функции с оставлением DLL загруженной, с
отдельной операцией выгрузки DLL.
Вариант с возможностью оставить DLL загруженной между различными вызовами функций в ней дает возможность разработчикам использовать внутренние данные такой DLL, ее собственное состояние,
многократно обращаться к ее внутренним объектам.
На основе внешних DLL обычно выполняются модули, написание которых на языке MUMPS очень трудоемко, либо для использования уже
написанных модулей, либо для использования специальных API операционных систем, не доступных готовыми для использования в MUMPS
вариантами. Также это могут быть функции, для которых критична скорость выполнения, например компрессоры данных, парсеры специальных
форматов данных, или интерпретаторы других языков.
К неудобствам таких внешних функций можно отнести то, что в
случае смены как MUMPS системы, так и операционной системы такие модули необходимо перекомпилировать под другую MUMPS- или
операционную систему (выполнить портирование). К большим плюсам
внешних DLL относится то, что в прикладной системе можно использовать произвольный функционал и расход ресурсов на вызов функции в
DLL обычно значительно меньше, чем на вызов иных внешних средств.
6.6. ФАЙЛЫ 447
К интересным возможностям вызова внешних функций в DLL можно отнести не только то, что в таких функциях разработчик ничем не
ограничен по возможностям, но и то, что большинство MUMPS систем
также предоставляют интерфейс обратного вызова процесса на языке
MUMPS из контекста вызванной DLL. При этом разработчик может в
таком обратном вызове выполнить набор команд или вычислить значение
выражения. При выполнении кода на MUMPS, в свою очередь, также
возможен вызов DLL, и так далее. Используя возможности обратного
вызова, разработик может, например, вернуть из DLL большое количество данных, записав их в локальную или глобальную переменную или
запросить дополнительные значения в зависимости от переданных аргументов.
В практическом применении чаще встречаются внешние DLL с функциями, которых не хватает в самой используемой MUMPS системе с точки зрения разработчиков прикладных систем, либо выполняющие сложные преобразования, либо предоставляющие доступ к специфическому
функционалу операционных систем. В частности, это функции кодирования данных в специальных форматах, функции криптографических
модулей, модулей регулярных выражений, модулей компрессии данных,
дополнительное управление аппаратным обеспечением сервера.
Также отдельно необходимо отметить, что именно внешние DLL используются для интеграции MUMPS систем с другими СУБД, как используя обобщенные драйверы (ODBC, OLEDB, BDE), так и специализированные DLL для определенных СУБД.
6.6 Файлы
Доступ к файлам поддерживается во всех MUMPS системах. Файл во
многих системах рассматривается как основное средство передачи данных, как больших, так и малых объемов, как в простых, так и в сложных
форматах.
Файл доступен MUMPS процессу как устройство. При открытии файла поддерживаются опции его открытия - нужно ли открыть только
имеющийся, или создать новый, какой должен использоваться доступ
- текстовый или бинарный, какой должен использоваться терминатор.
Операции чтения и записи автоматически смещают текущую позицию
в файле на количество прочитанных или записанных байт, при записи
после последней позиции файл автоматически увеличивается в размере.
И так далее. Не будет ошибкой сказать, что в целом MUMPS системы
поддерживают практически все операции с файлами, характерные для
448 ГЛАВА 6. ВНЕШНИЙ МИР
работы с файлами в других программных средах.
Способ открытия файла на чтение и ли на запись в каждой из используемых MUMPS систем отличается в силу того, что стандарт не
специфицирует в точности все необходимые опции. Это может быть открытие файла по номеру устройства с указанием в опции имени файла,
или указание в качестве имени устройства самого имени файла, или
совмещение в имени устройства и типа устройства и имени файла.
Набор поддерживаемых опций, их имена и значения также могут
отличаться в разных MUMPS системах. Поэтому для написания переносимого кода такие операции необходимо выносить в отдельный код.
Несмотря на некоторое расхождение в способе поддержки файлов
в виде устройств языка, общие правила у различных MUMPS систем
совпадают. Для того, чтобы процесс имел доступ к файлу, используется
команда OPEN, чтобы больше не использовать файл - команда CLOSE,
чтение выполняется командой READ, запись командой WRITE, а смена
опций использования командой USE. Чтобы выполнить портирование
кода на иную MUMPS систему, необходимо проверить по документации
на нее либо работу с этими командами, либо отдельное описание типа
устройства, где указываются поддерживаемые опции команд при работе
с файлами.
К особенностям применения файлов в практике можно отнести два
пункта: 1) работа в текстовом или бинарном режиме и 2) обработка
достижения конца файла.
Для текстового и бинарного режима различаются команды записи
write !
и чтения строки.
При записи символа перевода строки в Windows-based системах производится вывод последовательности
$C(13,10)
а в UNIX-like системах выводится последовательность
$C(10)
При чтении строки система также различает что является символом
окончания строки в зависимости от операционной системы. Для UNIXlike систем символ $C(13), предшествующий символу $C(10), считается
частью строки, хотя он и относится к непечатным, а в Windows-based
6.6. ФАЙЛЫ 449
системах, если он присутствует, то отбрасывается и в строку не включается. Но это относится только к последнему символу $C (13) - если
перед ним есть еще такие же, то они уже включаются в строку.
При работе в текстовом и бинарном режиме (если MUMPS система
поддерживает их различение) символ перевода строки рассматривается
описанным выше способом, в зависимости от типа операционной системы. В бинарном режиме выводится символ $C(10) вне зависимости от
типа операционной системы. Также для бинарного режима необходимо
задавать терминатор чтения. Иначе система будет читать строку на максимально доступную длину, например 32 килобайт.
Естественно, что если в файле находится строка с длиной превышающей максимальную длину строки MUMPS системы, то она прочитает строку на доступную длину и последующие чтения строки будут
производиться далее, из той же самой строки находящейся в файле. Таким образом, программа получит разбиение исходной длинной строки на
несколько строк. Если применяются файлы с такими данными, то разработчикам необходимо учитывать фактор максимальной длины строки.
И, возможно, в зависимости от применяемой MUMPS системы.
Для текстового и бинарного режима могут отличаться также поведение команд табулирования
write ?NN
В этом случае MUMPS система может как вести отсчет текущей
позиции в строке и корректно вывести в файл нужное число пробелов
для табулированного дополнения, так и не вести такой отсчет, и даже
игнорировать такую команду. Для каждой из MUMPS систем при необходимости применения такой команды по отношению к файлу необходимо отдельно проверить, какие операции система выполняет. Кроме того,
если выводящий код оперирует системными переменными $X и $Y при
работе с текущим устройством, то также необходимо проверить, какие
значения возвращаются для файла, как в текстовом, так и в бинарном
режиме.
Основной режим доступа к файлам в MUMPS предполагается через
модель последовательных устройств - текущий указатель автоматически смещается на количество прочитанных или записанных байт. Но
при работе со многими форматами файлов необходимо явно позиционироваться в файле. Для этого практически все системы поддерживают
опции команды USE, чтобы задать, как именно необходимо установить
текущую позицию в файле. Либо этот же функционал доступен через
специальные расширенные системные функции.
450 ГЛАВА 6. ВНЕШНИЙ МИР
К такой же операции, использующей позицию и длину, относится
операция явной блокировки участка файла на чтение или на запись. Такие операции уже могут поддерживаться м´еньшим числом MUMPS систем, и характерны скорее для файл-серверных систем, чем для клиентсерверных.
Многие MUMPS системы поддерживают отдельную опцию, задающую длину строки для чтения без указания терминатора чтения. С тем,
чтобы команда чтения строки всегда выполняла чтение строго указанной
порции байт. Таким образом, доступ к файлу из последовательного превращается в некоторым образом блочный. В любом случае, даже если
применяемая MUMPS система не поддерживает такой режим, у программистов есть опция команды чтения строки READ, указывающая длину
чтения.
Обработка конца файла по умолчанию определена во всех системах
как генерация ошибки. В стандарт входит именно такое поведение, и все
MUMPS системы его поддерживают, но стандарт не описывает код такой
ошибки, и в разных системах содержание ошибки может отличаться.
При выполнении команды чтения (как строки, так и одного символа) MUMPS система проверяет, есть ли в файле еще какие-то байты.
Если есть, то выполняет чтение на доступную длину. Например, если
программа запрашивает чтение данных на 100 байт, а в файле только
40, то команда вернет только 40 байт. Если же на момент выполнения команды чтения в файле нет доступных байт (предыдущие команды
чтения его исчерпали), то команда не возвращает пустую строку (иначе команды чтения зациклились бы), а генерирует ошибку достижения
конца файла.
Нужно отметить, что многие современные MUMPS системы поддерживают отдельный режим процесса для обработки конца файла. Используя системную функцию, можно переключить работу процесса так,
чтобы явно указать - будет ли генерироваться ошибка достижения конца
файла или будет взводиться определенная расширенная системная переменная. Многие MUMPS системы используют для такой переменной
имя
$ZEOF
При переводе процесса в такой режим программа должна реагировать
не на генерирующуюся ошибку, а на значение этой системной переменной.
В практическом применении файлы используются для экспорта и импорта данных, рутин, как в стандартных для MUMPS систем форматах, так и в сторонних форматах (XML, DBF, INI, CSV, и другие), а