Мнение IDC
Что такое стратегии IBM в континууме разработки приложений?
Периодически необходимо определять место разработки приложений (AD) в общем контексте. Слишком часто наше стремление упрощать и наша неспособность охватить все не позволяют нам постичь и понять отдельные объекты. Континуум AD является одним из таких объектов. Все разработчики инструментария поддерживают некоторые части континуума AD, но как мы определим этот континуум, и какая поддержка этого континуума будет достаточной? Хотя ответы могут быть даны только на часть этих вопросов, может явиться открытием тот факт, что только один производитель серьезно относится к тому, чтобы полностью покрывать континуум AD. Этот производитель - IBM.

Введение

Много было сказано и написано по проблеме 2000 года (Y2K) - в основном о хаосе, который может случиться в компьютерных системах и о больших вложениях, которые должны быть сделаны, чтобы предотвратить его. Хотя проблема Y2K действительно серьезна, есть и "луч света в темном царстве" Y2K. Часто говорят, что каждая экстремальная ситуация предоставляет удобный случай, и Y2K - не исключение. Проблема Y2K - фактически является катализатором, который позволяет организациям информационного сервиса (IS) восстановить свою лидирующую роль в формировании, продвижении и воплощении стратегии информационных технологий (IT). Вопросы, связанные с Y2K, должны позволить организациям IS привести в порядок их хозяйства. Впервые в компьютерную эпоху многие организации IS должны по-настоящему выполнить детальную инвентаризацию приложений, на которых годами выполнялся их бизнес. IS подталкиваются к достижению значительно более высокого уровня понимания портфеля приложений как необходимой предпосылки, гарантирующей погашение эффекта Y2K. Но что более важно, так это то, что высшее руководство должно теперь рассматривать уже имеющиеся, унаследованные программные приложения как активы в бизнесе. Итак, проблема Y2K должна дать высшему руководству возросшее понимание ценности унаследованных приложений и одновременно обеспечить более всестороннее понимание этих приложений IS-организациями. Замечание, определяющее унаследованные системы как активы, является важной концепцией, которая позволит организациям рассматривать более широкий набор альтернативных стратегий для развития их инфраструктур IT и лучше распределять вложения в IT. Поэтому неудивительно, что в последние годы IBM делала большие вложения в расширение инфраструктуры AD, связанной с S/390, чтобы обеспечить сохранение ценности S/390 в 21-м столетии.

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

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

Каждое из 3M на рис.1 занимает область, характеризуемую атрибутами дескрипторов. Трапециидальные области каждого основного подхода к AD отражают их ориентацию и связь с атрибутами дескрипторов. IDC определяет 3M следующим образом.

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

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

Хотя в миграция сосредотачивается на разработке новых, распределенных приложений, термин миграция имеет сохранять смысл из-за важности создания таких новых приложений, которые обеспечивают более всеохватывающую поддержку бизнес-правил, характерных для организаций, многие из которых были ключевыми и в уже существующих приложениях. Следовательно, хотя этот подход к AD порождает новые технологии для поставки приложений со значительно улучшенной функциональностью и производительностью, и возможностью автоматизировать более широкий набор процессов бизнеса, эти процессы часто имеют высокую степень стабильности.
Типичные подходы к этому атрибуту AD включают в себя явный упор на высокоструктурированные приложения, высокую надежность сервиса инфраструктуры и использование каркасов (framework) для выполнения быстрых, но структурированных разработок сложных приложений и действительной интеграции их с унаследованными приложениями (не только интероперабельности). Следует указать, что все эти подходы сосуществуют с AD для e-business.
Миграция поддерживает новую реализацию кода или бизнес-правил. Это может повлечь за собой новую реализацию бизнес-правил, то ли в ER-виде ("сущность-связь"), то ли преобразованных в более современный язык (скорее всего - на базе ОО подхода, лучше всего - Java) язык. Возможно, более интересный подход, обеспечивающий наибольшие долговременные выгоды, - конструирование новых приложений из модульных компонентов, разработанных в ходе фазы модуляризации. Это называется разработкой на базе компонентов (CBD). Что может быть лучше, чем применять эту совершенную парадигму AD для подъема унаследованных активов корпорации?

Теперь мы имеем форму для классификации и понимания подходов к AD, но что это означает для производителей инструментов AD?
Возможно, наиболее интересной находкой является то, что производители, которые поддерживают полный континуум AD, обеспечивают уровень полезности, который увеличивается в соответствии с увеличением размера организации. Следовательно, всесторонняя поддержка производителей полного континуума AD является ключом в потребностях больших организаций, обеспечивая большую гибкость AD (результат чего - в более экономичном AD) и лучшую защиту вложений в программное обеспечение.
Количество производителей, обеспечивающих всестороннюю поддержку AD, поразительно мало. IBM благодаря своему акценту в последние два года на привнесение ключевых способностей AD во все три области континуума AD, сейчас является лидером в AD для больших организаций. Хотя стратегия IBM в AD и неполна, она превосходит фактически всех других производителей широтой и полнотой ее поддержки AD для больших организаций.

По некоторым оценкам, более 2/3 данных во всем мире размещены на серверах IBM, главными из которых являются S/390. Это означает, что IBM должна больше всех приобрести или потерять от "подъема" существующих приложений (и аппаратуры, на которой эти приложения выполняются). IBM сталкивается с этой ситуацией "лоб в лоб" и разработала убедительный и интегрированный ответ на нее.
Вполне понятно, что предсказания близкой кончины мейнфреймов - перефразируя Марка Твена - были весьма преувеличены. В современной компьютерной среде для этой технологии остается место - и не только для размещения унаследованных приложений. IBM позиционирует S/390 как составную часть своей общей инициативы в e-business.
Почему используется S/390 для приложений e-business? Очевидный ответ - как серверы данных в n-уровневых распределенных приложения, но это еще не вся история. У S/390 выработалась за много лет стойкая репутация наиболее крепкой платформы, обладающей всеми свойствами, которые требуются для больших и средних предприятий (надежность, сопровождаемость, масштабируемость, функциональная полезность, расширяемость). Вдобавок IBM имеет сильную схему управления системами с мейнфреймами в центре - через свои продукты Tivoli и поддержку третьих фирм.
Оценка деятельности по консолидации данных наводит на мысль о том, что предприятия понимают и хотят получать выгоды, вытекающие из поддержки меньшего числа чрезвычайно мощных и надежных серверов. Этот подход к серверам в сочетании с нынешним упором IBM на средства разработки фактически подразумевает продолжающийся рост S/390. В следующем разделе оцениваются продукты AD-инструментария IBM и инициативы в континууме AD.

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

Этот взгляд, хотя и варьируется от предприятия к предприятию, тяготеет к некоторым общим характеристикам, включая:

• ориентация на Internet в различных формах;
• многоуровневые реализации;
• компоненты программного обеспечения.

В течение нескольких следующих лет большинство организаций будет строить такие инфраструктуры IS, которые будет включать в себя Internet (а фактически - строиться вокруг нее). Это - фактически главная возможность для стратегий e-business, принятых большинством организаций. От предоставления клиентам возможности доступа к существующим корпоративным данным и функциональным возможностям приложений будет получена большая отдача.

Даже теоретически, не принимая во внимание решения для e-business, требования реализаций, больших, чем простая двухуровневая модель клиент/сервер, - это преимущества отделения бизнес-логики от конечных источников данных и приложений, которые являются основой традиционных инфраструктур IS и платформой, на которой размещены унаследованные активы. Типичный трехуровневый сценарий подразумевает: ряд клиентов (на базе броузеров или др.), сервер или серверы приложений на среднем уровне (которые в конфигурациях на основе Web могут быть подключены к Web-серверу) и унаследованный уровень конечного пользователя. В некоторых случаях может быть реализован и четвертый уровень, функции которого полностью сосредоточены на доступе к имеющимся данным. (Эта возможность в общем просматривается в решениях, предоставляемых производителями СУБД и инструментов для интеграции данных на сервере с использованием таких стандартных техник, как JDBC).

Преимущества от использования компонентов ПО теперь хорошо известны. Они включают в себя потенциалы многократного использования, повышения качества приложений и увеличения продуктивности разработки. Преимущества компонентов, ориентированных на данные - лишь малая часть в общем объеме - также хорошо известны. Хотя концепция компонентов дает значительные преимущества, но само введение в культуру организации и образ мыслей разработчиков изменений, требующих полного использования этой парадигмы, может требовать трудной адаптации. Этот феномен похож на опыт внедрения в организацию использования объектов, но несколько факторов должны сделать разработку и внедрение на базе компонентов более привлекательным вариантом. Во-первых, компоненты в общем случае - более крупные частицы, чем объекты (хотя это не строго обязательно) и могут легче быть соотнесены с процессами и функциями бизнеса. Во-вторых, многоуровневые реализации с Internet в центре фактически требуют компонентного подхода. Функции приложений представлены клиентам на базе броузеров с использованием компонентов, выгруженных с сервера среднего уровня, и, с приходом Enterprise JavaBeans (EJB), приложения и бизнес-логика на самом сервере становятся компонентами.

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

Большинство задач Y2K или Euro включают в себя инвентаризацию существующих портфелей приложений, нахождение и коррекцию зависимых кодов и данных (этот процесс называется лечением), тестирование и отладку излеченных приложений. Хотя согласование с Y2K вообще рассматривается как тактическая проблема (т.е. нечто, требуемое на короткое время, чтобы сохранить работоспособность бизнеса), в нем могут быть и долговременные выгоды, не последние из которых - установление контроля над пакетом приложений и достижение некоторого уровня в понимании унаследованных данных и кодов. Это важные элементы в построении фундамента для миграции наследства.
Более того, процесс Y2K имеет сильный потенциал для повторного использования. Некоторые инструменты, использованные для Y2K, и последующего тестирования могут быть вновь применены в ходе модуляризации. Таким образом, инструменты, использованные для Y2K, применимы для тестирования модульных компонентов.
IBM ранее всех предвидела Y2K и продолжает оставаться главным производителем инструментов и сервиса Y2K. Она предлагает много инструментов для задач Y2K и Euro. Некоторые из них кратко рассматриваются здесь, но главное влияние Y2K и Euro на IBM - полученные компанией знания и понимание. Они могут быть хорошо использованы в установлении стратегии компании по трансформации унаследованных продуктов.

IBM OPTI-AUDIT полезен на инвентаризационном и оценочном этапах проектов Y2K. Он помогает сканировать исходные файлы COBOL'а для нахождения полей даты и может быть также использован для определения активных программ, процедур и наборов данных VSE. Функция анализа COBOL'а сканирует библиотеки VSE/ESA и вырабатывает схему перекрестных ссылок фаз COBOL'а с используемыми подпрограммами.

IBM's VisualAge Millennium Language Extension (MLE) - лечебная технология для коррекции проблемы даты 2000 года. Коды, отображающие дату, генерируются непосредственно языковыми компиляторами, это устраняет необходимость вручную добавлять логику для каждого появления в программе переменных, чувствительных к 2000 году.

Передовая позиция IBM в обработке транзакций в значительной степени является результатом полезных возможностей, обеспечиваемых IMS и CICS в среде MVS. Хотя IMS начинает уступать дорогу DB2, IMS продолжает иметь большую и стабильную базу инсталляций и, кажется, в сочетании с CICS и MVS не имеет себе равных в поддержке крупномасштабной OLTP.
Отдавая должное своей большой и верной базе инсталляций, IBM решила обеспечить некоторые ключевые возможности модернизации для IMS и CICS. Согласователи IMS и CICS являются компонентами с клиентской стороны, которые позволяют легко отобразить транзакцию в определенные новые среды.

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

Два типа согласователей интерфейса поддерживается для CICS - Внешний Интерфейс Презентации (EPI) и Внешний Интерфейс Вызова (ECI). EPI позволяет не-CICS приложению рассматриваться сервером CICS как терминал 3270. ECI позволяет не-CICS приложению обращаться к программе CICS на сервере CICS. Эти согласователи позволяют многим новым классам устройств быть оконечными для существующих CICS-систем и обеспечивают ключевые возможности интероперабельности в Web.

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

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

IBM ясно представляет, что выделение бизнес-правил является ключом для миграции или переработки унаследованного кода. Здесь используется термин самоанализ логики. После того, как определены бизнес-функции, которые должны быть компонентами, используется инструмент VisualAge COBOL для выделения относящихся к ним кодов и последующего конструирования бизнес-объектов Enterprise JavaBean. Шаги этого процесса следующие:

1. Самоанализ существующего унаследованного кода для выделения ключевых бизнес-модулей. IBM и NetWest (покупатель и бизнес-партнер IBM) разрабатывают инструменты для самоанализа, которые будут реализованы в1999 году.
2. Для сопровождения, коррекции и исправления существующего кода используется VisualAge COBOL.
3. Для выполнения отдельного и комплексного тестирования выделенных модульных компонентов используются средства тестирования IBM, такие как ATC и ARTT.
4. VisualAge for Java создает EJB-оболочку вокруг новых выделенных бизнес-модулей, собирая эти компоненты в новое приложение.

Адаптеры приложений являются следующим за переработкой приложений звеном в цепочке. Целью этих адаптеров является обеспечение интероперабельности между приложениями и определенными процессами бизнеса (например, SAP). Фактически, адаптеры являются новым слоем бизнес-объектов, который помогает координировать интеграцию приложений. Когда с использованием этого выполняется согласование один-к-одному, результатом и является адаптер. Более общая форма согласования, которая поддерживает соединение многие-ко-многим, требует значительно более сложной инфраструктуры классов и возможности управлять последовательностью и согласовывать многие приложения и различия между системами. Это в полном объеме - свойства Component Broker, который описывается в разделе "Миграция" этой статьи.

Единая программная модель IBM - это попытка предельно упростить AD путем сокращения количества API, которыми должны пользоваться разработчики. Хотя этот процесс имеет преимущества для разработчиков, он отражает и другой слой - хотя и более прозрачный - результат наличия широкого спектра средств разработки, которые были спроектированы в разное время. IDC надеется, что со временем IBM придет к упрощению этой внутренней архитектуры, но пока единая программная модель является прагматическим решением исторически расплодившихся различных API. IBM будет использовать Application Framework для e-business, чтобы упростить эту архитектуру.

IBM выступает в мире CBD со своим семейством продуктов VisualAge и, более всего, VisualAge for Java. Первая версия VisualAge for Java была сама по себе мощным продуктом, комбинирующим интуитивно понятный пользовательский интерфейс со средой разработки, которая обеспечивает интегрированное рабочее пространство для разработки, тестирования и отладки.
Одним из наиболее значительных свойств VisualAge for Java было то, что IBM называет Промышленные Конструкторы Приложений (EAB). EAB были введены для упрощения процесса распространения промышленных данных в Web без необходимости кодирования middleware. В сущности, EAB генерирует обычные компоненты JavaBeans, которые обеспечивают ображение к middleware вместо того, чтобы заставлять разработчиков вручную кодировать различные API, появляющиеся в задаче. Изначально EABs включали в себя JDBC, ODBC, CICS, RMI и др., а в VisualAge (for Java) 2.0 этот список расширился включением SAP (через BAPI), CICS(EXCI), CICS(EPI) и, возможно важнее всего, IIOP (что означает что компоненты и приложения, построенные в VisualAge for Java взаимодействуют с ORB CORBA так же хорошо, как и с IBM Component Broker). Введенный в феврале 1998 года VisualAge for Java Enterprise edition продолжает развитие концепции EAB улучшением среды разработки, более эффективной поддержкой командной разработки и других рядом усовершенствований. Таким образом, с VisualAge for Java Enterprise edition, где содержится EAB, разработчики могут получить доступ к унаследованным бизнес-модулям и оформить их как компоненты Enterprise JavaBeans.

VisualAge Generator разработан для удовлетворения нужд в инструментах промышленного класса с различными свойствами RAD для построения бизнес-ориентированных приложений. VisualAge Generator содержит ряд интересных высокоуровневых свойств, которые позволяют ему эффективно конкурировать на рынке промышленных средств разработки. Однако, этот рынок продолжает сужаться из-за амбициозных свойств его продуктов, их сложности и конкуренции со стороны производителей серверов приложений, которые утверждают, что предлагают более открытый и компонентный подход к построению многоуровневых приложений. Несмотря на это, VisualAge Generator сохраняется благодаря тому, что занимает ключевую нишу в семействе VisualAge. Более того, VisualAge Generator - очень хороший путь построения новых транзакционных приложений для S/390, потому что он оптимизирован для CICS, IMS и DB2 и скрывает сложность от программиста.
Интеллектуальные свойства, такие как разработка многоуровневых приложений, эвристическое разделение, поддержка широкого спектра служб middleware, моделирование данных, поддержка Web-клиентов и генерация кодов приложений на C++ или COBOL, отличают VisualAge Generator от соответствующих средств 4GL RAD.
Хотя VisualAge Generator уже заполнил рынок промышленных средств разработки по самую ватерлинию, он продолжает быть незаменимым для разработчиков сложных приложений, которые ищут более высокого уровня продуктивности и автоматизации разработки.

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

За последние 4 года Java уделялось чрезвычайно большое внимание. Имеет смысл вернуться к вопросу, который мы ужерассматривали: Java, по его определению, имеет потенциал для обеспечения и полезного, и эффективного стандарта как для компонентной модели, так и для многоплатформенных решений. В большей части своей короткой истории Java, однако, был явлением клиентской части. Большинство вложенных в Java усилий были направлены на построение аплетов и компонентов для обслуживания Web-клиентов. Java выглядел (и с некоторыми расширениями продолжает выглядеть), как решение проблем, связанных с HTML, наиболее важная из которых √ необходимость перекачки всей Web-страницы каждый раз, когда в ней изменяется даже единственный незначительный элемент.
На практике, однако, Java не стал таким спасителем, каким он был заявлен. Причина этого по большей части в различиях, сохраняющихся в JVM и Web-броузерах, которые затрудняют достижение совместимости между собой. Хотя на этом пути и прилагаются значительные усилия, Java клиентской части несколько разочаровал.
Но при этом (возможно, и поэтому) использование Java на серверной стороне (т.е. на среднем уровне -сервере приложений) получило значительный толчок в последние годы. Поскольку организация "владеет" своими серверами как частью своей IS инфраструктуры, она может установить более жесткий над тем фундаментом, на котором существуют ее Java-компоненты. Также справедливо то, что модель компонентов Java привлекательна как стандарт для компонентов, позволяющий "наследству", включая источники данных и приложения, совмещаться с остальным современным, многоуровневым окружением.

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

• любой класс Java (включая и полную библиотеку классов) может легко стать распределенным классом. Благодаря транзакционности и безопасности, обеспечиваемым в контейнерной спецификации, эти классы доступны в сети безопасным и надежным образом.
• критическим для завершения эффективной интеграции унаследованных данных (в основном реляционных данных) является способность навести мост через пропасть между старыми источниками данных и объектной парадигмой, реализованной на сервере среднего уровня. EJB достигает этой цели и позволяет пользователям заставить любой источник данных выглядеть как коллекция Java-объектов. Вся информация в этом источнике данных, включая возможность инкапсулировать SQL-запросы в Java-объекты, доступна через Java-объекты.

Параллельно с совершенствованием продукта VisualAge for Java IBM также ввела семейство продуктов WebSphere (WS). WebSphere - попытка IBM предложить полностью всеохватывающее решение для разработки и внедрения промышленных решений на базе Web. Среда WS включает в себя три главных компонента:

• WebSphere Studio. Эта среда поддерживает разработку и внедрение Web-приложений. Она включает в себя VisualAge for Java, Professional edition (EAB), NetObjects Fusion, ScriptBuilder, и BeanBuilder (объединяющие разработку HTML, внедрение и управление сайтом). Также включает в себя большое количество Web Workbench и Servlet Wizard для просмотра, редактирования и управления содержимым Web-сайта.
• WebSphere Application Server. Это сервер IBM среднего уровня, который служит точкой интеграции существующих приложений и данных. Он обеспечивает инфраструктурную основу для внедрения компонентно-базированных решений, разработанных с использованием WebSphere Studio и других сред разработки. Включает два Web-сервера - Apache и Domino Go. Apache выполняется на разных Unix-платформах и NT, Domino Go выполняется на разных платформах, включая S/390.
• WebSphere Performance Pack. Этот пакет включает в себя кэширование, балансировку загрузки, управление распределенными файлами, а также поддержку Tivoli для централизованного управления приложениям.

Component Broker, который предшествовал WebSphere на их рынке примерно около года, был в действительности более универсальным продуктом с более широкими и масштабируемыми предложениями, чем начальный вариант (ныне - Standard Edition) WebSphere. Он представляет ОО программную модель как основу его распределенной вычислительной архитектуры в комбинации с расширяемым каркасом бизнес-объектов и объектных служб. IBM развивает Component Broker как средство внедрения распределенного объектного подхода в приложения и данные на мейнфреймах (Component Broker основывается на CORBA с точки зрения middleware). В этом смысле IBM создала версию Component Broker для S/390, которая играет роль монитора транзакций (подобно CICS и IMS).
На рынке была некоторая путаница с позиционированием WebSphere и Component Broker, которые, как кажется на первый взгляд, решают одну и ту же задачу. Ответом IBM на эту путаницу было (в прошлом) позиционирование WebSphere как более Web-ориентированного, и простого предложения (что означает меньший масштаб и меньшее "богатство сервиса" в терминах транзакционности и некоторых других функций); если же пользователи готовы, то Component Broker обеспечит им путь миграции для крупномасштабных промышленных реализаций. С введением же WebSphere Application Server Enterprise Edition и подмножества слияния Component Broker и TXSeries с ним, IBM имеет более ясный, хорошо сегментированное представление своих возможностей разработки и внедрения промышленных приложений.

WebSphere Application Server также обеспечивает инфраструктурную основу для компонентов бизнес-приложений из проекта и каркаса IBM SanFrancisco. IBM SanFrancisco - это коллекция компонентов на базе Java, которые можно собрать для построения серверного бизнес-приложения. Она также позволяет разработчикам строить собственные Java-компоненты.
SanFrancisco является в наиболее буквальном смысле этого слова каркасом, в котором упакованы в единой архитектуре компоненты и возможности, необходимые для построения полнофункциональных промышленных приложений. Его архитектуру составляют несколько слоев (в порядке их уровня над платформой):

• SanFrancisco Foundation and Utilities Layer (базовый уровень и утилиты). Обеспечивает функции базового уровня для таких задач, как инсталляция, конфигурирование, безопасность.
• SanFrancisco Common Business Object (общие бизнес-объекты). Этот слой содержит объекты и компоненты, которые представляют ключевые для бизнеса сущности, такие как: "покупатель", "валюта", "адрес", и т.п.
• SanFrancisco Common Business Processes (общие бизнес-процессы). Компонентами, размещенными в этом слое, поддерживается ведение счетов, общая бухгалтерия и большое количество других общих для всех отраслей функций.
• ISV и Customer Application (приложения независимых производителей и пользователей). Эти приложения поставляют разработчики решений, многие из них специфичны для отрасли.

IBM, т.о., собрала вместе м продолжает совершенствовать крепкий набор средств разработки и внедрения (VisualAge for Java) и базированный на EJB, простой в использовании и установке сервер приложений (WebSphere); и их возможности в промышленных транзакциях и распределенных объектах в связное, хорошо масштабируемое решение проблемы переноса наследства в "современный" мир Internet и многоуровневых вычислений.
Это стратегия многосторонняя и модульная - в том смысле, что другие инструменты могут быть использованы с WebSphere, а поддержка EJB делает VisualAge хорошим инструментальным выбором для внедрения на фактически любом сервере, который поддерживает его. IDC считает, что совместное использование инструментов, серверов и сред управления IBM дает преимущества в оптимизации, хотя для IBM важно своевременно внедрять усовершенствования. Некоторые конкуренты могут использовать как козырь свою более раннюю поддержку EJB и других возможностей, но мало кто пришел к завершенности в обеспечении всеобъемлющего и масштабируемого решения. От IBM требуется же проводить агрессивную политику выдвижения продукта и четко прочерчивать свою стратегии и превосходство в эффективности над еще незавершенными реализациями, заявленными конкурентами.
Широта стратегии IBM в AD и продуктов четко ориентирована к разработчикам крупномасштабных, сложных, бизнес-критических приложений IBM уже имеет значительный успех на рынке с отдельными продуктами из семейств VisualAge (VisualAge for Java) и WebSphere благодаря наилучшей ориентации этих продуктов. Однако, широта AD-стратегии IBM позволяет полностью покрыть континуум AD.

Ясно также, что все три семейства продуктов (VisualAge, WebSphere и SanFrancisco) будут сохранять свою роль в континууме AD, но IDC считает, что возрастающая гибкость пакетных приложений и высокая полезность сборки приложений (по сравнению с традиционными методами AD) позволит этим подходам к AD окончательно доминировать.
Три формы семейств продуктов формируют, в сущности, континуум: от разработки (VisualAge) через внедрение (WebSphere) и до управления установленными приложениями (Tivoli). IBM рассматривает эту схему как важную часть своего e-business Application Framework, который является основой стратегии e-бизнеса. Учитывая те растущие вложения, которые IBM делает в эти две области, IDC считает, что этот производитель остается одним из лидеров, если не единственным лидером, в AD.
Хотя стратегия IBM в AD более односторонняя, когда идет речь о поддержке операционного окружения, важно заметить, что все ключевые семейства продуктов (VisualAge, WebSphere и SanFrancisco) включают в себя поддержку установки на S/390. Группа S/390 также обсуждает инструменты и программы для переноса приложений с большим числом третьих производителей для придания S/390 возможности конкурировать с рыночными конкурентами. Если течение повернет в направлении сервер-центрической обработки, то, возможно, организации значительно выше оценят полезность средств внедрения для S/390. Комбинация всеохватывающих возможностей AD, поддержанная мощной серверной технологией, обеспечивает исключительно полное ценное предложение для организаций, которые нуждаются в поддержке сложных бизнес-критических приложений.

Мы можем сделать много важных выводов из этого обзора стратегии IBM в AD на 21-й век.
IBM является мировым лидером как производитель средств AD. IBM завоевала эту высокую позицию благодаря постоянному наращиванию своих знаний о поддержке AD крупномасштабных, бизнес-критических приложений. Это привело IBM не только к всеобъемлющему набору продуктов, связанных с AD, но также дало этому производителю способность поддерживать полный континуум AD, который приблизительно разделяется на три области: модернизация, модуляризация, миграция. Отличие, заключающееся в способности производить широкую поддержку AD для крупномасштабных, сложных приложений является значительным достижением и одним из тех факторов, которые поднимают IBM на высоту, недосягаемую для других конкурентов.
Возрастает симбиоз в совместной работе ключевых инструментальных семейств (VisualAge, WebSphere и SanFrancisco), но проведение линии от раздельной интероперабельности до полной интеграции остается выбором IBM, как и для любого производителя многих продуктов. Хотя очевиден прогресс IBM в этой области, она продолжает оставаться областью грандиозных возможностей. Однако, вложения IBM в Component Broker и WebSphere вместе с продолжающимся упором на единую программную модель, показывает, что IBM быстро движется в правильном направлении.
Для больших организаций, нужды которых связаны с разработкой сложных приложений, ориентированных на Web, остается только одна альтернатива: IBM.