InfoWorld, США
Времена меняются. Устойчивость способов выполнения операций больше не является обязательным атрибутом бизнес-процессов
Джим Рамбо, ведущий инженер корпорации IBM, недавно возглавил подразделение программного моделирования в IBM Rational. Вместе с Гради Бучем и Иваром Якобсоном он составил Three Amigos («Трио друзей»), ставших создателями легендарного языка Unified Modeling Language, в 1997 году утвержденного Object Management Group в качестве стандарта. Рамбо также принимал участие в подготовке Rational Unified Process и был главным разработчиком методики Object Modeling Technique по объектно-ориентированному анализу и проектированию. Рамбо ответил на вопросы старшего редактора еженедельника InfoWorld Пола Крила.
Расскажите о предыстории UML и о том, как вы оказались вовлечены в эту работу?
Некоторое время назад едва ли не все специалисты по методологии использовали собственные методы моделирования. И многие обращалась к нам со справедливым вопросом: почему нельзя все это унифицировать? Своим появлением UML обязан Майку Делвину, генеральному директору компании Rational Software, который и пригласил меня на работу. Ивар Якобсон и Гради Буч к тому времени уже были сотрудниками Rational. Нас стало трое, и все мы теперь работали в одной компании. Греди и я первыми составили то, что мы назвали Unified Method. На самом деле именно Ивар предложил переименовать его в Unified Modeling Language — унифицированный язык моделирования. После чего и у других специалистов появился стимул присоединиться к нам. Именно тогда началась реализация масштабной инициативы.
Какова была ее цель?
Мы намеревались создать некую общность на основе множества различных подходов к моделированию и сформировать стандартный подход, которым могли бы пользоваться все. В результате и появился UML. Теперь многие специалисты, помимо нас троих и сотрудников Rational, принимают участие в его развитии. Этим и объясняется успех UML. Сейчас, как вы знаете, UML довольно активно вытесняет все остальные методы. Даже сторонники других технологий в конечном итоге сдаются и начинают использовать UML.
Microsoft, по существу, не поддерживает UML. Они не видят большой потребности в UML. Какого рода проблемами это грозит?
Время покажет, на самом деле они с нами или нет. Кроме того, в определенном смысле они его поддерживают. Похоже, они просто хотят выиграть в любом случае. Но опять-таки, очень многие считают UML удобным и эффективным. И только оттого, что в Microsoft думают иначе, ситуация не изменится. Microsoft не сможет убедить всех действовать так, как она предлагает, во всех без исключения областях. Это уж точно. (Прим. ред.: Microsoft поддерживает UML 1.4, но не поддерживает более новую версию, UML 2.0. Однако компания Borland Software представила модуль проектирования на базе UML 2.0 для работы с инструментарием Microsoft Visual Studio).
Вы часто говорите о важности архитектуры, опирающейся на модели (model-driven architecture, MDA). Является ли UML формой такой архитектуры? Что собой представляют некоторые технологии на основе MDA?
UML — это язык моделирования, то есть это способ описания моделей. MDA — способ создания моделей. Эти два подхода ортогональны друг другу. Вам необходим способ описания модели, так же как и способ ее создания. Один — это процесс разработки, а другой, в определенном смысле язык, формат — как угодно его назовите — представления.
Складывается впечатление, что вы пренебрегаете Web-сервисами. Почему?
Среда Web-сервисов — это разновидность сервис-ориентированной архитектуры (service-oriented architecture, SOA), поэтому фактически они подпадают под это название. Web-сервисы были своего рода первым примером SOA или, в любом случае, очень ярким примером.
Имеется ли у IBM инструментарий Enterprise Service Bus или вы намерены его создать?
По существу, сервисная шина предприятия ESB встроена в ПО промежуточного слоя WebSphere. На самом деле она не является автономной. В некотором смысле, ESB — это концепция, которую продукты должны поддерживать. Поэтому выделять ее не стоит. Это свойство, которым должно обладать программное обеспечение промежуточного слоя. Это термин для обозначения свойства, необходимого для того, чтобы вы без труда могли вызывать одно из чего-то другого. Причем делать это, вне зависимости от машинных форматов, языков и платформ.
Так что же составляет основу ESB? Это же, по сути, шина передачи сообщений, разве не так?
Согласен, данная концепция опирается на идею обмена точными сообщениями между разными объектами. Если смотреть под таким углом, это действительно обмен сообщениями между приложениями.
Насколько популярны сейчас архитектуры, ориентированные на сервисы?
Повторюсь, Web-сервисы — разновидность SOA. Поэтому пользователи, безусловно, их внедряют, и мы предполагаем, что в дальнейшем это будет распространяться все шире и шире. И наша задача — максимально это упростить. До сих пор возникавшие проблемы были серьезными препятствиями. Например, проблемы, касающиеся связи между платформами. Поэтому IBM разрабатывает ПО промежуточного слоя. Задача этого инструментария — дать пользователям возможность создавать приложения, которые могут взаимодействовать и делать то, что им нужно. Сейчас существует немало такого ПО, и я думаю, что оно будет развиваться и дальше.
Верно ли, что переход предприятия от монолитной архитектуры к SOA потребует значительных вложений? Кто-нибудь из Sun Microsystems, скорее всего, не преминул сказать, что IBM будет продавать услуги IBM Global Services для внедрения SOA. Насколько дорого обходится переход на архитектуру, ориентированную на сервисы?
Делать все сразу необязательно. Мы постоянно подчеркиваем, что такой переход осуществляется постепенно. Переход на SOA необходим в тех областях, где подобное решение себя окупает.
Первое, что можно сделать, — это изменить отношение. Принципы культуры и политические правила, действующие внутри компании, могут стать серьезным препятствием на пути реализации данной идеи. Как правило, такие решения вызывают сопротивление со стороны сотрудников. Но работа генерального директора, финансового директора и директора по технологиям как раз и заключается в том, чтобы преодолевать эти барьеры.
Что вы думаете о языке выполнения бизнес-процессов BPEL (Business Process Execution Language)?
Да, мы его используем. И хотя это довольно низкоуровневая спецификация, очень важно строить свою работу на основе стандартов. Поэтому у нас есть продукты, которые его применяют.
В войне Java против .Net, если так можно выразиться, будет ли победитель?
Существовать будет и то и другое.
Однако Microsoft, по-видимому, нашла более эффективный способ зарабатывать на .Net, чем Sun зарабатывает на Java.
IBM тоже поддерживает Java. Давайте выразимся так: Microsoft в данном случае — грозный соперник.
Вы считаете, что IBM является лидером в области технологии Java, даже опережает в этом Sun?
Да, я считаю, что IBM занимается этим очень серьезно и активно, и мы не ждем, что Sun прекратит поддерживать Java. Но я, безусловно, считаю IBM одним из лидеров этой области.
Как происходит сотрудничество между IBM и Rational после слияния? Ощущает ли Rational какие-то ограничения?
Многие сотрудники Rational считают, что теперь у программных продуктов Rational перспективы существенно расширились. Ведь сфера действия IBM значительно шире, чем у Rational, и теперь мы продаем свои продукты там, где никогда не делали этого раньше. Так что фактически мы получили даже большую свободу, чем прежде.
IBM подчеркивает значимость SOA
Современному бизнесу с его распределенной природой нужны сервис-ориентированные архитектуры (service-oriented architecture, SOA). Такой вывод сделали представители корпорации IBM на конференции разработчиков Software Development West 2005 Conference, проходившей в марте в городе Санта-Кларе (Калифорния).
«Бизнес, который всегда был неделимым, сегодня приобретает все более распределенный характер, — заявил прославленный исследователь Джим Рамбо, создавший некогда язык Unified Modeling Language и в свое время вместе с компанией Rational Software перешедший в корпорацию IBM. — Времена меняются. Повышается гибкость взаимоотношений с клиентами и поставщиками. Устойчивость способов выполнения операций больше не является обязательным атрибутом бизнес-процессов».
По мере того как бизнес претерпевает изменения, нужно менять и поддерживающую его инфраструктуру программного обеспечения.
По словам Рамбо, программной среде, которая отвечает требованиям дальнейшего развития бизнеса, должны быть присущи четыре основные черты.
- Организации нужна компонентная бизнес-модель и сервисы предоставления компонентов.
- Изменения в инфраструктуру ИТ необходимо вносить с учетом поддержки архитектур сервисного типа.
- Процедуру отображения архитектур нужно автоматизировать с использованием методологии MDA (model-driven architecture).
- Следует избегать монолитного стиля проектирования, отдавая предпочтение итерационной разработке.
Критически важное значение для успешного развертывания систем на базе сервисов и эффективного их взаимодействия имеют стандарты.
«Прежде всего нам нужно обеспечить интероперабельность и утвердить стандарты, в том числе и стандарты для программного обеспечения с открытым кодом, — подчеркнул Рамбо. — Компании, оказавшиеся за пределами пространства стандартов, будут выброшены из бизнеса».
Хотя термин SOA и не имеет достаточно четкого определения, он тем не менее дает представление о порядке развертывании систем.
«В действительности цель заключается в том, чтобы установить гибкие связи между всеми компонентами и упростить тем самым внесение изменений, — отметил Рамбо. — И первым примером SOA являются Web-сервисы».
Связь между отдельными системами в архитектуре SOA обеспечивается с помощью корпоративной сервисной шины (enterprise service bus, ESB). К ней же пристыковываются и унаследованные компоненты.
«Мы не собираемся переделывать весь бизнес одновременно, поэтому нужен какой-то интерфейс с шиной, позволяющий подключать унаследованные системы в режиме прямого доступа», — пояснил Рамбо.