|
Страница 15 из 17
Сервисный дизайн Сервисная ориентация - эволюционное развитие лучших методов формирования распределенных систем. Также, она извлекает образцы из успешных аспектов распределенных объектных технологий и ориентированных на сообщения решений связующего ПО (ПО, обеспечивающее прозрачную работу программ в неоднородной сетевой среде, middleware), и определяет антиобразцы из менее успешных аспектов той же самой архитектуры. Дон Бокс из группы "Indigo" выделяет четыре принципа, которые следует иметь в виду, рассматривая сервисную ориентацию:
- Принцип 1: Границы явны. Сервис взаимодействует явной передачей сообщений через границы. Мы не делаем никаких предположений о пространстве позади сервисных границ. Пересечение сервисных границ может быть дорогостоящим (например, Вы, возможно, должны охватить разные страны, трастовые границы, или среды выполнения). Мы явно указываем это в вызове сервиса, формально передавая определенные сообщения между сервисами. Явные границы позволяют нам формально выражать реализацию независимого взаимодействия - мы можем быть агностичными к выбору платформы, промежуточному ПО, или языку программирования, используемому для реализации других сервисов.
- Принцип 2: Сервисы автономны. Сервис ведет себя разумно, как независимый объект. Мы не делаем никаких предположений о пространстве между сервисными границами. В сервис-ориентированной среде нет никакого начальства. Сервис независимо развернут, версионизирован и управляется. Топология, в которой выполняется сервис, может и будет развиться. Сервис должен ожидать, что одноранговые сервисы могут и будут ломаться, и что он может и будет получать уродливые(поврежденные) или злонамеренные сообщения. Сервис должен быть построен, чтобы не "падать", используя (например) избыточность и отказоустойчивые методики.
- Принцип 3: Сервис публикует Схему и Контракт, а не класс. Сервисы взаимодействуют исключительно на их описании структур, используя схему, и поведения, используя контракт. Контракт сервиса описывает структуру сообщений и ограничения на получение сообщений. Формальность выражения позволяет машине проверять входящие сообщения, и позволяет нам защищать целостность сервиса. Контракты и схема должны остаться устойчивыми во времени, поэтому формируйте их гибко (например, через использование xsd:any в схеме) и это важно.
- Принцип 4: Сервисная совместимость основана на политике. И поставщики услуг и сервисные потребители будут иметь политики - операционные требования - для взаимодействий между границ. Простой пример провайдерской политики - то, что сервис может требовать, чтобы вызывающий имел правильную учетную запись у поставщика услуг. Со стороны потребителя, организация может требовать, чтобы вызовы сервиса через Интернет были зашифрованы, так что будет использовать только сервис, которое предлагает возможность обеспеченного двунаправленной защитой обмена данными. Сервисы выражают их возможности и требования в терминах машинно-читаемого выражения политик. Утверждения политик идентифицированы устойчивым, глобально-уникальным названием.
Индивидуальные утверждения политики непрозрачны к системе в целом; сервис просто должен быть в состоянии удовлетворить требования других политик.
Взаимодействия в пределах вашего сервиса должны придерживаться вышеупомянутых принципов. Эти принципы требуют формального выражения схемы, контракта, и политик между сервисами участвующими в сервис-ориентированной среде. В то время как механизмы, созданные для определенного случая на скорую руку могут быть разработаны для выражения границы сервиса, такие механизмы ограничены областью влияния изобретателя. Например, если Вы разрабатываете систему, которая выражает схему и контракт способом, который является распознаваемым только в вашем отделе, Вы обрекаете ваш сервис на непригодность его использования вне вашего отдела.
Чтобы полностью понимать выгоды сервисной ориентации, ваше выражение сервисной границы должно быть так широко принятым и способным к взаимодействию, насколько возможно. Индустрия ясно выбрала WS-* протоколы передачи через среду в сообщениях SOAP, как стандарт функциональной совместимости для сервисов. Сервисная ориентация, на практике, требует Веб-служб, сообщений SOAP, и использования WS-* протоколов.
Выбор технологии передачи сообщений, которая поддерживает сервисную ориентацию, означает выбор среди технологий передачи сообщений, которые поддерживают SOAP и WS-* протоколы. В текущей поставке технологий Microsoft, это означает .asmx в ASP.NET. Если Вы нуждаетесь в поддержке расширенных протоколов WS, используйте .asmx с WSE. В текущих технологиях передачи сообщений Microsoft, .asmx оказывает лучшему поддержку для выставления схемы, контракта и политики, независимую от реализации и способа взаимодействия.
Ключевая часть уважения сервисных границ в том, что в пределах границы может использоваться любая реализация. Как только Вы формально определили ваши сервисные границы с ASMX и/или WSE, Вы можете использовать любую технологию или стек передачи сообщений, чтобы осуществить обработку и обмен данными в пределах этих границ. Для простоты и последовательности, мы рекомендуем оставаться с сервисной моделью и использованием ASMX даже с сервисной границей. Нужно ли это для поддержки специфических возможностей или поддержки использования существующего развертывания, в любом случае, MSMQ, Remoting, или Enterprise Services - разумный выбор в границах сервиса. Они - не подходящие технологии, чтобы осуществить граничные интерфейсы вашего сервиса.
|