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

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

Взять, к примеру, крупного дистрибьютора фармацевтической продукции, открывшего доступ к документации из Web. Используя технологию брокеров объектных запросов (Object Request Broker, ORB), компания предоставила своим торговым представителям доступ к финансовым данным на мэйнфрейме через Web. Теперь они имеют практически мгновенный доступ к информации, на получение которой ранее уходили порой недели. Сообщая заказчикам своевременные и точные данные о товарах, торговые представители повысили эффективность своей работы к собственной выгоде и удовольствию заказчиков.

Internet и Web открывают прекрасные возможности создания новых источников дохода и роста вашей компании. Например, вы можете использовать Web для увеличения своей доли на рынке, однако для этого вы должны предоставить лучшие условия, чем у конкурентов. Прежде чем придумывать новые или совершенствовать старые услуги, установите, что ваши конкуренты уже предлагают или собираются предложить.

После этого вы должны ответить на ряд вопросов. Находится ли необходимая заказчикам информация в ваших унаследованных системах? Если вы станете предоставлять такую информацию через Web, то упростится ли процесс приобретения товаров? Может ли информация, которая вам требуется от заказчиков, быть получена в результате транзакций через Web? Какие новые данные или возможности могут быть предоставлены? Станет ли заказчикам удобнее работать с вами в результате открытия им доступа к информации через Web? Будут ли ваши услуги лучше, чем у конкурентов? Ответы и свои идеи лучше всего проверить, проведя опрос среди целевых групп и предполагаемых заказчиков, чтобы узнать их мнение на этот счет.

Вместо того чтобы переманивать заказчиков у своих конкурентов, вы можете привлечь новых за счет проникновения на существующие рынки с неожиданной стороны. Ища способ привлечь внимание потенциальных покупателей, вы должны задуматься о следующем. Где неохваченные покупатели вашего целевого рынка проводят свое время в Web? Почему они до сих пор не стали вашими клиентами? Есть ли ваша реклама на тех серверах, которые предполагаемые покупатели часто посещают? Какую информацию вы сможете предоставить через Web, чтобы заставить их обратиться к вам?

Другой способ увеличить свои прибыли - предложить совершенно новые продукты и услуги на неохваченных рынках. Если у вас уже есть свое представительство в Web и ваши заказчики о нем знают, то Internet может стать бесценным механизмом для проникновения на новые рынки. Критическим фактором является здесь сведение к минимуму времени представления новых продуктов и услуг. Адаптация унаследованных систем для работы в Web позволит упростить мгновенное предоставление такой информации.

Оснащение унаследованных приложений средствами работы в Web позволяет, с одной стороны, извлечь дополнительную прибыль, а с другой - снизить расходы. Один из подходов состоит в создании самообслуживаемых приложений для поставщиков и заказчиков. Благодаря сокращению нагрузки на сотрудников по предоставлению информации, в результате открытия доступа к ней через Web, энергия и таланты персонала могут быть направлены на оказание более ценных услуг.

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

Вне зависимости от того, на кого направлена ваша инициатива - на поставщиков или заказчиков, - успешная реализация стратегии присутствия в Web требует выполнения определенных условий. Задайте себе следующие вопросы. Имеют ли ваши партнеры соединение с Internet? Есть ли у них браузеры Web и оборудование для их поддержки? Достаточно ли эффективны технологии защиты информации для обеспечения конфиденциальности, аутентификации и целостности данных? Предоставляют ли планируемые для работы в Web приложения особые удобства или другие преимущества при обращении к ним? Чтобы ваши шансы на успех были максимальны, ответ на каждый из этих вопросов должен быть утвердительным. Любой отрицательный ответ может обернуться в конечном итоге провалом вашей попытки адаптации приложений к Web.

Хотя в этой статье основное внимание уделяется адаптации приложений для работы в Internet, та же технология позволяет снизить затраты и при развертывании ее в рамках корпоративной сети Intranet. Например, вы можете адаптировать дорогостоящее программное обеспечение с толстыми клиентами под архитектуру с тонкими клиентами на базе Web. Это позволит значительно уменьшить расходы на сопровождение приложения благодаря централизации администрирования.

Компании с устаревшим оборудованием (например, с компьютерами на базе 486-х или даже 386-х процессоров) могут вообще не иметь возможности перейти к программному обеспечению с толстыми клиентами. В таких средах, где приложения на базе мэйнфреймов и эмуляция терминалов являются нормой, технологии Internet с тонкими клиентами открывают недорогой путь к обновлению программного обеспечения. Если в вашей компании есть такие компьютеры, то рассмотрите возможность перепроектирования громоздких приложений под простые, эффективные и более эстетически привлекательные интерфейсы на базе Web. Снабжение их информацией о том, зачем, когда и как использовать систему, позволит снизить затраты на обучение и сопровождение и повысить производительность.

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

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

Если базовые ориентиры или экономические показатели не разработаны, то придумайте какой-либо способ измерения отдачи. Например, если вы до сих пор не пытались установить, насколько клиенты удовлетворены работой с вашей компанией, то проведите опрос заказчиков после того, как они некоторое время поработают с новым программным обеспечением. Определите абсолютные, а не относительные цели, например получение от пользователей средней оценки 4,5 по пятибалльной шкале. Даже несмотря на то, что вы не можете измерить повышение/снижение степени удовлетворенности пользователей в результате реализации нового программного обеспечения, абсолютная оценка окажется тем не менее полезной.

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

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

ТАБЛИЦА 1 - СВОДКА ПОДХОДОВ К АДАПТАЦИИ МЭЙНФРЕЙМОВ ДЛЯ РАБОТЫ В WEB
Характеристика	Эмуляция терминала	Преобразование экрана	Нестандартное промежуточное ПО	Упаковка объектов	Непосредственный доступ к данным
Низкая стартовая цена	+	-	-	-	-
Малые затраты на техническую поддержку	+	+	-	-	+
Быстрота развертывания	+	+	-	-	+
Удобный пользовательский интерфейс	-	+	+	+	+
Взаимодействие с несхожими системами	-	-	+	+	-
Возможность создания новых сложных функций	-	-	+	+	-
Опора на открытые стандарты	-	-	-	+	-
Простота интеграции в Internet	-	-	+	+	-

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

Если ваша целевая аудитория уже работает или не возражает против работы с эмулируемым терминалом, то такую функциональность имеет смысл предоставить через браузер Web. Учитывая историю и изобилие автономного программного обеспечения эмуляции терминала, преимущества предоставления этой функции через браузер Web имеют не столько технический, сколько административный и финансовый характер. Это экономит время и деньги, так как таким программным обеспечением можно централизованно управлять и предоставлять по требованию. Примерами продуктов эмуляции терминала из браузера могут служить Host-On-Demand компании IBM и OC://WebConnect от OpenConnect Systems.

Если ваши унаследованные приложения достаточно функциональны и вполне приемлемы, за исключением неприглядного пользовательского интерфейса, то они являются хорошими кандидатами на то, что на языке американских технарей называется "губная помада для свиней", или, проще говоря, преобразования экрана (screen scraping). Перехват данных, предназначенных для отображения на дисплее терминала, например потока 3270, и представление экранной информации по-другому - далеко не новый подход. В течение многих лет специальные инструменты помогали разработчикам внести косметические улучшения в приложения на базе терминала посредством представления информации на ПК в более приглядном формате.

Для приложений, не нуждающихся в преобразовании экранного потока, автоматизированное программное обеспечение реального времени, например Arpeggio Live от Wall Data, позволяет создать динамический пользовательский интерфейс на базе Web для приложений на базе терминала. Для более сложных приложений Arpeggio Live позволяет создать собственные презентационные уровни. Конечно, такая настройка требует анализа и разработки, и потому больших вложений.

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

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

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

При использовании промежуточного программного обеспечения клиенты получают доступ к унаследованным приложениям через API. Примерами программного обеспечения, где применяется такой подход, могут служить мониторы обработки транзакций, такие как Tuxedo компании BEA Systems или ориентированное на сообщения промежуточное ПО MQ*Series компании IBM.

Хотя расширение приложений с помощью открытых стандартов предпочтительнее, адаптация унаследованных систем для работы в Web с помощью API может оказаться более эффективной с точки зрения затрат. Возьмем, для примера, крупную распределенную систему ввода заказов, использующую пользовательский интерфейс по типу терминала, и Tuxedo в качестве монитора обработки транзакций. Предположим, что компания хочет предоставить своим клиентам возможность ввода заказов в это приложение через Internet. Кроме того, предположим, что различные категории клиентов в разных частях света имеют свои требования к пользовательскому интерфейсу.

В идеале вы должны будете переделать прикладной уровень таким образом, чтобы он соответствовал открытым стандартам ORB. Однако в данной конкретной ситуации использование нестандартных API Tuxedo и необходимое дополнительное обучение программистов могут оказаться более оправданны с точки зрения финансов. Одна из причин этого - высокая стоимость работ по переписыванию промежуточного программного обеспечения. К счастью, для промежуточного программного обеспечения Tuxedo компания BEA Systems предлагает сервер приложений Java под маркой Jolt, упрощающий использование в Internet нестандартных API компании.

С архитектурной точки зрения наиболее сложным из подходов к адаптации унаследованных приложений для работы в Web является их инкапсуляция в контейнеры объектов в соответствии со стандартной архитектурой брокера

объектных запросов (Common Object Request Broker Architecture, CORBA). C помощью CORBA и Internet InterORB Protocol (IIOP) вы можете расширить функциональность унаследованных приложений, где бы в Internet они ни находились. Эта стратегия оправданна, если сообщество программистов территориально разобщено, а также в случае распределенных вычислений.

Гибкость этого подхода иллюстрирует Рисунок 2, где приложения изображены в виде сфер, где надписи обозначают язык программирования, на котором они написаны. За счет предоставления брокеру объектных запросов доступа к функциям приложения через стандартизованный язык определения интерфейса (Interface Definition Language, IDL), территориально распределенные функции программы могут взаимодействовать друг с другом по Internet. Например, прикладной программист из японского филиала корпорации может на месте написать приложение, использующее функции и данные корпоративного мэйнфрейма в Сан-Франциско.

Рисунок 2.
Инкапсуляция приложений с помощью IDL расширяет их доступность. Например, приложение на C++ в одной части мира может обращаться к функциям приложения на COBOL в другой.

Microsoft предлагает свой конкурирующий подход на базе распределен-ной компонентной объектной модели (Distributed Component Object Model, DCOM); эта нестандартная технология упаковки объектов предоставляет еще один способ расширения унаследованных систем. Для сред, где необходимы и CORBA и DCOM, такие продукты, как VisiBroker for ActiveX Bridge компании Visigenic, позволяют объединить два подхода.

Упаковать унаследованные приложения на COBOL в MVS/CICS для CORBA можно с помощью продукта ORBIX for MVS компании Iona Technologies. Component Broker от IBM позволяет сделать то же самое. Ввиду тесной интеграции брокера объектных запросов IBM с другими средами разработки этой компании, создать IBM-центрическое решение может оказаться проще, чем заставить работать вместе приложения от нескольких поставщиков.

Несмотря на то что упоминание унаследованных систем всякий раз вызывает к жизни образ огромных суперкомпьютеров, подход с упаковкой объектов работает столь же хорошо, если не лучше, и в случае мини-компьютеров. Это возможно благодаря тому, что программное обеспечение брокеров разрабатывалось изначально на и для платформ UNIX, а со временем охватило и Windows NT. Приложения для этих платформ пишутся зачастую на C или C++, а для их расширения с помощью CORBA существует хорошо проработанная и достаточно зрелая методика.

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

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

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

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

Многочисленные шлюзы, от Common Gateway Interface (CGI) до нестандартных интерфейсов типа Netscape's API (NSAPI) или Microsoft's API (MSAPI), позволяют непосредственно считывать и записывать информацию в базу данных. Разработчики баз данных, например Oracle, предоставляют собственные интерфейсы к своему программному обеспечению базы данных.

Какой шлюз выбрать, зависит от множества факторов. Какое программное обеспечение сервера Web вы используете? Каковы требования к его производительности? Должно ли решение быть масштабируемым? Более простой и открытый подход с использованием CGI упрощает задачу программиста, правда, в ущерб масштабируемости. Применение MSAPI или NSAPI позволяет достичь лучшей производительности и масштабируемости, но при этом вы окажетесь зависимы от конкретного сервера. Фирменные шлюзы к базам данных имеют максимальную производительность и масштабируемость, но они работают только со своими специфическими базами данных. Выберите подход, с помощью которого вы сможете добиться максимальной отдачи, исходя из ваших конкретных обстоятельств и требований.

К счастью, требования к сети для адаптации унаследованных приложений для работы в Web достаточно просты: это должна быть сеть TCP/IP. Если вы используете вспомогательный сервер для брокера объектных запросов и упаковки объектов или промежуточного программного обеспечения, например Tuxedo, то TCP/IP должен связывать клиента и сервер среднего звена. Если ORB выполняется на хосте, то TCP/IP должен использоваться на всем пути до хоста. Шлюзов из TCP/IP в SNA имеется в избытке, так что операторам вашего хоста остается только выбрать наиболее подходящий для вашей среды продукт.

С учетом разработки клиентского приложения максимальная гибкость обеспечивается архитектурой упаковки объектов CORBA. При таком подходе клиентский код может быть написан практически на любом языке программирования, но в последнее время наибольшей популярностью при разработке приложений для Web пользуется Java. Наверняка вы уже наслышаны о таких достоинствах этого языка, как переносимость и удобство использования. Прикладной уровень может быть написан на Java независимо от того, на каком языке написан клиентский уровень, поэтому вопрос языка программирования для клиента сводится к выбору между сложностью пользовательского интерфейса и широтой доступа. Java блокируется многими корпоративными брандмауэрами, так что написание интерфейса на Java может отрезать значительную часть вашей целевой аудитории.

Используя такую технологию, как Web Request Broker компании Oracle, вы можете создать презентационный уровень HTML для взаимодействия с прикладным уровнем во многом на тех же принципах, что и для клиентов Java. Конечно, пользовательский интерфейс ограничен графическими компонентами HTML. Для пользователей, привыкших к метафорам пользовательского интерфейса в таких языках, как C++ и Java, подобное ограничение может явиться значительным разочарованием. Поэтому если ваша целевая аудитория имеет или собирается иметь браузеры Web, то рассмотрите возможность использования Java для создания эффектного и эффективного пользовательского интерфейса.

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

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

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

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

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

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

Выберите архитектуру и технологию, отвечающие на сегодняшний день потребностям ваших внешних пользователей и имеющие достаточную гибкость для интеграции впоследствии дополнительных функций. Простейший подход к адаптации унаследованных систем для работы в Web состоит в эмуляции терминала из браузера Web. Более затейливая версия этого подхода, динамическая Web-интерпретация терминальных потоков, приятнее для пользователей с эстетической точки зрения. Если в вашей среде уже используется промежуточное обеспечение независимых производителей, то вы можете воспользоваться API для расширения функциональности унаследованных систем. Если вы имеете или предвидите возможность обширной адаптации к Web, то не бойтесь вкладывать средства в инкапсуляцию унаследованных систем с помощью упаковщиков объектов на базе CORBA.

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

Рич Ниебаум - технический эксперт в c2o Interactive Architects. С ним можно связаться по адресу: rniebaum@c2o.com.

Ваш мэйнфрейм в Web: насколько вы готовы к этому? Адаптация унаследованных систем к Web открывает отличные перспективы развития бизнеса, но только при определенных условиях. Чем точнее выполняются следующие условия, тем больше шансов на успех.