Эволюция программных архитектур
Классическим примером первой ступени, мейнфрейма, может служить система SAP R/2. В клиент-серверной архитектуре таким образцом стала широко распространненая SAP R/3, а в качестве сервис-ориентированного решения компания SAP позиционируетсвою новую интеграционную платформу NetWeaver. "Теперь SAP производит не только и не столько ERP-систему, а скорее специализированную оболочку — набор средств для быстрой и эффективной интеграции всего того, что уже работает на предприятии, - отмечаетТимур Аитов, директор по развитию бизнеса РБК СОФТ. - Сервисно-ориентированный подход, лежащий в основе платформы NetWeaver, позволяет резко облегчить и ускорить внедрение корпоративной информационной системы на любом предприятии" - подчеркивает он.
Сервис-ориентированная архитектура основана на технологии Web-сервисов, способность к саморазвитию которых и обеспечивает так необходимую адаптивность ИТ-инфрастуктуры предприятия. Однако, между очевидным потенциалом Web-сервисов и их реальными возможностями сегодня существует довольно большой разрыв. Именно в базировании SOA на Web-сервисах кроется ее основная проблема. Перевод бизнес-критичных приложений корпорации на использование их в рамках этой концепции требует наличия единых стандартов на Web-сервисы. Существующих требований явно недостаточно для решения сложных, комплексных задач, а работа над созданием более совершенных стандартов еще очень далека от совершения и в этом немалую роль играет противостояние крупнейших гигантов ИТ-индустрии, таких как Microsoft, с остальным миром производителей программных продуктов.
Справедливости ради, стоит отметить, что после анонсирования Microsoft Visual Studio Team System 2005, а также предложений IBM по конкретным решениям, основанным на SOA, это противостояние стало минимальным, и можно ожидать продвижения в разработке единых стандартов, регламентирующих использование Web-сервисов. Для успеха концепции сервис-ориентированной архитектуры необходимо наличие единого интерфейсного языка, описывающего Web-сервисы. В последнее время активно ведется работа над совершенствованием такого языка – Web Services Description Language (WSDL).
Некоторые существующие предварительные спецификации на Web-сервисы уже сегодня призваны гарантировать доставку сообщений SOAP по назначению и поддержку стабильности состояния длительных транзакций. Тем не менее, по мнению многих экспертов, говорить о повсеместном использовании подобных «сырых» спецификаций еще очень рано. Отсутствие единых стандартов на Web-сервисы не позволяет компании реализовать критичные бизнес-процессы в рамках SOA и в значительной степени сдерживает развитие этой концепции.
«Подводные камни» soa
Классическое представление SOA реализуется в виде треугольника, во которого главе стоит реестр сервисов (Universal Description, Discovery and Integration - UDDI), а в двух остальных вершинах – провайдер и потребитель Web-сервиса.
Классическое представление концепции soa
Реестр содержит исчерпывающую информацию по всем сервисам и службам, которую обязан опубликовать в нем провайдер соответствующего сервиса. Потребитель сервиса отправляет необходимый запрос в реестр, который и обеспечивает связывание его с провайдером. Еще одна проблема SOA связана с отсутствием четкого перечня требований к UDDI. Более того, совершенно непонятно, каким образом осуществляется выбор лучшего сервиса для выполнения бизнес-функции по запросу потребителя.
Другой немаловажный вопрос, связанный с самой технологией Web-сервисов, - использование протокола HTTP для передачи данных. С одной стороны это позволяет реализовать саму идеологию интеграции распределенных гетерогенных систем и обеспечить ее универсальность, а с другой - вызывает большое количество проблем, связанных с надежностью и безопасностью проведения транзакций. Более того, при использовании Web-сервисов, когда компоненты одного приложения могут отключаться и взаимодействовать с компонентами совершенно другого приложения, особенно остро встает проблема разграничения доступа и построения распределенной архитектуры защиты.
Основным достоинством концепции SOA, позволяющей реализовать адаптивность и эластичность ИТ-инфраструктуры является так называемая слабая связанность, которая подразумевает под собой отсутствие жестких связей между программными компонентами, что позволяет значительно оперативнее создавать новые приложения. Тем не менее, здесь же кроется и другой «подводный» камень SOA, а точнее проблема ее конкретной реализации. На первое место при создании SOA-приложений выходит проектирование интерфейса, что, в свою очередь, выдвигает новые требования к разработчикам, связанные с кардинальной переменой самой идеологии программной разработки, которые не могут обеспечить современные средства проектирования, изначально ориентированные на классическую клиент-серверную архитектуру.
Подобных, достаточно спорных вопросов в реализации SOA довольно много. Безусловно, использование XML обеспечивает необходимую универсальность, но с другой стороны, закономерно встает проблема производительность SOA-приложений, скорость работы которых напрямую связана с так называемым «весом» XML-транзакций, на обработку которых требуется значительно большее время, нежели на классические двоичные транзакции. Сторонники SOA видят решение этой проблемы в появлении специализированных программных решений – «ускорителей» XML.
Опять же, всеобъемлющая интеграция приложений, являющаяся одним из главных аргументов сервис-ориентированной архитектуры, также не является универсальной. В том числе, в такой важной области как поддержка унаследованных бизнес-критичных приложений. Конечно, сама концепция SOA подразумевает подобную интеграцию, но безболезненно она пройдет лишь для приложений изначально спроектированных под SOA. А как же быть с программными решениями, которые существуют в компании достаточно давно и в наибольшей степени отвечают реализации тех или иных бизнес-функций? Ответ очевиден – необходимы дополнительные усилия разработчиков для создания промежуточного программного слоя, обеспечивающего интеграцию – задача достаточно сложная и не всегда однозначно решаемая.