Извлеки максимум пользы из старого кода

Сервис-ориентированная архитектура становится все более популярным подходом для построения новых корпоративных систем. К концепции SOA более или менее привыкли, она теперь понятна широкому кругу руководителей, и ее разработка теперь не представляет особой сложности для программистов и почти также элементарна как, скажем, разработка традиционного приложения для настольной системы или программных пакетов на основе браузеров. Итак, SOA – это как раз то, что вам нужно. Но, тем не менее, не все так просто. К сожалению, если технология кажется слишком уж безупречной, чтобы быть правдой, значит в ней на самом деле есть недостатки. А главный недостаток столь прогрессивных и популярных SOA-технологий в том, что нам приходится разрабатывать приложения нового поколения в среде, сплошь изобилующей устаревающими приложениями 1980-1990 гг., создателям которых вряд ли могло даже прийти в голову, что появятся такие протоколы как SOAP/WSDL! Таким образом, мы сталкиваемся с необходимостью интеграции разрабатываемых нами приложений нового поколения и уже существующих (т.е. унаследованных) систем и данных.

Важные аспекты унаследованных данных

При создании новых приложений, которым суждено слаженно функционировать с унаследованными, необходимо учитывать следующие аспекты:

• Обеспечение доступа к данным
• Извлечение данных из приложения
• Преобразование унаследованных данных в том виде, в котором они существуют, и отображение их в новом виде, применимом к SOA

Унаследованные компьютеры и сети

Проблемы начинаются уже на этапе получения физического доступа к системам, в которых хранятся унаследованные данные. На самом деле, это совсем не так просто, как кажется. На сегодняшний день еще довольно много компаний, в которых используются разнородные и несовместимые системы разных мастей, которые никто никогда не пытался объединить. Например, финансовые системы типа «эстафетное кольцо» или системы CAD, основанные на стандарте FDDI, и сеть Ethernet. Таким образом, перемещение данных из пункта А в пункт Б дело далеко не простое.

Самое простое в данной ситуации – вывод из эксплуатации старых систем и приложений. Предварительно осуществляется одноразовый экспорт данных из них. Для этой цели вы можете использовать диск, магнитный накопитель или любое другое средство, предназначенное для хранения информации. Все что вам нужно – это импортировать ваши данные на такой носитель, который бы без труда воспринимался новой системой (оптимальный вариант – если вы сможете изъять этот накопитель из старой системы и встроить его в новую) или привлечь специалистов, способных преобразовать данные, которые вы экспортировали, и сделать их понятными для новой системы.

В большинстве случаев, однако, задача не ограничивается только импортированием данных. Гораздо чаще все же предпочитают устанавливать связь между старой и новой системами с целью их многократного использования. А это значит, что нужно создать некий межсетевой шлюз, который бы сыграл роль связующего звена между старой и новой системами. Если это входит в ваши планы, то вам надо задуматься о двух вещах:
• Оперировании унаследованными данными в условиях сервис-ориентированной архитектуры
• Сетевых протоколах (третьего уровня), воспринимаемых обеими системами

В идеале все выглядит довольно просто: если вы работаете в сети Ethernet, а старый финансовый сервер базируется на сети Token Ring, но фактически является частью системы Net Ware сервера x86, то вам надо просто установить на сервере сетевую карту Ethernet (или установить сетевую карту Token Ring в систему новой сети). Тем не менее, иногда бывают случаи, когда не получается свести все системы к общим характеристикам. В этих случаях необходимо установить специальное устройство – межсетевой шлюз, который станет своеобразными воротами между двумя параллельными мирами.

Какой тип межсетевого шлюза выбрать, зависит от степени несовместимости систем. Случается, что системы несовместимы только на уровне физических сетевых возможностей, т.е. вы не можете подсоединить их к системам Token Ring, PCNet, LockalTalk, packet radio, 100VG-AnyLAN, и т.д.). А бывает и так, что обе системы не могут воспринимать протоколы третьего уровня друг друга. Скажем, если обе системы способны воспринимать протокол IPX, но физически эти системы несовместимы, вам нужно просто приобрести маршрутизатор (или создать его - операционная система Linux имеет больше возможностей для маршрутизации и сетевой поддержки унаследованных систем) для преобразования сообщений. Если же вам не удалось найти такой протокол третьего уровня, который бы воспринимался обеими системами, вам придется приобрести или разработать более сложное устройство – сетевой шлюз, наделяющий системы способностью преобразования протоколов третьего уровня с целью сделать их понятными для разных систем.

Унаследованные приложения

Если вы сумели обеспечить взаимопонимание систем, то вы уже почти решили проблему, точнее, ее технологическую часть. Дело осталось лишь за малым – получить доступ к данным. Пока у вас есть доступ только к машинам.

Получить доступ к данным можно двумя способами. Первый способ заключается в получении прямого доступа к файлам на дисках через какой-нибудь протокол обмена файлами (SBM, FTP, AppleShare, NFS, …) и извлекать их в том виде, в котором они существуют в системе. В этом случае можно сразу перейти к пункту «отображение данных», который вы найдете ниже. Второй способ подразумевает работу непосредственно с приложением, обычно через его программный интерфейс или процессы экспортирования/импортирования, или через какую-то его часть.

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

Отображение данных

Теперь, когда у вас есть физический доступ к данным, остается сделать последний, с технической точки зрения, самый легкий шаг, хотя он может потребовать от вас больших временных затрат, связанных с тестированием, и вовлечения в процесс большого количества человеческих ресурсов. Речь идет о разработке средств отображения данных, т.е. их преобразования в новый формат. Процесс отображения может быть как однонаправленным (когда новая система только считывает данные с унаследованной системы или записывает их туда) и двунаправленным (когда вам приходится преобразовывать старое в новое и новое в старое). Здесь не избежать компьютерных сбоев в программе, связанных с различием форматов данных, величиной потоков (их длина может оказаться нормальной для машины А, но слишком большой для машины Б) и другими «фокусами-покусами». Самое «забавное» заключается в том, что встречаются, и довольно часто, такие структуры унаследованных данных, которые изначально (т.е. с момента их создания) не были нормализованы. Скажем, вместо того, чтобы просто учитывать сделанные покупки, система учитывает все данные о покупателях, совершивших каждую покупку. Совершенно логично, что в этом случае и отображение данных тоже не пройдет без сюрпризов.

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

Следует особо оговорить и то, что совершенно не обязательно, что то, чего хочет добиться организация, вообще осуществимо. Проект по интеграции унаследованных систем должен быть двунаправленным, подобно улице с двусторонним движением, так что вместо того, чтобы говорить: «Нам нужно уметь по требованию извлечь сведения об уровне запасов из системы X», правильнее сформулировать задачу так: «Выяснить, есть ли способ сделать так, чтоб можно было по требованию извлекать сведения об уровне запасов из системы X». Иногда то, что мы хотим, неосуществимо.

Давайте рассмотрим все выше сказанное на примере. Допустим, нам нужно интегрировать систему оперативного учета в новое ПО обработки данных. Единственное, что можно сделать – это обеспечить автоматическое экспортирование данных по расписанию и скачивать их в хранилище, откуда они могут быть получены. В то время как изначально интеграция была задумана для того, чтобы новая система ПО могла посылать запросы старой системе в интерактивном режиме. Однако осуществить это не представлялось возможным в силу ограниченности бюджетных средств, поэтому пришлось искать компромиссное решение. Подобные ситуации поиска компромиссных решений весьма широко распространены, очень важно понимать, что не все может быть осуществимо в силу ограниченности ресурсов, которыми мы располагаем.

Каким образом все это применимо к SOA?

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

Преимущество SOA по сравнению с другими архитектурами в том, что интеграцию унаследованных систем можно рассматривать как просто интеграцию еще одного сервиса (или, скорее, набора сервисов) в архитектуру. Вы просто представляете унаследованные системы в виде сервисов и интегрируете их с новыми сервисами, либо используете специальные сервисы для интеграции унаследованных систем. А выполнением конкретных технических задач, таких как извлечение данных из унаследованных систем или отправление данных в унаследованные системы, занимаются непосредственно сами сервисы. Подобно другим сервисам, они предоставят свои интерфейсы приложениям, используемым организацией. Разработчики бизнес-логики могут обращаться к этим абстрактным интерфейсам, при этом не требуется наличия каких-то специальных знаний (в принципе, для этого вообще не нужны никакие знания).

Преимущество осуществления интеграции унаследованных систем на базе SOA проистекает из того, о чем мы уже говорили – из получения физического доступа к основанным на ней системам. Так, если вы пишете настольное приложение для унаследованной системы, вам надо снабдить каждый ПК средствами связи с ней, что может оказаться невозможным, если унаследованная система не может напрямую взаимодействовать с корпоративной сетью. Если вы пишете клиент-серверное приложение, вам надо обеспечить сервер средствами связи с унаследованной системой, которые могут либо спровоцировать перегрузку сервера, либо замедлить его работу за счет того, что будут заставлять сервер делать запросы к внешнему сетевому шлюзу. В условиях среды SOA, этот межсетевой интерфейс превращается в еще один сервис, возможно, он даже выполняет какие-то совместные функции с другими физическими сервисами. Все это облегчает доступ клиентского приложения к данным унаследованной системы, при этом ни в коей степени не усложняя клиентскую систему ни на уровне техники, ни на уровне ПО.

По материалам сайта www.techworld.com

Комментарии