|
Страница 14 из 17
Дизайн для расширяемости Никогда не было достаточного понимания требований, чтобы выдержать испытание временем. К future-proof ваших сервисов и решений, Вы должны проектировать расширяемо. Есть две ключевых области расширяемости: расширяемость объекта и поведенческая расширяемость.
Основной подход к расширению информации, смоделированной в объекте - это позволить последовательность элементов Extension, которые могут иметь любое содержание. Обычно они идентифицируют себя названием, и ссылкой на их собственную схему. Включая эту поддержку в определении объекта, Вы создаете полиморфные объекты. Расширенный объект Employee все еще может обрабатываться всеми сервисами, которые понимают базовый объект, но могут также поддержать расширенную обработку сервисами, которые понимают, скажем, расширение названное TravelProfile.
Различные географии требуют различной информации. Налоговый идентификатор, например, может быть по-разному структурирован в различных странах. Не делайте Social Security Number элементом верхнего уровня в вашем объекте Employee; лучше иметь элемент TaxID, который может идентифицировать свой подтип как "US-SSN".
В отличие от объектной ориентации, сервисная ориентация использует позднее связывание(late binds) поведения - "поведение" объекта прикрепляется к нему, когда он направлен сервису, который знает, как воздействовать на информацию, содержащуюся в объекте.
Поведенческая расширяемость достигается в первую очередь выставляя сервисы, которые могут добавить значение, управляя объектом. Есть множество эффективных образцов для связи нового поведения с объектами, но их обзор вне рамок этой статьи. Поучительный пример - сервис, который действует как "фасад" для другого сервиса, являясь способным к управлению элементом большего объекта. VerifyEmployeeAddress мог бы принять объект Employee, извлечь элемент Address, и передать его более универсальному сервису VerifyAddress, предлагаемому соответствующим национальным почтовым сервисом.
Ключевая часть руководства, следовательно, в составлении объектов из стандартизированных элементов, максимизируя и возможность многократного использования сервисов, и последовательность обработки общих информационных элементов.
Отделить функциональные и операционные отношения Думайте и о вашем бизнес-сервисе и о сервисах инфраструктуры, как поставляющих возможности. Сервисы инфраструктуры поставляют горизонтальные возможности, также называемые перекрестные отношения(cross-cutting concerns) или, несколько загадочно, аспекты.
При выполнении сервис-ориентированного анализа, ваш вызов - идентифицировать эти перекрестные отношения и факторизировать их из ваших деловых объектов. Вы захотите, насколько это возможно, иметь единственную реализацию каждого сервиса инфраструктуры, что даёт возможность конвейеризации, превращая полные операционные требования в обмен индивидуальными сообщениями.
Ваш портфель инфраструктуры сервисов вероятно будет смешением и покупных продуктов и созданных внутри компании, с большим предпочтением покупке, если соответствующая реализация будет доступна на рынке. Эта тема развита более подробно в теме "Управление сервисом" ниже.
Помнить клиентов Упражнения в пользователь-центрированном дизайне - важная часть сервис-ориентированного анализа. Каковы варианты использования этих сервисов? Кто вызовет их и зачем? Пользователи каких ролей обратятся к сервисам? Кто должен иметь возможность вызвать сервис и кто не должен? Какие устройства и требования должны быть поддержаны? Мы должны разработать сервисных агентов, чтобы упростить доступ к сервисам от любого из этих устройств?
Размышления при моделировании информации для клиентской манипуляции включают следующее:
- Использовать только типы XSD (и сложные типы, составленные из типов XSD); не привязываться к операционной системе, кодируя данные определенным для неё способом.
- Схемы должны выражать ограничения на значения данных, чтобы позволить клиентам проверять правильность запросов обновления перед отправкой; клиентская проверка правильности может очень уменьшить издержки и неудовлетворенность сервисом, отклоняющим запросы из-за некорректных значений. (Конечно, сервис тоже должен проверять правильность значений, несмотря на то, что публикует ограничения)
- Ссылочная информация должна быть с временными метками или как-либо иначе версионизирована, чтобы поддержать кэширование, дельта-обновления, и условные запросы обновления.
Когда сервис станет доступен, умные люди в вашей организации найдут способы использовать его. Не делайте предположений, что клиенты, на которых Вы ориентируетесь во время разработки, являются единственными клиентами, которые будут когда-либо вызывать сервис. Не помещайте в клиента ожидания чего-либо, не указанного в сервисном контракте, и не доверяйте клиенту, он может посылать сервису не только правильные запросы. |