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

Управление сервисом

Тонкая красота спецификации SOAP состоит в том, что она предусматривает ясное разделение функциональных требований сервиса - деловой информации, которой сервис будет манипулировать - из операционных требований сервиса это, например, команды, касающиеся маршрутизации сообщений, и получения доступа к сервису. Функциональные требования удовлетворены Body сообщения SOAP; операционные требования удовлетворены элементами в Header сообщения SOAP.

Keep it that way. Если Вы поместите поддержку регистрации сообщения в ваш объект Employee, то Вы будете должны сформировать реализацию регистрации сообщения, которая может анализировать(ся) Employee. Гораздо лучше иметь универсальную реализацию регистрацию сообщения, который может определить местонахождение соответствующего элемента в заголовке SOAP независимо от того, что содержится в его теле.

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

Что же должен сделать IT-отдел, чтобы ответить сегодняшним операционным требованиям, когда реализации WS-* спецификаций все еще находятся на рассмотрении системными продавцами?

Компромис. Используя существующие технологии, которые наиболее эффективно соответствуют вашим потребностям, с намерениями мигрировать на сервисные технологии, когда они станут доступны и полностью поддержаны вашими системными продавцами. Если Вы должны защищать передачу, используйте HTTPS; если Вы нуждаетесь в надежной(гарантированной) передаче сообщений, используете MSMQ.

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

Когда Вы должны спроектировать и сформировать такой сервис, следуйте за образцами, появляющимися от реализаций продавцов WS-* протоколов:
  • Работайте с консорциумом заинтересованных сторон, чтобы эффективно собрать требования; для требований вертикальной промышленности, работайте с торговыми партнерами и даже конкурентами.

  • Определите схему для заголовка SOAP, который может быть присоединен к любому сообщению, чтобы нести операционную информацию.

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

  • Составьте ваши схемы, заново используя работу, которая соотносится с действительно горизонтальными отношениями, например описание физического адреса.

  • Стройте итерационно; вложите капитал в формирование вашей инфраструктуры передачи сообщений, с допущением бюджета и времени.
 
« Предыдущая статья   Следующая статья »