Метод создания промежуточного ПО - эмулятора доступа к устаревшей системе

Метод эмуляции или иммитации работы системы для каких-то внешних по отношению к ней систем стар как мир компьютеров (и не только). Начиналось это еще с эмуляции терминалов к мэйнфремам. Сейчас он запечатлен, например, в стандартах взаимодействия открытых систем (ISO OSI - Open Systems Interaction), в драйверах доступа к внешней аппаратуре из ЭВМ, в протоколе доступа к SQL-ориентированным базам данных (ODBC - Open Data Base Connectivity), многочисленным шлюзам к
унаследованным базам данных и др.

В [21] описан типичный пример ситуации миграции к новой системе. Предположим, что вы хотите интегрировать вашу систему с устаревшей системой бухгалтерского учета. Документации на интерфейс нет, и все необходимые сведения придется черпать из системы, которую мы заменяем. Из этого положения можно выйти слеующим образом:

1. Приобрести новый пакет бухгалтерского учета. К сожалению, существующим пакетом пользуются и другие системы фирмы, поэтому это будет само по себе серьезным проектом
2. Взять интерфейсные модули бухгалтерского учета непосредственно из старой системы и максимально их использовать
3. Разработать ПО промежуточного уровня, работающее между приложением и пакетом бухгалтерского учета (эмулятор доступа). Прикладное ПО производит простые и четко определенные вызовы этого ПО. ПО промежуточного уровня превращает такой вызов в вызов системы бухучета. Это ПО можно разрабатывать отдельно от основного приложения. Если будет приобретен новый пакет бухучета, нам придется лишь переписать программы промежуточного уровня, поскольку наши приложения полностью изолированы от внутренних механизмов бухгалтерских программ (инкапсуляция доступа).

Авторы книги рекомендуют 3-й вариант как наиболее гибкий и эффективный. Как развитие идеи ПО промежуточного уровня к настоящему времени разработано несколько промышленных стандартов, поддерживающих эту архитектуру. Наибольшым успехом в среде разработки крупномасштабных распределенных ИС на сегодня (и на ближайшее будущее) пользуется OMG CORBA. В проектах малых и средних размеров сегодня более популярен Microsoft COM+ (не путайте с COM (Core Object Model) - ядром объектной модели у OMG!). Более подробно эти стандарты будут описаны ниже. Можно еще отметить, что в войне этих двух подходов достигнуто небольшое перемирие: созданы шлюзы для взаимодействия объектов из этих разных систем. Возможно возникновение и некоего общего стандарта по взаимодействию (как это было сделано, например, во 2-й версии CORBA: был создан GIOP - единый протокол для общения ORB (Object Request Broker) разных производителей).

Еще одним следствием эволюции подхода ПО промежуточного слоя стал компонентый метод разработки ПО. Это когда каждый модуль системы представляет из себя полностью автономный компонент, имеющей для доступа к себе некий стандартный API (Application Programming Interface). Причем, компоненты эти при определенных обстоятелствах (когда возможна совместимось) могут быть написаны на разных программных языках. В связи с бурным развитием распределенных (по разным ЭВМ) систем этот метод получил широкое распостранение. В объектном подходе такие компоненты рассматривают как распределенные по сети объекты. Приемущества описываемой архитектуры в черезвычайной гибкости и масштабируемости получаемого на ее основе ПО.
Эволюция данного подхода будет рассмотрена немного ниже.