SOA И EDA И ПОДДЕРЖКА СИСТЕМ РЕАЛЬНОГО ВРЕМЕНИ

В апреле 2004 года состоялась Internet-конференция «Сервисы и события — секретные составляю­щие эф­фективного предприятия», организованная аналити­ческой компанией ebizQ. Еe основным итогом стало признание участвовавшими в ней экспертами того факта, что только подходы на ос­нове SOA и ЕDA могут обеспечить предприятиям эффективное ведение биз­неса.

Эти два архитектурных подхода позволят сблизить системы управления бизнесом с требовани­ями ре­ального времени, то есть построить предпри­ятие, работающее в режиме реального времени (real-time enterprise, RTE),

В этом смысле SOA и EDA взаимно дополняют друг друга. Архитектура SOA позволяет легко и быстро со­здавать новые и перестраивать имеющиеся ресурсы в соответствии с меняющимися условиями бизнеса. Архитектура ЕDA, со своей стороны, позволяет авто­матически и без вре­менных задержек инкорпориро­вать данные о происходящих событиях.

IBM И EDA

Принятие корпорацией IBM нового технологическо­го направления является если не необходимым, то уж точно достаточным условием для подтверждения его истинности. На появление EDA корпора­ция отве­тила объявлением инициативы IBM Common Event Infrastructure (CEI). В нынешнем виде СЕ1 представля­ет собой модульный набор для обработки событий, реализующий следующие функ­ции;

-транспортировка событий (event transport);

-шина распространения событий (event bus distribution);

-обеспечение жизнеспособности событий (event persistence);

-подписка на события (event subscription);

-модернизация событий (event updates);

-очереди событий (event queries);

-метаданные событий (event metadata).

CEI использует общую базу событий Common Base Event (CBЕ), основанную на системе обмена со­общени­ями, которая имеется в IBM WebSphere, и использует концентратор обмена сообщениями, вы­полненный по технологии ESB. Рассмотрение CEI с большей сте­пенью детализации выходит за рамки данной статьи; эта инициатива упомянута лишь для подтверждения серьезности идеи созда­ния корпо­ративных информа­ционных систем, способных функционировать в со­ответствии с пото­ком внешних событий.

НОВЫЕ ТЕХНОЛОГИИ ИНТЕГРАЦИИ

Новое поколение технологий, унифицирует архитектурные стили EDA вклю­чающие всебя различные стили инфраструктурного (серверы прило­жений, брокеры, очереди) и при­кладного (ERP, CRM и т.п) программного обеспечения.

К первому поколению Web-сервисов относят во мно­гом успешные инициативы, преследовавшие целью открытие существующих систем для внешнего взаи­модействия. Новое поколение Web-сервисов основано па обмене документами, осмысленно спроектирован­ных интерфейсах. В этой «ин­карнации» Web-сервисы обещают стать самой рас­пространенной технологией реализации как сервис-ориентированных, так и управляемых сообщениями систем.

В качестве естественного способа обретения сервис-ориентированных возможностей в стиле брокера многие разработчики используют язык выполнения бизнес-процессов BPEL (Business Process Execution Language). BPEL описывает XML-нотацию, позволяющую представить абстрактную мо­дель бизнес-процесса (явные ин­формационные потоки, связывающие системы) и сooтветствующий этой модели алгоритм. Последний может быть представлен в виде исполняемого Web-сервиса, имею­щею описание интерфейса на языке WSDL, кото­рый тесно связан с BPEL,

BPEL — «язык программирования SOA» — предлагает стандарт­ную альтернативу собственным язы­кам интеграции ус­таревающих брокеров EAI.

Классическая демонстрация возможностей BPEL основана на процессе заказа туристической пу­тевки, включающем в себя бронирование авиабилетов, номера в гостинице и оплату. Сложность за­ключается в опти­мизирующих ограничениях, определяющих необхо­димость минимизации суммар­ной стоимости поездки. Эти ограничения распространяются на стоимость би­летов и мест в гостини­цах, которая мо­жет варьировать­ся, асами билеты (места) на определенные дни —даже оказаться полностью распро­данными. Только после оп­ределении оптимальных дат путешествия и успешного бронирования про­цесс произво­дит оплату по кредит­ной карте, а если это невозможно, отменяет бронь и из­вещает об ошибке. Локаль­ная память, ветвление, циклы и обработка исключений позво­ляют полностью автома­тизировать процесс при помощи ВРEL..Отдельным немаловажным аспектом этого приме­ра является обеспечение такой гибкости инфраструк­туры, которая позволяет добавлять новые интегрируе­мые сер­висы (новые авиали­нии и гостиничные сети), изменять параметры уже ис­пользуемых (например, ад­реса взаимодействия) и удалять сервисы из рассмотре­ния процессом без внесения изменений в его структуру. Предпочтительно, чтобы владельцу процесса (турагенту) во­обще не приходилось само­стоятельно реагировать на каждое изменение на стороне контрагента.

Для поддержки самообслуживания партнеров хоро­шо подходит реестр сервисов на базе стандарта Universal Description, Discovery and Integration (UDD1). Используя этот подход, авиалинии и гости­ницы, с которыми у владельца процесса бронирования установлены дело­вые отношения, получают от него разрешение на автономную публикацию своих сервисов и управление ими в партнерском реестре сервисов турагента. Клиент этих сервисов, процесс бронирования, при обработке запро­сов обращается в реестр для обнаружения доступных сервисов, после чего оперирует ими в оответствии с бизнес-ло­гикой.

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

Реестр обеспечивает и единство интерфейсов серви­сов. Он содержит описание метаданных, ассоции­руе­мых с сервисами, включая спецификации их интерфей­сов на WSDL. Каждый сервис бронирова­ния может быть привязан к одному типу. Только соответствующие это­му типу сервисы будут най­дены и рассмотрены процес­сом в ходе бронирования.

РОССИЙСКАЯ ДЕЙСТВИТЕЛЬНОСТЬ

Сегодня,, ни одна из российских систем автоматизации не отвечает полностью требованиям, предъявляемым к ERP-системам. Дело в том, что стандарт ERP в первую очередь предназначен для планирования и оптимизации деятельности компании: исходя из этих предпосылок и разрабатывается информационный комплекс; отечественные же системы нацелены на фактический учет деятельности. Таким образом, одни описывают организацию «как должно быть», вторые — «как есть». Прежде всего это связано с российской спецификой развития рынка программных продуктов: сам рынок систем автоматизации начал развиваться лишь в 90-х годах ХХ в., и изначально затребованными оказались не системы планирования и управления, а системы материального и финансового учета. Если за рубежом проблема учета уже давно решена и перед предприятиями остро стоят задачи оптимального планирования деятельности как одного из важнейших преимуществ в конкурентной борьбе, в России наблюдается не только вакуум на рынке отечественных систем управления: российские предприятия в большинстве своем «не доросли» до таких решений.

Вплоть до настоящего момента наиболее актуальным для отечественных предприятий является решение задачи учета их ресурсов, о планировании же речь пока не идет. Более того, современное состояние экономики не позволяет использовать системы управления предприятием в полной мере. Действительно, зачем руководителю разрабатывать план поставок с привлечением характеристик своего производства, если он не уверен в том, что клиент оплатит заказ вовремя и у предприятия будут средства на закупку материалов?

Недавно в России началась опытная эксплуатация от­раслевого решения booklogic, нацеленного на интегра­цию отечественных издателей и книжных магазинов. Книжный рынок характеризуется ря­дом специфичес­ких особенностей, в числе которых — широкий ас­сортимент товарной номенкла­туры и большое число контрагентов, а также резкая смена темпов движения отдельных товарных по­зиций и состава предложений. Эти особенности требуют от участников рынка высокой слаженности действий, которой было сложно добиться из-за крайней разнородности имевшихся средств ИТ-обес­печения и отсутствия инфраструктуры для их не­прерывною взаимодействия.

Решение booklogic основано на продуктах UnilSpace, предназначенных для эксплуатации в удален­ном ре­жиме. «Гостевая» модель позволяет пользователям раз­мещать сервисы в выделенном центре дан­ных, осна­щенном каналами связи, аппаратными средствами и имеющем достаточный обслужи­вающий персонал, ко­торые было бы нецелесообразно воссоздавать каждому из клиентов. Размещен­ные на площадке booklogic ти­повые сервисы обеспечивают предоставление библио­графической и цеповой информации, прием коммер­ческих документов и т. д. На стороне интегрируемых организа­ции оста­ется только клиентская функциональ­ность, которая синхронизирует состояние их внутрен­них инфор­мационных системе состоянием сервисов booklogic.

Центральным элементом booklogic является реестр UDD1, который позволяет приобщить любой сер­вис к общему виртуальному пространству и обеспечива­ет прозрачность сервисов для всех участни­ков. Место физического расположения системы, предоставляю­щей сервис, теряет значение; интерес пред­ставляют лишь факторы доступности и качества обслужива­ния, которые зачастую завися го: на­дежно­сти кана­лов связи.

Сервисы ассоциируются в реестре с соответствую­щими им провайдерами — несмотря па их физиче­ское предоставление из одного центра данных.

Бизнес-сервисы booklogic оформлены в виде BPEL-процессов, исполняемых на площадке. По­скольку собственного механизма обеспечения возможности постоянного храпения объектов данных в ВPEL не пре­дусмотрено, инфраструктура booklogic дополнена плат­формой создания «гостевых» сервисов дан­ных для их преобразования и долгосрочного хранения. Когда речь идет о критичных для бизнеса про­цессах, провайдер сервисов интеграции не может слепо надеяться на ус­пешное вы­полнение удален­ною вызова — тем более в России, где качество каналов связи сильно варьируется,

Прикладные задачи, решаемые book logic при помо­щи SOA и Web-сервисов, выходят далеко за пре­делы пе­редачи коммерческих документов по модели EDI. Уже сейчас сервисы booklogic обеспечи­вают прозрачность складских остатков в магазинах, консолидацию катало­гов и анализ прайс-листов по­ставщиков.

ИНТЕГРАЦИЯ КАК УСЛУГА

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

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

Действительно, практика показывает, что опти­мальным решением проблемы многосторонней интеграции является построение общей инфраструк­туры. Причем вне зависимости от от­расли — общая инфраструктура обеспечивает и водоснабжение, и работу телефонных и поч­товых сетей. Суть процесса интеграции безграничного числа тер­миналов приобретает формат ус­луги, пре­доставляемой по подписке, и сопровождается отказом от индивиду­ального построения соб­ственной избыточной инфра­структуры каждым из участников. Дополнительным преимуществом та­кого под­хода к интеграции явля­ется автоматическое обновление функциональности у всех пользова­телей при добавлении повой функции в центре. Примером этого архитектурного преимущества мо­жет служить введение, скажем, тонального набора в АТС городской телефонной сети.

Появление первого поколения провайдеров интег­рационных сервисов было связано с технологией EDI (Electronic Document Interchange). Тогда эти провайде­ры были операторами сетей VAN (Value Added Network), которые обеспечивали доставку коммерческих до­кументов ЕDI еще без инфраструк­туры Internet. Те из них, которые успешно пережили появление internet, конвертируются в полноцен­ных провайдеров интег­рационных сервисов, добавляя в свои решения ряд интеллекту­альных функций. Среди наиболее извес­тных операторов VAN, работающих сегодня на рын­ке инте­грации, можно на­звать компании GXS, Inovis, ClickCommerce и Sterling Commerce. Они активно по­полняют линейки своих предложений, обеспечивае­мых в удаленном режиме, другими решениями — как прикладными,

ЧТО ПРОИСХОДИТ ВО ВЗРОСЛОЙ ЖИЗНИ? Если вы все еще «неправильно» связаны с матерью, вы избегаете отделения и независимого взрослого существования...

Что делает отдел по эксплуатации и сопровождению ИС? Отвечает за сохранность данных (расписания копирования, копирование и пр.)...

Конфликты в семейной жизни. Как это изменить? Редкий брак и взаимоотношения существуют без конфликтов и напряженности. Через это проходят все...

Что будет с Землей, если ось ее сместится на 6666 км? Что будет с Землей? - задался я вопросом...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: