На вопросы редакционного директора ИТ-группы изданий "СК Пресс" Эдуарда Пройдакова о сервис-ориентированной архитектуре ответил Евгений Абрамов, Engagement Architect представительства корпорации Sun Microsystems в России и странах СНГ.
PC Week: Что означает название вашей должности - Engagement Architect?
Евгений Абрамов
Евгений Абрамов: У этой должности нет эквивалентного названия на русском языке. Дело в том, что в нашей компании есть должности архитекторов, которые работают на стадии реализации проекта, есть работающие на стадии выяснения постановки бизнес-задачи. Моя же задача - проанализировать проблемы и задачи наших заказчиков и сформулировать для них решение на основе наших программных продуктов. С одной стороны, это инженерная должность, а с другой - позиция аналитика, консультанта.
PC Week: Термин "сервис-ориентированная архитектура", или "SOA", который сейчас звучит все чаще, выглядит несколько размытым. Можно ли ему дать более строгое определение?
Е. А.: Общего понимания, что это такое в ИТ, наверное, нет ни в России, ни в мире, хотя это достаточно четко определенная архитектура, и я могу попробовать сформулировать, какой смысл в эти слова вкладываю, например, я. SOA - это попытка выделить в каждом из используемых в организации приложений некоторые базовые сервисы. Допустим, у нас есть биллинговая система. Понятно, что биллинг сам по себе - это высокоуровневый сервис, состоящий из целого ряда сервисов более низкого уровня типа проверки состояния счета абонента и т. п. Все эти базовые сервисы мы можем в некотором стандартном, единообразном виде вывести на так называемую сервисную шину, причем сделать это не только для биллинговых систем, но и для ERP, CRM и т. д. В дальнейшем если нам в какой-то бизнес-задаче необходимо пополнить счет абонента, то мы можем стандартным образом вызвать нужный сервис. Сейчас для этого чаще всего используют интерфейсы SOAP веб-сервисов, и задача исполняется внутри биллинговой системы. На самом деле нам совершенно не нужно знать, где это происходит.
После того как все основные сервисы будут выведены из основных приложений на сервисную шину, мы можем довольно легко автоматизировать какие-то новые бизнес-процессы.
PC Week: Если не имеет значения, где сервис исполняется, то возникает проблема синхронизации процессов?
Е. А.: Да, это может исполняться на другом процессоре, другом сервере, нам даже не важно, что это за система. Синхронизация происходит на уровне бизнес-процесса. Мы абстрагируемся от конкретных систем - у нас есть некоторый движок, который исполняет бизнес-процессы. Это наиболее сложный и ответственный компонент SOA.
PC Week: По существу SOA - это ПО промежуточного слоя, то, что по-английски называется middleware?
Е. А.: В том, что касается исполнения, да. Здесь нет никакой революции - интеграционные решения существуют очень давно, причем как для интеграции систем в рамках одного предприятия, так и для внешней интеграции между системами партнеров и поставщиков. Стандартный EDI (электронный обмен документами. - Прим. ред.) - тоже давно известная вещь. Что поменялось? SOA - это не революция, а результат эволюционного развития программирования. Все большая стандартизация и все большее развитие средств взаимодействия между различными платформами. Если совсем недавно мир крутился вокруг двух платформ для корпоративного программирования - Java и .NET, то сейчас уже говорить о противостоянии этих платформ не приходится, так как есть хорошие средства, обеспечивающие их взаимодействие, и сегодня те компании, которые были нашими основными конкурентами, очень быстро превратились в наших стратегических партнеров.
PC Week: А как с переходом на SOA быть с унаследованными системами?
Е. А.: Это одна из задач построения сервис-ориентированной архитектуры. Нам необходимо реализованные в унаследованных системах сервисы выпустить вовне, но не в виде древних и редких протоколов, а в виде современных протоколов типа SOAP, UDDI и т. п. Для этого большинство производителей интеграционных решений, и мы здесь не исключение, предоставляет множество уже готовых адаптеров. Компания Sun, как приверженец открытых стандартов, предлагает свои адаптеры на базе открытого Java-стандарта Java Connection Architecture. Но тонкости реализации адаптера, т. е. как он взаимодействует с унаследованной системой, для разработчика особой роли не играют - важно, что во внешнем мире он виден как веб-сервис и с ним можно обмениваться XML-сообщениями.
PC Week: Мы говорили, что в SOA очень важен движок исполнения бизнес-процессов. Кто разрабатывает движки?
Е. А.: Такой движок в том или ином виде предлагают практически все интеграционные компании. В большинстве своем они строятся на базе открытого стандарта BPEL, есть также стандарты моделирования этих бизнес-процессов. Общепринятого стандарта здесь пока нет. Мы в своем решении Java Connection Architecture используем BPMM как стандарт для описания бизнес-процессов. Далее XML-описание бизнес-процесса загружается в движок для исполнения. По этому описанию могут порождаться параллельные процессы. Кроме того, движок отвечает за высокую доступность созданных процессов и сохранение их при программных или аппаратных сбоях. Для этого наши интеграционные решения поддерживают кластерную архитектуру на сервере приложений. Все бизнес-процессы собираются в стандартные J2EE-приложения, которые мы можем размещать и исполнять на любом J2EE-совместимом сервере приложений. Здесь нет привязки к аппаратной платформе, поскольку это Java, и нет привязки к ПО промежуточного слоя, поскольку любой сервер приложений может исполнять бизнес-процессы.
PC Week: Насколько успешно, на ваш взгляд, этот подход продвигается среди разработчиков, и можно ли ожидать, что корпоративные приложения в ближайшем будущем полностью перейдут на эту архитектуру? И вообще, что это им в итоге даст?
Е. А.: Сейчас для решения какой-то бизнес-задачи с нуля или почти с нуля нам приходится заказывать разработку какого-то приложения, которое и решит нашу задачу. При этом бизнес-аналитик не может автоматизировать процесс без участия программистов. Есть и другой подход: если задача более-менее стандартная, можно купить некоторое приложение, и после некоторой адаптации оно нас будет устраивать. Наконец, третий подход - попытка внедрить комплексную ERP-систему, которая покроет все наши задачи. Это направление, в свою очередь, распадается на два: первое - когда поставщик ERP-системы сам подгоняет свою систему под требования заказчика; второе и более популярное и эффективное - это по мере возможности поменять свой бизнес под купленную ERP-систему.
В рамках SOA мы можем использовать модули из различных систем. Если все потребности предприятия покрываются одной системой, то большого смысла в применении SOA нет, так как все приложения собираются из модулей этой системы. Но мы исходим из того - и сталкиваемся с этим в реальной жизни, - что компании используют ПО от разных производителей и возникает задача интеграции функциональностей из разных систем, поскольку 90% необходимого функционала уже имеется в существующих системах. Если они разрабатывались в одной архитектуре и на одной платформе, то проблем взаимодействия, скорее всего, не возникнет, но в реальной жизни разработчики систем разные, исповедуют различные подходы к программированию, и либо нам придется в каждом случае находить с ними общий язык, либо мы используем открытый стандарт по взаимодействию сервисов; в этом плане SOA - хороший работоспособный стандарт для таких целей.
Если бизнес-аналитик может записать бизнес-процесс в какой-то нотации, а мы можем запустить этот бизнес-процесс на интеграционную шину, то по сути мы получим готовое решение. Это несколько идеализированная ситуация, в реальной жизни все не так просто, но подобный подход позволяет минимизировать объем разработки в десятки раз. Опять же - эффективность подхода зависит от характера задачи, например, он, наверное, не очень подойдет для разработки антивирусных программ. SOA не отменяет разработку отдельных приложений, но очень сильно упрощает жизнь при написании делового и финансового ПО.
Если говорить об актуальности, то, на мой взгляд, с SOA уже прошел этап первичной эйфории и сейчас начался этап прагматичного анализа возможностей данного подхода. С другой стороны, в настоящее время ощущается острая нехватка специалистов по этой тематике, причем как на уровне бизнес-аналитиков, так и на уровне программистов, которые могут воплощать SOA в жизнь.
PC Week: Откуда возникло движение SOA, и каковы в нем интересы Sun?
Е. А.: Ближайшим предшественником SOA я бы назвал CORBA. Идеологии очень похожи, только за время, прошедшее после появления CORBA, возник язык XML, в разработке которого сотрудники Sun принимали непосредственное участие, были созданы новые платформы программирования - Java и .NET, поэтому появились более простые для разработчиков и системных архитекторов интерфейсы для взаимодействия приложений на базе веб-сервисов, а сами веб-сервисы стали по сути стандартным интерфейсом для построения SOA, хотя способ этот, в принципе, не единственный. Но на сегодня это новый и удобный инструмент.
Sun Microsystems - инфраструктурная компания, поэтому для нас SOA представляет важное направление, и в состав JCA входят все инфраструктурные компоненты для построения интеграционных решений - это и набор адаптеров, и сервер приложений, и среда разработки, и сервисная шина, и движок бизнес-процессов, и среда мониторинга для отслеживания состояния и статуса бизнес-процессов. При этом все наши компоненты строятся на базе открытых стандартов, т. е. заказчик может использовать компоненты от других производителей.
PC Week: Java-машина, как интерпретатор, заметно замедляет скорость исполнения программ. Не скажется ли такое снижение производительности на работе корпоративных приложений?
Е. А.: Здесь я позволю себе не согласиться. Сейчас практически все среды исполнения Java предлагают средства JIT-компиляции, т. е. перед исполнением байт-код транслируется в объектный код. Кроме того, Java-приложение исполняется на сервере приложений, а не на клиентской машине. Поэтому J2EE-разработчик в части масштабируемости, безопасности, в области обеспечения целостности транзакций может использовать функциональность, которая имеется на сервере приложений.
PC Week: Вынос исполнения на сервер приложений сделан для внедрения тонких клиентов или были другие резоны для такого решения?
Е. А.: Здесь две основные причины: необходимость независимости от аппаратной платформы для упрощения разработки и независимости от ОС. Сейчас практически все крупные системы разрабатываются именно в такой архитектуре. Наличие тонкого клиента здесь не является обязательным требованием.
PC Week: Что делает представительство Sun Microsystems для продвижения SOA?
Е. А.: Мы действуем в нескольких направлениях. Во-первых, рассказываем о SOA нашим заказчикам как при непосредственных встречах, так и на разных конференциях и семинарах. Во-вторых, проводим работу с партнерами. Все наше ПО, включая сервисную шину, в целях ознакомления и обучения бесплатно доступно партнерам и заказчикам на нашем сайте. Это полнофункциональная, работоспособная, не ограниченная во времени версия вместе с документацией. Таким образом снижается первоначальный барьер в деле ознакомления с данными решениями. С партнерами проводятся также регулярные семинары и тренинги по тематике SOA. Кроме того, в 15 вузах России наша компания начала реализацию программы Sun Campus Ambassador, которая помогает студентам осваивать средства разработки. Когда эта программа заработает в полную силу, нам будет еще проще объяснять преимущества SOA.
PC Week: Спасибо за беседу.
