КаталогИндекс раздела

Стратегии разработки приложений IBM на 21-е столетие
Steve Garone, Richard V. Heiman, Stephen D. Hendrick
IDC Bukketin #18221
January 1999

Мнение 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, возрастающие возможности и важность вложений в ПО заставляют организации быстрее развивать их портфели приложений 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) и лучшую защиту вложений в программное обеспечение.
Количество производителей, обеспечивающих всестороннюю поддержку AD, поразительно мало. IBM благодаря своему акценту в последние два года на привнесение ключевых способностей AD во все три области континуума AD, сейчас является лидером в AD для больших организаций. Хотя стратегия IBM в AD и неполна, она превосходит фактически всех других производителей широтой и полнотой ее поддержки AD для больших организаций.

Имеет ли S/390 будущее в 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.

Поддержка IBM AD для модернизации

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

Взгляд на модернизацию

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

Ориентация на Internet в различных формах

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

Многоуровневые реализации

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

Компоненты программного обеспечения

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

Реалии модернизации

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

Лечение Y2K

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

IBM OPTI-AUDIT

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

VisualAge Millennium Language Extension

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

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

Согласователи CICS

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

Поддержка IBM AD для модуляризации
Переработка или инкапсулирование приложений: замена презентационного уровня унаследованных приложений

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

Эти характеристики делают возможным построение приложений из компонент и делают возможным построение приложений из компонент и дают возможность компонентам совместно работать. Инкапсуляция может придать некоторые или все эти характеристики имеющемуся ПО, до некоторой степени превращая его в компоненты. Остается еще один важный вопрос: как мы достигнем нашей цели "модернизации" унаследованных активов и в то же время будем в состоянии использовать стандартизованные решения, способные выполняться на любых платформах, которые мы можем иметь быть в нашей среде в любое время? Когда IBM говорит о инкапсуляции, она говорит в контексте Java-компонентов, которые в современной среде имеют четкую Web-ориентацию. Однако, бизнес-партнеры IBM, как PlanetWorks by Interspace, предлагают альтернативы компонентам, на базе Java с использованием других клиентских инструментов для создания нового презентационного уровня, таких как Visual Basic или PowerBuilder.

Выделение бизнес-правил

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

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

Адаптеры приложений

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

Единая программная модель

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

VisualAge for Java

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

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 уже заполнил рынок промышленных средств разработки по самую ватерлинию, он продолжает быть незаменимым для разработчиков сложных приложений, которые ищут более высокого уровня продуктивности и автоматизации разработки.

Поддержка IBM AD для миграции

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

Java

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

Enterprise JavaBeans

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

Спецификации EJB, таким образом, дают разработчику фундамент, позволяющий сосредоточить усилия на разработке бизнес-логики и уникальных прикладных функций вместо того, беспокоится об изобретении колеса, когда необходимо выполнять транзакции, доступ к данным и реализовывать разные низкоуровневые функции. Возможно, что EJB дает Java шанс для выполнения его обещаний быть ядром как однопрограммной, так и компонентной модели на любой и на всех платформах.
Структура EJB очевидная: обычные файлы Java помещаются в файл JAR, который архивируется и включает в себя описательный файл MANIFEST, который содержит информацию о содержании EJB. Разработчик создает классы EJB. Home и Remote классы и интерфейсы, роль которых - управлять доступом к классам EJB, генерируются как часть процесса разработки. Deployment Descriptor и MANIFEST генерируются в момент установки.
Файлы JAR размещены в контейнере EJB, задача которых - обеспечивать необходимый сервис (именование, управление состоянием, транзакции, безопасность и др.) для EJB. Среда выполнения, включая системный сервис и управление ресурсами, обеспечивается сервером EJB. Во многих случаях контейнера обеспечиваются производителями серверов.
Определены два типа EJB: Session Beans (бины сеансов), которые обеспечивают управление сеансами для Java-клиентов, и Entity Beans (биныы сущности), которые выполняют отображение источников данных на классы Java и, следовательно, делают эти источники данных прозрачными для пользователей. Каждый экземпляр бина сущности обычно представляет строку данных и идентифицирован первичным ключом. Бины сущности также могут содержать бизнес-логику, что делает возможным для имеющихся не-EJB-приложений взаимодействовать с объектами Java на сервере среднего уровня и полностью взаимодействовать им друг с другом.
Итак, бины сущности - путь, которым старые данные могут быть интегрированы в многоуровневые приложения. Фактически все производители серверов приложений усмотрели в этом важное направление и в течении второй половины 1998 года анонсировали новые версии продуктов, поддерживающих спецификации EJB. В декабре 1998 года IBM анонсировала поддержку EJB в своем Web Application Server и связанных с ним инструментах (обсуждаемых в следующих разделах). Это был шаг важный, но не удивительный. IBM не делала секрета из своей мощной поддержки Java как перспективного направления для своей стратегии в e-business и промышленной стратегии, и EJB - важная часть в реализации этих стратегий.

WebSphere

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

Первая версия WebSphere Application Server, Standard Edition, поддерживает среду выполнения на базе сервлетов. В декабре 1998 года IBM объявила Advanced Edition, которая, в сущности, превращает продукт в сервер EJB. Эта редакция включает в себя поддержку Java Transaction Service и свойства управления бинами и контейнерами. Объявление декабря 1998 года было сфокусировано на соединение с унаследованными базами данных, но также включало в себя законченные возможности производства EJB для соединения с MQSeries, CICS и другими хорошо известными транзакционными средами.
Поддержка EJB в WebSphere Application Server Advanced Edition была завершена некоторыми важными усовершенствованиями в VisualAge for Java Enterprise Edition. Эти усовершенствования включили в себя мастера EJB-бинов сеанса и сущности для уменьшения ручного кодирования, автоматическую генерацию кодов для поддержки бин- и контейнер-управляемых модулей, автоматическое создание тестового клиента для отладки EJB в VisualAge IDE, генерацию JAR-файла EJB, включая описатель установки для внедрения в WebSphere Enterprise Java Server и др.
В сентябре 1998 года IBM объявила о своем намерении вывести на рынок WebSphere Application Server Advanced Edition, который будет доступен в первой половине 1999 года. Эта версия объединяет функции Advanced Edition с Component Broker и TXSeries, добавляя поддержку интегрирования/распределения объектов приложения и поддержку транзакций промышленного уровня, специально для WebSphere.

Отношения Component Broker c WebSphere

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 имеет более ясный, хорошо сегментированное представление своих возможностей разработки и внедрения промышленных приложений.

SanFrancisco Framework

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

Слои каркаса размещаются над Java Virtual Machine (JVM).
В некоторых отношениях SanFrancisco подобна Object Connection - партнерской программе IBM, которая фокусировалась на разработке компонентов ПО (преимущественно таких, которые доступны в VisualAge и/или на основе Java) и совместимых с VisualAge инструментами для компонентно-базированной разработки. Обе программы разрабатывались для будущего, когда большинство функций будет подаваться в форме компонент, но SanFrancisco с его ударением на укрупненные, вертикальные компоненты пытается быть специфически нацеленным на промышленные приложения. Обе программы представляют основные соглашения IBM по разработке и внедрению компонентно-базированных приложений.
Еще многое должно быть внедрено в SanFrancisco, но IBM, тем не менее, сформулировала сценарий, который, по мнению IDC, является логичной и желательной конечной точкой с CBD: многосторонний, простой в применении, всеохватывающий каркас для конструирования и сборки промышленных приложений. Более того, Java-основание SanFrancisco делит его полностью совместимым с видением и реализацией IBM EJB.

Ценные предложения IBM по AD

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.

На рис. 2 AD стратегия IBM наложена на континуум AD. Рис. 2 обобщает ключевую информацию и отражает возрастание полезности и уместности SanFrancisco и WebSphere для организации по мере того, как организация движения в направлении миграции ее бизнес-процессов.

Ясно также, что все три семейства продуктов (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.


КаталогИндекс раздела