Шлюзы и ORB

Архитектура клиент серверной системы подразумевает не только распределение вычислительных ресурсов, но и разделение функций между ресурсами. Когда мы приступаем к разработке клиент серверной системы, часто приходится учитывать тот случай, что у клиентов (кто заказывает приложение) могут оказаться уже большие объемы каких-то данных, хранящиеся в каких-то СУБД. Часто бывает так, что это достаточно старые информационные системы, которые не так-то просто преобразовать к клиент-серверной системе.

Шлюзы

Традиционным механизмом в этом случае называют шлюзы, это специальные дополнительные программные средства, которые позволяют данные из старых каких-то там информационных систем напрямую или не совсем напрямую фактически перекачивать в новые программные системы.
Остановимся на примере ORACLE. Несмотря на то, что СУБД ORACLE работает со своей базой данных ORACEL, тем не менее, она имеет в своем составе несколько шлюзов, точнее три типа шлюзов, т.н. прозрачные шлюзы. При доступе к таким базам данных как Informics, Sybase, MS SQL, IBM DB2 и ряда других фактически прозрачный шлюз позволяет работать со структурами чужих баз данных напрямую как будто со своими, без всяких проблем — это прозрачные шлюзы. Т.е. в ORACLE встроены специальные т.н. ORACLE Transparent Gateway, которые напрямую работают с чужими базами данных, даже не задумываясь о том, что они – чужие.

Второй вид шлюзов – процедурный. В этом случае ORACLE уже знает, что работает с нестандартной структурой, но если программист грамотный и сможет написать специальные библиотеки на СИ++ или PL/SQL, то работа с такой базой данных тоже может происходить вполне нормально и почти незаметно, т.е. процедурный шлюз надо сделать самому.

Третий вид шлюзов – это пассивные. Это уж совсем какие-нибудь древние структуры данных, которые сначала приходится из одних форматов поэтапно передавать в другие, а потом уже задействовать в ORACLE. Поскольку прямого взаимодействия организовать не возможно, поэтому их условно называют пассивными.

Это вот один прием, который позволяет к новым информационным системам подключать большие блоки данных, которые уже имеются в наличии в какой-нибудь организации

ORB

Второй подход, считающийся современным, — это использование ORB (Object Request Broker). Здесь делается следующее: все массивам информации, которые нам надо подключить условно, организуют объектно-ориентированные оболочки, упаковывают в ОО среду и с помощью ORB (ORB – механизм уже стандартный он находится в CORBA2) обеспечивают доступ вот к такого рода информационным ресурсам, данные которых просто так напрямую перекачать обычно никто не старается. Потому как возможны потери и т.д. и т.д., поэтому вот делают OO оболочку и с помощью ORB обеспечивают доступ.

ODBC, BDE, OCI

Фактически в 92 году фирма Microsoft создала некоторое промежуточное программное обеспечение. Если раньше между клиентом и сервером доступ был напрямую или через специальный драйвер (ORACLE driver…, net2, net3, net8 – начиная с 8 версии ORACLE), то здесь было предложено поставить набор каких-то dll – к, которые могли бы от любого приложения написанного на каком-нибудь универсальном языке с помощью драйверов добраться до любой базы данных.
Первая конкретная реализация была предложена в 92 году фирмой Microsoft, и она называлась ODBC (Open database connectivity). В параллель фирма Borland тоже разрабатывала такой стандарт, он назывался BDE. У них был свой, сперва называвшийся IDAPIA, но к нему подключилось несколько фирм: Borland, IBM, Novell, …и.т.д., — они вот создали аналогичный стандарт. Потом, поскольку первый продвигался от Microsoft, остальные отпали, и Borland остался один и переименовал его в BDE. Потом ORACLE сделала свое – OCI, JDBC (Java DB connectivity). Таких промежуточных средств на сегодняшний день стало много, но все они подходят под стандарт, который утвержден был чуть позже. Сначала появились, так скажем, протоколы и API – промежуточные, а потом появился стандарт. К сожалению, так получилось, что на сегодня стандарт существенно отличается от реализаций и по названиям и.т.д. и т.д. Просто стандарт запоздал. Он хотя опубликован и существует, но ни Microsoft, ни ORACLE, ни SUN, ни Borland – никто подстраиваться под стандарт не стал.
Если мы теперь ставим Windows систему какую-нибудь и ставим там офисное приложение, тогда в панели управления появляется пиктограмма Administrator ODBC, с помощью которого можно подключить к системе любое количество драйверов для доступа к разным базам данных. Как правило, там есть следующий комплект драйверов: к SQL Server, Oracle, Access, WinWord, Paradox, FoxPro и.т.д.

Комментарии запрещены.