Ориентация на сервисы и её роль в Стратегии распределенных систем
Страница 17. Образцы сервис-ориентированных решений



Образцы сервис-ориентированных решений

Что Вы должны делать, чтобы сформировать распределенные системы сегодня? Вы должны погрузиться в полную переразработку вашего прикладного портфеля вокруг сервис-ориентированной модели? Вы должны только ждать и смотреть?

Опыт Microsoft, непосредственно подкрепленный опытом наших клиентов и партнеров предлагает более умеренный подход. Есть много бизнес и технических образцов, для которых сервисная ориентация даёт ясную выгоду уже сегодня.

Самый распространенный образец - информационная интеграция, изображенная в сценарии Rum Island crawl. Поскольку архитектура технологии развилась за прошедшие 30 лет, организации пришли к управлению или источнику обширного количества распределенных и избыточных данных. Законченное описание клиента, например, могло бы быть распространено поперек дюжины деловых приложений и баз данных. Эта информация редко полностью актуальна, и объединение этой информации для взаимодействия оптимального клиента (или партнера, или служащего) плохо поддержано. Сервисы информационной интеграции - эффективное средство и для представления вашего прикладного портфеля с унифицированным представлением этих ключевых объектов, и чтобы гарантировать последовательность информации поперек всех ваших конечных систем. Внутренний проект корпорации Microsoft - Алхимия(Alchemy) успешно обращается точно к такому же вызову, как и у наших собственных корпоративных хранилищ информации. Проекты информационной интеграции могут идти от тактических соображений, типа примера Rum Island, или от более широких стратегических - с дополнительным реинжинирингом информационного доступа и управления поперек предприятия.

Образец унаследованной интеграции изображает тактическое использование сервисов, чтобы сохранить существующие инвестиции в бизнес-приложениях, расширяя поставляемые функциональные возможности. Сервис мог бы добавить поддержку выполнения новых инструкций, например, перед существующим ERP package. Приложения проектировались бы, чтобы обмениваться сообщения с сервисом, который извлечет compliance-relevant данные и затем направит запрос к ERP package.

Предыдущий пример предлагает более широкий образец для сервисной ориентации: управление процессом. В этом образце, элементы "заголовка" используются, чтобы взаимодействовать ключевыми деловыми метаданными - с оборотного времени на клиенте запрос к объекту (тот, кто подтверждает) для определенных деловых решений. Это метаданные captured сервисом инфраструктуры, для объединенного анализа и/или в реальном масштабе времени. "Сервис-родные" процессы, включили бы эту информацию в заголовки SOAP, в то время как неродные приложения придется проектировать заново, чтобы передать метаданные, как сообщение на сервер governance .

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

Много сервисов поставляют некоторую форму ресурса virtualization. Вот - некоторые примеры:
  • Контекстно-зависимая и чувствительная к содержанию маршрутизация запросов, типа посылки real-estate inquiry агенту по указанной географии, который специализируется в свойствах фермы.

  • Маршрутизация запросов к разделенным банкам сообщений (без необходимости понимать схему разделения запрашивающему).

  • Балансировка загрузки запросов поперек доступных средств - от клиента сервиса представителей в каналах потокового видео.

Наконец, организации весьма успешно использовали сервисы для externalization процесса. Веб-службы используются, чтобы помочь надежно договариваются об обработке платежной ведомости, компенсации расхода служащего, и logistical поддержке. Поставщики услуг сотового телефона и Интернет-порталы используют Веб-службы, чтобы объединить содержание. Стоящие перед клиентом организации используют Веб-службы, чтобы сформировать составные предложения, типа пакетов, включая рентные автомобили и стоимость авиабилетов. Ключ к успешному воплощению процесса на сегодняшнем стеке технологии это управлять вашим собственными ожиданиями - компромиссом ваших требований к пределам существующих технологий так, чтобы Вы не потеряли прибыль или сохранения на построении инфраструктуры сервисов, которое Вы замените через несколько лет.

Об авторе

Майк Бернер - архитектор решений в Microsoft Developer and Platform Evangelism Group. Майк в настоящее время сосредотачивается на исследовании лучших методов проектирования, построения, и управления сервис-ориентированными решениями.

В течение прошедших семнадцати лет, Майк формировал крупномасштабные распределенные системы, от сетей университетского городка до интерактивных телевизионных систем управления контентом и Веб-служб масштаба Интернета. За его шесть лет в Microsoft, Майк сосредоточился на техниках построения для XML-управляемого сотрудничества, включая и решения B2B и возможностей конечного пользователя. До присоединения к Microsoft в 1998, Майк был Vice President of Engineering в Alexa Internet, где он управлял разработкой Веб-метаданных Alexa, и сервисов "recommender", одной из первых суперскалярных веб-служб XML.
 
« Предыдущая статья   Следующая статья »