Уровень сложности: простой IBM developerWorks, IBM developerWorks, IBM
05.2007 В этой главе мы опишем сценарий-пример, который используется в этой книге для иллюстрации обсуждений. Мы также укажем на его особенности, которые делают его подходящим для применения разработки, управляемой моделями.
В этой главе мы опишем сценарий-пример, который используется в этой книге для иллюстрации обсуждений. Мы также укажем на его особенности, которые делают его подходящим для применения разработки, управляемой моделями.
Мы выбрали этот сценарий для иллюстрации применения MDD к разработке сервисной шины предприятия (enterprise service bus, ESB) в рамках сервисно-ориентированной архитектуры (SOA) масштаба предприятия. Этот сценарий основывается на сплаве индивидуального опыта авторов, но не отражает никакой конкретный проект, реализованный авторами в прошлом.
Проект, который описывает данный сценарий, начинался не как разработка, управляемая моделями, а как простой ESB-проект,концентрирующийсянашаблонахин--проект, концентрирующийся на шаблонах интеграции и повторном использовании существующих наработок. Проделав еще не слишком много работы по формализации архитектуры и шаблонов, команда проекта признала преимущества разработки, управляемой моделями, и стала создавать модели на унифицированном языке моделирования (UML). По этой причине первоначальные наброски архитектуры не являются UML-моделями. -моделями.^то отражено в описании сценария в этой главе и в гл. 7, «Разработка шаблонов для сценария», в описании информации, на основе которой создается модель дизайна.
В проекте, в котором модель создается с самого начала, вы применяете UML на всем протяжении процесса проектирования.
2.1 Структура предприятия
Предприятие, представленное в этом сценарии, предлагает свои продукты многим покупателям, с которыми заключены контракты значительной сложности. В сценарии рассматриваются функции для работы с покупателями и их поддержка серверными системами. На предприятии проводится обновление технологии, при котором во множество подразделений, ответственных за разные группы продуктов, вводятся новые клиентские системы. Они используют информацию от серверных систем, как общекорпоративных, так и уровня подразделения. Серверные системы также нужно заменить. Однако время выполнения двух этих программ обновления нельзя полностью синхронизировать, поскольку подход типа «все сразу» считается слишком рискованным.
Бизнес-сценарий, на котором основываются примеры, приводимые в этой книге, предполагает, что архитектура предприятия является установившейся и что все будущие проекты в подразделениях будут привязаны к этой архитектуре.
В качестве архитектуры предприятия принята SOA. Архитектура предприятия основывается на нескольких готовых пакетах, которые помогают приложениям-обработчикам запросов взаимодействовать с покупателями, управлять бухгалтерской информацией и службами во всем историческом диапазоне и в конечном счете использовать вспомогательные приложения. В настоящее время бухгалтерская информация и информация о покупателях управляется старыми системами. Некоторые из них будут через какое-то время заменены новыми, чтобы удовлетворять требованиям новой функциональности.
Чтобы снабжать клиентские системы информацией о покупателях и счетах, поступающей из серверных систем, а также для обеспечения обновления информации в серверных системах, в архитектуре предприятия используется сервисно-ориентированная интеграционная шина масштаба предприятия, или ESB
Системы уровня подразделений должны использовать ESB для любой интеграции между системами, взаимодействующими с покупателями, и серверными приложениями. Такова цель, о которой проинформированы все подразделения, и которую они должны учитывать.
В рамках проектов уровня подразделений будет вестись разработка нескольких бизнес-процессов. В архитектуре предприятия управление бизнес-процессами понимается как уровень, не входящий в ESB, хотя процессы могут инициироваться из ESB, а процесс может вызывать службы из ESB. В архитектуре предприятия любой долго-функционирующий процесс должен обрабатываться на уровне управления бизнес-процессами, а не напрямую из ESB. Для архитектуры предприятия требуется каркас управления системой (System Management Framework), который ведет мониторинг всех приложений уровня предприятия, включая ESB.
Начальный набор продуктов для ESB включает в себя:
- WebSphere® Business Integration Server Foundation;
- WebSphere Business Integration Message Broker.
2.1.1 Возможность использования разработки, управляемой моделями
Даже на этой ранней, высокоуровневой стадии определения архитектуры можно найти ряд признаков, указывающих, что данная программа разработки является кандидатом на применение MDD.
Рис. 2-1. Общий вид архитектуры предприятия
Есть проекты разработки, для которых требуется создание интеграционных служб, которые работали бы через ESB во всех подразделениях. Любые инвестиции в создание необходимого каркаса и инструментария для разработки интеграционных служб в MDD, скорее всего, окупятся многократно.
Хотя подразделения предприятия имеют значительную автономию в отношении приобретения и разработки средств IT, предварительное определение хорошо структурированной архитектуры предприятия и установление единого руководства, обеспечивающего соблюдение подразделениями этой архитектуры, скорее всего, увеличит количество повторяющихся типовых операций. Это повысит продуктивность и успешность подхода, управляемого моделями.
2.1.2 Признаки несоответствия сценария подходу, управляемому моделями
Хотя налицо факторы, которые предположительно внесут свой вклад в потенциальный успех MDD, это предприятие не делает существенных вложений в UML и в выработку соответствующих навыков моделирования. Кроме того, у IT-менеджеров могут быть опасения, связанные с тем, как обеспечить соблюдение такого подхода ГТ-пос-тавщиками, с которыми заключены контракты.
Дальнейшее обсуждение возможности использования MDD будет приведено после помещенного ниже описания интеграционной архитектуры. Тогда ситуация с окупаемостью инвестиций при использовании каркаса в масштабах предприятия станет более ясной.
2.2 Интеграционная архитектура
Архитектура предприятия предполагает, что сервисно-ориентированный подход должен применяться ко всем новым разработкам. Сюда входит и ESB, где в качестве базового принципа используется сервисно-ориентированная интеграция (service-oriented integration, SO I).
Сервисно-ориентированая интеграция поддерживает SOA, где приложения не вызывают службы других приложений напрямую, но вызывают службы, которые относятся к интеграционному промежуточному программному обеспечению. Эти интеграционные службы выполняют посреднические операции, такие, как проверка или трансформация. Они также обеспечивают интеграционную оркестровку (orchestration) перед вызовом одной или нескольких служб, которые предоставлены другими приложениями.
Примечание. Оркестровка - последовательность и условия, при которых одна Web-служба вызывает другие Web-службы, чтобы выполнить некоторую полезную функцию.
Интеграционные службы в данном случае не поддерживают долговременные бизнес-процессы с сохранением состояния, поскольку они явным образом отнесены в архитектуре предприятия к отдельному уровню управления бизнес-процессами.
Высокоуровневая архитектура ESB определяет сервисно-ориентированные принципы, которым должны соответствовать службы, размещаемые в ESB. В данном сценарии особенно важно, что поставщики и клиенты служб связаны нежестко. Также важно, что, хотя клиенты служб должны знать о контракте службы, они не знают о деталях ее реализации. Это позволяет поставщику изменять реализацию независимо от клиентов, соединяющихся с ESB. Переход со старых систем на новые OTS-паке-ты - процесс длительный, и он должен происходить без нарушения обслуживания клиентов.
Еще один принцип архитектуры ESB и самой архитектуры приложения состоит в том, что интеграционные службы, размещаемые на ESB, должны иметь возможность повторного использования, и использоваться многократно множеством приложений как внутри подразделения, так и разными подразделениями. Принцип нежесткой связи помогает достижению этой цели. Также этому способствует применение портфеля поиска служб, с помощью которого обеспечивается выявление имеющихся служб и обязательное использование канонического формата данных для интеграционных служб. Уже имеется в зачаточном состоянии модель данных и связанный с ней канонический формат данных. Они разрабатываются под централизованным руководством, чтобы не допустить разработки служб типа «от точки к точке».
Готовые приложения и наследственные системы-провайдеры не соответствуют каноническому формату Enterprise Canonical Data Format (ECDF). Следовательно, предоставляются интеграционные службы ESB с фасадами для входящих запросов и фасадами, через которые они вызывают службы провайдеров, не входящие в ESB. В фасадах применяются трансформации для преобразования данных в формат ECDF и обратно.
2.2.1 Структура ESB
Шина ESB имеет в своей структуре два уровня. Службы, относящиеся к внутреннему уровню, работают только с ECDF и обеспечивают оркестровку интеграции. Службы внешнего уровня - это фасады, которые отвечают за трансформацию данных из внешних форматов в ECDF и за другие барьерные операции, такие, как проверка, аудит, авторизация и управление взаимодействием с внешними клиентами и поставщиками. ESB также предоставляет службы-утилиты, которые поддерживают общие функции и которые вызываются как из служб-фасадов, так и из интеграционных служб.
На рис. 2-2 показана простая сквозная служба (синхронная или однонаправленная) с одной интеграционной службой (integration service, IS) на внутреннем уровне. Эта служба вызывается из клиентского офисного приложения через фасад интеграционной службы (integration service facade, ISF) и вызывает серверную службу-поставщик через фасад поставщика (PF). И служба-фасад, и интеграционная служба могут вызывать службы-утилиты, относящиеся к внутреннему уровню.
Рис. 2-2. Структура ESB
Службы-утилиты (utility services, U) также являются частью архитектуры ESB. Они отличаются от тех служб, о которых мы говорили ранее, тем, что они реализуются только один раз и являются частью самой инфраструктуры ESB.
На рис. 2-3 показана еще одна сквозная служба в ESB. В данном случае имеется асинхронная служба (ISF, IS и PF показаны малыми голубыми кружками) и три дополнительных вида служб, которые называются возвратными службами (callback services). Эти службы позволяют возвратить асинхронный ответ в клиентское офисное приложение, пославшее запрос. Возвратная служба фасада поставщика (provider facade call back, PFCB) предоставляет интерфейс, к которому может обращаться служба-поставщик для возврата ответа. Эта служба, в свою очередь, вызывает возвратную интеграционную службу (integration service call back, ISCB) и возвратный фасад клиента (requester callback facade, RCBF), и все заканчивается вызовом возвратной службы клиента. Это, по сути, две односторонние службы, которые сохраняют ID транзакции, который позволяет сопоставить ответ и запрос в возвратной службе клиентского офисного приложения.
Итак, сквозную интеграцию обеспечивают шесть типов служб:
- фасад интеграционной службы,
- интеграционная служба,
- фасад службы-поставщика,
- возвратная служба фасада поставщика,
- возвратная служба интеграционной службы,
- возвратный фасад клиента.
Рис. 2-3. Дополнительные типы служб
В этих двух простых примерах показаны базовые принципы использования различных типов служб. Однако эти службы являются строительными блоками, из которых можно составлять более сложные сквозные службы.
Архитектура ESB требует, чтобы любые фасады интеграционных служб, размещаемых на ESB, предоставляли внешним отправителям запросов интерфейс, определенный на языке Web Services Description Language (WSDL). Этот интерфейс специфицирует SOAP-сообщения через HTTP, JMS и MQ.
Службы внутреннего уровня ESB также должны иметь четко определенные WSDL-ин-терфейсы. В этом случае для повышения эффективности можно использовать нестандартное легкое соединение. Службы ESB реализуются либо в WebSphere Application Server, либо в WebSphere Business Integration Message Broker.
В любой реальной архитектуре ESB нужно учитывать нефункциональные аспекты, такие, как безопасность, доступность и преодоление сбоев. Эти аспекты являются частью дизайна всей архитектуры, и они не включены в данный сценарий, в котором акцент делается на управляемой моделями разработке служб, размещаемых в ESB. Мы не говорим, что эти аспекты не важны для MDD. Мы кратко рассмотрим их в гл. 5, «Жизненный цикл решения, создаваемого с использованием разработки, управляемой моделями».
2.3 Определение шаблонов
Наш первый шаблон - это высокоуровневая архитектура ESB, в которой интеграционная служба имеет оболочки-фасады. Определяются типы служб, которые будут размещаться. Также задается первый уровень ограничений, касающихся того, как эти службы могут вызывать друг друга и как могут взаимодействовать с клиентами и поставщиками, не входящими в ESB.
Рис. 2-4. Шаблон связи служб в ESB
- Фасад интеграционной службы представляет сквозную службу внешнему клиенту. Он является фасадом единой интеграционной службы.
- Интеграционная служба может быть вызвана через один или через несколько соответствующих фасадов. Каждый фасад может представлять службе другой формат запроса. Фасады должны работать с форматом, как можно более близким к формату запрашивающего приложения.
- Интеграционные службы могут вызывать одну или несколько служб-поставщиков через фасад поставщика.
- Интеграционные службы могут вызывать другие интеграционные службы.
Имея эту архитектуру, рассмотрим теперь более подробно шаблоны интеграционных служб, которые будут поддерживаться в ESB.
2.3.1 Шаблоны поведения при взаимодействии
Сначала рассмотрим некоторые фундаментальные контракты на поведение (contracts on behavior) между клиентами и поставщиками службы. В контексте данной книги контракт на поведение определяется как шаблон поведения, включающий ряд аспектов взаимодействий.
В контракте на поведение определяется согласованный набор операций, которые можно применить к взаимодействию. Эти операции определяют требования, которые налагаются на приложения, составляющие запросы к службам, и на промежуточное программное обеспечение - поставщиков и службы. Эти требования скорее технические, чем требования бизнеса, но тем не менее от технологий и протоколов они не зависят. Например:
- синхронность, асинхронность или односторонность;
- обновление или только-для-чтения;
- ответственность за обработку ошибок;
- ответственность за вывод сообщений об ошибках;
- корреляция между запросами и ответами;
- аудит.
Каждый контракт на поведения несет с собой набор требований к клиенту и поставщику в любом взаимодействии. Любая служба, размещаемая на шине ESB, поддерживает все требования одного из специфических контрактов на поведение и когда она работает как поставщик, и каждый раз, когда она делает запрос к поставщику.
Контракты на поведение, используемые в нашем сценарии, подробно описываются в гл. 5, «Жизненный цикл решения, создаваемого с использованием разработки, управляемой моделями».
2.3.2 Шаблоны отдельных служб
Следующий уровень абстракции - это изучение шаблонов, которые применяются к отдельным типам служб. Они объединяют архитектурные принципы ESB, применя-,применяемые к конкретным типам служб, с контрактом на поведение.
Шаблоны фасадов
Фасады и их возвратные службы включают в себя набор стандартных граничных функций, которые обрабатывают запрос или ответ, обеспечивая его соответствие архитектуре ESB, и выполняют необходимые преобразования. Шаблоны фасадов также обрабатывают взаимодействия служб и ошибки в соответствии с выбранным контрактом на поведение.
Интеграционные службы
Внутренние интеграционные службы более сложны, поскольку обеспечивают оркестровку интеграций. Пример типа оркестровки, поддерживаемый шаблонами интеграционных служб, - это запрос на обновление одного целевого элемента, который может перенаправляться альтернативным службам-поставщикам на основе содержимого сообщения. Шаблоны интеграционных служб подробно рассматриваются в гл. 5, «Жизненный цикл решения, создаваемого с использованием разработки, управляемой моделями».
Не так просто создать полный набор шаблонов для поведения интеграционных служб. Однако если ограничиться охватом 80/20 (То есть ограничиться теми 20 % шаблонов, которые покрывают 80 % поведения), то возможно определить набор шаблонов, который будет пополняться по мере уточнения требований. Шаблоны интеграционных служб тесно связаны с базовыми шаблонами электронного бизнеса.
2.3.3 Возможность использования разработки, управляемой моделями
По мере того как мы детализируем архитектуру предприятия, определяя архитектуру интеграции, и шаблоны, которые можно определить, исходя из данной архитектуры, становится очевидным, что разработка служб для ESB является явным кандидатом для разработки, управляемой моделями.
Мы коротко описали, как архитектуру интеграции можно определить в виде иерархического набора шаблонов. Имея такой набор шаблонов, мы можем конфигурировать шаблоны под конкретные ситуации. Это означает, что, применяя разработку, управляемую моделями, к архитектуре ESB, можно реализовать два преимущества из числа упомянутых в разд. 1.3, а именно, опыт, который фиксируется в шаблонах и трансформациях, и его многократное использование.
Уровень абстракции, достигаемый при использовании шаблонов, означает большие возможности повторного применения и значительное увеличение возможной экономии средств.
2.3.4 Признаки возможных трудностей при использовании MDD
Нельзя назвать какие-то явные технические факторы, которые мешают применению щим. Архитектурный каркас, если его твердо придерживаться, будет подходящим в полной мере.
Помешать внедрению данного подхода могут многие организационные факторы. Хотя разработку, управляемую моделями, хорошо понимают архитекторы, которые отвечают за архитектуру предприятия и за входящую в нее архитектуру ESB, такой подход недостаточно признан среди руководителей IT-отделов подразделений.
IT-отделы подразделений обычно имеют значительную автономию при определении IT-стратегии. Организация и выполнение интеграционной программы масштаба предприятия (ESB) сами по себе могут быть предметом дискуссий. Дополнительное требование использования стандартных шаблонов и нового метода разработки, который эти шаблоны поддерживает, потребует решения организационных проблем.
2.4 Автоматизация
Мы описали архитектуру ESB в виде шаблонов, которые накладывают ограничения на реализацию служб. Эти шаблоны можно использовать в качестве исходных данных для традиционной фазы подробного проектирования каждой службы, которая будет реализовываться для ESB. Поскольку службы создаются под контролем менеджмента IT-отделов разных подразделений, которые имеют контракты с разными поставщиками IT-услуг, это может привести к использованию разных сред разработки. Также от каждого подразделения и от каждого поставщика требуются определенные навыки для реализации сервисно-ориентированной интеграции и для полного понимания архитектурных ограничений, накладываемых ESB, а также ESB-технологий.
Однако на уровне предприятия применение шаблонов открывает возможности для автоматической генерации служб и связанных с ними артефактов.
Моделирование шаблонов ESB-служб и генерация экземпляров служб по этим моделям включается в качестве обязательного требования в архитектуру предприятия. Rational Software Architect включается в список необходимых продуктов как средство моделирования структуры ESB и ESB-служб и для создания трансформаций для этих моделей. С помощью трансформаций генерируется код, реализующий службы, и связанные с ними артефакты. Все это способствует созданию полного пакета, который можно быстро разместить и протестировать.
Организационные трудности понимаются и преодолеваются на трех уровнях - техническом, организационном и административном.
2.4.1 Технический уровень
Реализация ESB - это проект масштаба предприятия, а не подразделения, и управлять им нужно на уровне всего предприятия. Необходимо создать каркас разработки, управляемой моделями. Он включает исходный набор шаблонов в виде моделей с трансформациями для генерации готовых к размещению служб и инструментарий,
который помогает разработчикам служб и направляет их. Также обрабатывается связь ESB с управлением всей системой предприятия.
В качестве компенсации в подразделениях недостаточных навыков разработки, управляемой моделями, создается базовый каркас. Такой каркас также по большей части устраняет необходимость в наличии навыков моделирования за пределами централизованно управляемого ESB-проекта.
Новые шаблоны создает центральная группа ESB в соответствии с требованиями подразделений. Применение шаблонов поддерживается наличием более чем одного интерфейса. Для некоторых пользователей разрабатывается специально настроенный пользовательский интерфейс, чтобы создание ESB-служб в проектах уровня подразделений требовало только общих навыков интеграции, а не глубоких знаний технологий моделирования.
2.4.2 Организационный уровень
Устанавливается необходимое управление. Одна головная группа владеет всеми процессами, системами и элементами управления на уровне предприятия, которые позволяют в интеграционных проектах, выполняемых в подразделениях, генерировать свои собственные службы и передавать их в головную группу для сертификации и размещения. Также обеспечивается централизованное распространение информации о существующих и готовящихся возможностях с целью поощрения повторного использования служб и для предотвращения размещения новых служб с дублирующей существующие службы функциональностью. Подход MDD помогает работе такой головной группы. При реализации архитектуры через шаблоны уменьшается число проблем управления и возникает существенный прирост качества и согласованности разрабатываемых служб.
2.4.3 Административный уровень
Создается программа по распространению информации о ESB и разработке, управляемой моделями, во всех подразделениях. Осуществляется финансовое стимулирование, чтобы реализовать те преимущества, ради которых и вводится ESB.
2.5 Заключение
В этой главе мы описали сценарий, который мы используем в данной книге для демонстрации применения MDD. В ходе обсуждения сценария были выявлены возможности для создания шаблонов, и это показывает, что MDD даст в данном проекте положительный экономический эффект. Мы также идентифицировали несколько нефункциональных требований для успешной реализации MDD.
Об авторе  | | | команда developerWorks работает над созданием полезных материалов для разработчиков |
Выскажите мнение об этой странице
| 
