Первые элементы soad

Кроме осознания необходимости использования при формализации SOAD комбинации OOAD, BPM и EA, существует также несколько важных понятий и аспектов SOAD, которые пока не получили своего смыслового наполнения:

• Классификация и агрегация сервисов

• Политики и аспекты использования

• Сходящиеся процессы

• Семантические переходы

• Сборка сервисов и передача знаний

Классификация и агрегация сервисов

Сервисы имеют различное назначение и могут использоваться различным образом: например, программные сервисы отличны от бизнес-сервисов (как ранее было показано на Рис. 5). Кроме того, отдельные сервисы могут быть оркестрованы (собраны) в законченные сервисы более высокого уровня. Композиция сервисов упрощается исполняемыми моделями (например, выполненными в BPEL) - это то, с чем не оперируют традиционные средства и методы моделирования.

Политики и аспекты использования

Сервис имеет синтаксические и семантические характеристики, а также характеристики качества сервиса (QoS), которые должны учитываться в моделях. В то же время формальные интерфейсные контракты взаимодействия сервисов представляют собой нечто большее, чем может описать язык Web Services Description Language (WSDL). В этой связи спецификация WS-Policyявляется весьма важной в качестве дополнения к WSDL. Желательным свойством, наряду с хорошо известным принципомархитектурной трассируемости, являетсябизнес-трассируемость(в оригинале - business traceability; traceability, трассируемость - финансовый термин, означающий возможность отнесения затрат на конкретную операцию или объект затрат - прим. перев.): должна быть возможность прямой привязки всех возникающих в ходе разработки системы артифактов к языку, понятному неэксперту предметной области. Это особенно важно для абстракций, напрямую используемых на бизнес- и сервисном уровне. Закон Сарбейнса-Оксли (SOX) (англ. Sarbanes-Oxley act - закон, согласно которому компании, акции которых котируются на фондовых биржах, регулируемых Комиссией по ценным бумагам и биржам, должны вести финансовую отчетность в соответствии с общепринятыми принципами бухгалтерского учета - прим. перев.) (см. статьюAstor) является примером, для реализации которого и может потребоваться бизнес-трассируемость.

Процесс моделирования: сходящийся

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

Семантические переходы

В любой SOA для синтаксиса вызовов важно наличие формального интерфейсного соглашения. При моделировании предметной области также должны быть решены вопросы семантики (значение параметров и т. д.). Ответы на эти вопросы являются ключевыми при разработке любого B2B-сценария или сценария динамического вызова. Данные сценарии являются краеугольными понятиями концепции SOA, которая привносит гибкость и быстроту адаптации как ответ на новые бизнес-нужды в мире слияний, поглощений, бизнес-реструктуризаций и глобализации.

Сборка сервисов и передача знаний

Данный вопрос относится к области управления знаниями и концепции жизненного цикла сервиса: как правильно разработать сервисы и сделать их доступными для повторного использования сразу после концептуализации? Сервисы необходимо идентифицировать и описывать, имея ввиду один из главных критериев SOA - свойство повторности использования (и возможность сборки). Если компонент (или сервис) не может быть повторно использован, он не должен представляться как сервис. Он может быть связан с другим сервисом архитектуры предприятия, но не будет сервисом в полном смысле этого слова. Однако, даже если свойство повторности использования закладывается с самого начала, методология проектирования должна иметь формализованную методологию сборки сервисов. Использование сервиса несколькими клиентами - основная цель проектирования в SOA (например, при создании реестра сервисов - UDDI-реестра масштаба предприятия).