Network World, США
С точки зрения корпоративных ИТ, сервис SONA порождает больше вопросов, чем ответов
Последние 40 лет сетевые решения в корпоративном мире развивались синхронно с ИТ. В 2006 году эта ситуация может измениться. Чья же позиция окажется более убедительной: корпорации Cisco Systems или других ИТ-компаний? Концепции организации вычислительных систем за последние четыре десятилетия в своем развитии прошли множество этапов: централизованная модель, распределенная, клиент-серверная, сетевая, одноранговая и, наконец, сервисно-ориентированная модель.
В сервис-ориентированной архитектуре (Service-Oriented Architecture, SOA) основу формируют базовые компоненты инфраструктуры, выполняющие вычислительные функции, а также предназначенные для организации хранения и сетевых взаимодействий. Корпорация Cisco оспаривает эту концепцию, предлагая иное видение, получившее название Service Oriented Network Architecture (SONA). В соответствии с этой концепцией, сеть является основой для всех процессов обработки информации, выступая в роли связующего элемента для других компонентов инфраструктуры ИТ — клиентов, серверов и систем хранения.
Выбор между этими архитектурами определяет основы проектирования, реализации и использования корпоративной SOA и управление ею. Сервисно-ориентированная архитектура, опирающаяся на отраслевые стандарты, представляет собой многоуровневую оболочку, которая позволяет всем вычислительным концепциям существовать в рамках единой архитектуры. Это служит одной цели: воплощению корпоративных бизнес-процессов в конкретной технологии. Для того чтобы добиться этой цели, интеллектуальные взаимодействия между приложениями необходимо распределить по всей цепочке бизнес-процессов, включая саму компанию, ее клиентов и поставщиков, а также каналы распространения и продаж. При такой архитектуре корпоративная сеть становится физической «нервной системой», связывающей все внешние компоненты с корпоративными ИТ, а корпоративная сервисная шина (Enterprise Service Bus, ESB) превращается в логическую систему передачи электрических сигналов для поддержки взаимодействий.
Сервис SONA отличается кардинальным образом. Эта архитектура создает трехуровневую оболочку, формируя промежуточный уровень интерактивных сервисов между программной и сетевой инфраструктурой. Она помещает интеллектуальную составляющую коммуникаций в сеть и предусматривает наличие пассивных программных и инфраструктурных сред ИТ.
Ситуация еще более усложняется тем, что сервис Cisco не является сервисом SOA. Согласно определению SOA — это повторно используемые программные компоненты с четко определенными, опубликованными и опирающимися на стандарты интерфейсами. Эти компоненты выполняют конкретную функцию от имени объекта, участвующего в вычислениях, такого как пользователь или другой программный компонент. Сервис SONA, с программной точки зрения, отличается более узкой специализацией и может быть, а может и не быть повторно используемым. Он также не имеет опубликованных API, ориентирован на продукты одного производителя и выполняет функцию интерактивного взаимодействия между приложением и инфраструктурой.
|
| Фрэнк Дзюбек — президент компании Communications Network Architects, специализирующейся на анализе рынка. С ним можно связаться по адресу fdzubeck@commnetarch.com |
В декабре были предложены две новые инициативы, связанные с сервисно-ориентированной архитектурой и поддерживающие виртуализацию приложений в сети. Первая из них, Service Component Architecture (SCA), предлагается в качестве модели для создания и объединения сервисных сетей. Вторая, Service Data Objects (SDO), ставит своей целью определение единой методологии доступа к данным. В реализации SCA и SDO принимают участие многие производители, но не Cisco, в силу чего эти инициативы приведут к еще большим различиям между SOA и SONA.
На первый взгляд, SOA и SONA могут сосуществовать, поскольку первая применима к программному обеспечению, а вторая — к сетевым решениям. К сожалению, SONA, по всей вероятности, усложнит реализацию оптимизированной сервисно-ориентированной архитектуры, если вовсе не воспрепятствует ей. Если Cisco настаивает на переносе в сеть функций, которые ранее выполнялись на программном уровне, и на выполнении виртуализации серверов и вычислений, а также функций управления именно в SONA, тогда любые преимущества, которые могла бы получить компания от реализации двойного подхода SOA/SONA, будут весьма ограниченными.
С точки зрения корпоративных ИТ, сервис SONA порождает больше вопросов, чем ответов. Какие инструментальные средства существуют для моделирования и развертывания смешанных сервисов SOA и SONA в бизнес-процессе? Каким образом корпоративное бизнес-приложение сможет запросить сервис SONA, если он не является сервисом SOA? Как можно обеспечить сквозную виртуализацию или оптимизировать производительность потока работ в среде, где одновременно используются решения SOA/SONA различных производителей? Будет ли SONA соответствовать новым отраслевым стандартам SCA и SDO, и какие отраслевые стандарты применимы к SONA? Будет ли SONA иметь сетевую сервисную шину, аналогичную ESB в сервисно-ориентированной архитектуре? Сервис SOA можно реализовать с помощью внутренней инфраструктуры компании и инфраструктуры, поддерживаемой посредством аутсорсинга, а можно ли SONA реализовать таким образом?
Возникают все новые и новые вопросы. Но есть один вопрос, имеющий определяющее значение для отрасли ИТ, сетевой индустрии и рынка корпоративных приложений: является ли SONA порождением гордыни и попыткой сформировать рынок «под себя»?