Компонентная архитектура сервисов (SCA) - это множество спецификаций, описывающих модель построения приложений и систем с использованием сервис-ориентированной архитектуры (SOA). SCA расширяет и дополняет предыдущие методы реализации сервисов и основывается на открытых стандартах, таких как веб-сервисы.
По-сути, SCA обеспечивает программную модель для реализации SOA.
Спецификация состоит из двух основных частей, описывающих методы
Разработчиком спецификации является консорциум Open SOA Collaboration (www.osoa.org). Текущая версия спецификации - 1.0 от 21 марта 2007 г. Некоторые части спецификации приняты позднее, например SCA Assembly Extensions for Event Processing and Pub/Sub V1.00 - 30 апреля 2009 г. Существует черновик версии 1.1, выпущенный 31 мая 2011. Несмотря на то, что это - черновик, он уже поддерживается Oracle.
SCA подчеркивает независимость способа реализации и объединения сервисов от возможностей инфраструктуры и используемых методов доступа. Компоненты SCA обслуживают бизнес-уровень и используют минимум API промежуточного слоя.
Данная спецификация поддерживает реализации сервисов, написанные с использованием различных языков программирования, включая объектно-ориентированные и процедурные языки, такие как Java, PHP, C, C++, COBOL, языки-подмножества XML, такие как BPEL и XSLT, а так же языки декларативного программирования, такие как SQL и XQuery. SCA так же поддерживает различные стили программирования, включая асинхронное, ориентированное на обработку сообщений и стиль "запрос-ответ".
Так же спецификация поддерживает большое количество методов доступа к сервисам: веб-сервисы, системы обмена сообщениями, CORBA IIOP и т.д. Связывание сервисов друг с другом осуществляется декларативно и не зависит от кода реализации самих сервисов. Инфраструктурные возможности, такие как обеспечение безопасности, транзакции и использование гарантированной доставки, так же подключаются декларативно и отдельно от кода реализации сервисов. Использование инфраструктурных возможностей осуществляется посредством механизма политик.
Одной из целей разработки SCA является упрощение создания сервисных компонентов: программист может сконцентрироваться на задачах бизнес-логики, и не обращать внимание на инфраструктурные вопросы. Спецификация так же предлагает прозрачную модель объединения сервисных компонентов в бизнес-решения с обеспечением декларативной информацией, определяющей связи сервисов, ссылок и используемых протоколов.
Для представления бизнес-данных используются сервисные объекты данных - Service Data Objects (SDO), которые формируют параметры вызова и возвращаемые сервисами значения, а так же обеспечивают унифицированный доступ к бизнес-данным в дополнение к унифицированному доступу к бизнес-сервисам, реализованному SCA самостоятельно. Т.е. SCA предоставляет унифицированный доступ к бизнес-сервисам, а SDO в добавок к этому - унифицированный доступ к бизнес-данным.
Введение такого унифицированного метода доступа к данным позволяет освободить разработчика от необходимости понимания множества различных форматов данных и программных интерфейсов, которые необходимы для их обработки (например, JDBC для реляционных данных, JAX-P для XML и т.д.) Так же SDO поддерживает разъединенный, оптимистически-обновляемый стиль программирования, где данные считываются из некоторого источника, обновляются клиентским приложением и передаются обратно в оригинальное месторасположение без необходимости блокирования исходных данных на время их обработки.
Ниже приведен словарь, включающий в себя основные понятия спецификации SCA.
Сервис представляет интерфейс, реализуемый компонентом либо целой SCA-сборкой - композитом. Данный интерфейс может использоваться клиентом композита либо компонентом. Сервис, реализованный извне композита, называется внешним сервисом.
Компонент представляет часть бизнес-логики. Это может быть логика процесса, такого как BPEL- или BPMN-процесс, логика маршрутизации, такая как Mediator или другие компоненты. Компонент - ядро SCA и может быть реализован на любом языке, поддерживаемом данной спецификацией. Будучи однажды определенным, компонент может декларативно конфигурироваться с помощью механизма свойств.
Ссылка - это зависимость от сервиса, предоставляемого другим компонентом, другой SCA-сборкой или внешней сущностью, такой как удаленный веб-сервис. Ссылка на сервис, реализованный вне композита, называется внешней ссылкой. Ссылки позволяют компоненту взаимодействовать с другими сервисами. Ссылки разрешаются во время загрузки или во время исполнения.
Модель сборки описывает как сервисы определяются и настраиваются.
Связь. Сервисы и ссылки объединяются вместе с помощью связей. Связь обозначает зависимость между компонентами или между компонентом и внешней сущностью.
Соединение (wiring). Компоненты объединяются с помощью связей, которые указывают каждому компоненту, какие у него есть источники информации и какие приемники. Соединения описываются декларативно. SCA не требует, чтобы источник и приемник имели одинаковые типы (например, допускается соединение Java и WSDL). Для упрощения разработки SCA поддерживает автоматические соединения (Autowiring). Пока информация о ссылках однозначна,
контейнер имеет возможность соединять компоненты во время исполнения.
Связывание (binding). Модель SCA осуществляет коммуникацию между сервисами и ссылками с помощью механизма связывания, поддерживающего множество
технологий. Все совместимые со спецификацией SCA реализации должны поддерживать SCA Service Binding и WebService Binding. Связывания используются сервисами и ссылками. Сервисы используют связывания для определения того, как они могут вызываться. Ссылки используют связывания для определения того, как они могут вызывать сервисы.
Композит. Компоненты группируются в композиты. В зависимости от описания, композит может использоваться как сервис либо как новый компонент. Таким образом SCA поддерживает рекурсивную сборку.
Для реализации QoS и нефункциональных требований модель SCA предлагает механизм политик (Policy Framework). Политики могут использоваться для обеспечения безопасности, доступности, транзакционности и реализации других требований.
Политики могут быть ассоциированы с каждым компонентом. Сервисы и ссылки могут иметь множественные политики для обеспечения различных способов доступа. Основные элементы механизма политик это Намерения (Intents), Профили (Profiles) и Множества политик (Policy Sets).
Намерение - это абстрактное утверждение об ограничении QoS для реализации компонента. Например, сообщение может быть конфиденциальным, соответственно определяется намерение с названием confidentiality.
Профайл - это набор наименований намерений. Намерения, на которые ссылается Профайл, отображаются на конкретные реализации во множестве политик.
Множество политик соответствует реализации Намерений. Определяет специфичное для технологии ограничение на элементы в модели сборки. Например, описывает использование инфраструктуры публичных ключей для реализации шифрования.
В Oracle SOA Suite политики можно добавлять к компонентам как во время разработки с помощью JDeveloper, так и во время работы с помощью Enterprise Manager'а.
С технической точки зрения SCA описывает несколько другую плоскость, нежели ESB и JBI (JSR 208 - Java Business Integration). Если ESB концентрируется на интеграции отдельных сервисов и существующих приложений, а также на использовании инфраструктурных сервисов трансформации и маршрутизации данных, то SCA предназначен для реализации внутренней архитектуры приложений.
Попросту говоря, сервисная шина предприятия - это концепция промежуточного ПО, а сервисные компоненты - это концепция разработки бизнес-приложений.
Подробнее про то, как сделать правильный выбор между SCA и ESB, можно прочитать в статье Интеграция: Oracle Service Bus vs Oracle SOA Suite.
Ситуация с реализацией SCA напоминает ситуацию со спецификацией EJB во времена EJB 2 и более ранние: спецификация есть, есть описание того, как ее нужно реализовывать, есть набор пространств имен, аннотаций, других артефактов, но каждый производитель программного обеспечения все равно реализует спецификацию по-своему, вносит свои пространства имен, конфигурационные файлы и т.д. В итоге композит, разработанный для одной реализации SCA, может не работать под другой реализацией.
Реализации SCA:
Понравилось сообщение - подпишитесь на блог и Twitter
По-сути, SCA обеспечивает программную модель для реализации SOA.
Спецификация состоит из двух основных частей, описывающих методы
- Реализации компонентов, предоставляющих одни и использующих другие сервисы.
- Объединения множества компонентов для построения бизнес-приложений путем связывания сервисов и сервисных ссылок (service references).
Разработчиком спецификации является консорциум Open SOA Collaboration (www.osoa.org). Текущая версия спецификации - 1.0 от 21 марта 2007 г. Некоторые части спецификации приняты позднее, например SCA Assembly Extensions for Event Processing and Pub/Sub V1.00 - 30 апреля 2009 г. Существует черновик версии 1.1, выпущенный 31 мая 2011. Несмотря на то, что это - черновик, он уже поддерживается Oracle.
SCA подчеркивает независимость способа реализации и объединения сервисов от возможностей инфраструктуры и используемых методов доступа. Компоненты SCA обслуживают бизнес-уровень и используют минимум API промежуточного слоя.
Что такое SCA
Данная спецификация поддерживает реализации сервисов, написанные с использованием различных языков программирования, включая объектно-ориентированные и процедурные языки, такие как Java, PHP, C, C++, COBOL, языки-подмножества XML, такие как BPEL и XSLT, а так же языки декларативного программирования, такие как SQL и XQuery. SCA так же поддерживает различные стили программирования, включая асинхронное, ориентированное на обработку сообщений и стиль "запрос-ответ".
Так же спецификация поддерживает большое количество методов доступа к сервисам: веб-сервисы, системы обмена сообщениями, CORBA IIOP и т.д. Связывание сервисов друг с другом осуществляется декларативно и не зависит от кода реализации самих сервисов. Инфраструктурные возможности, такие как обеспечение безопасности, транзакции и использование гарантированной доставки, так же подключаются декларативно и отдельно от кода реализации сервисов. Использование инфраструктурных возможностей осуществляется посредством механизма политик.
Одной из целей разработки SCA является упрощение создания сервисных компонентов: программист может сконцентрироваться на задачах бизнес-логики, и не обращать внимание на инфраструктурные вопросы. Спецификация так же предлагает прозрачную модель объединения сервисных компонентов в бизнес-решения с обеспечением декларативной информацией, определяющей связи сервисов, ссылок и используемых протоколов.
Для представления бизнес-данных используются сервисные объекты данных - Service Data Objects (SDO), которые формируют параметры вызова и возвращаемые сервисами значения, а так же обеспечивают унифицированный доступ к бизнес-данным в дополнение к унифицированному доступу к бизнес-сервисам, реализованному SCA самостоятельно. Т.е. SCA предоставляет унифицированный доступ к бизнес-сервисам, а SDO в добавок к этому - унифицированный доступ к бизнес-данным.
Введение такого унифицированного метода доступа к данным позволяет освободить разработчика от необходимости понимания множества различных форматов данных и программных интерфейсов, которые необходимы для их обработки (например, JDBC для реляционных данных, JAX-P для XML и т.д.) Так же SDO поддерживает разъединенный, оптимистически-обновляемый стиль программирования, где данные считываются из некоторого источника, обновляются клиентским приложением и передаются обратно в оригинальное месторасположение без необходимости блокирования исходных данных на время их обработки.
Основные понятия SCA
Ниже приведен словарь, включающий в себя основные понятия спецификации SCA.
Сервис представляет интерфейс, реализуемый компонентом либо целой SCA-сборкой - композитом. Данный интерфейс может использоваться клиентом композита либо компонентом. Сервис, реализованный извне композита, называется внешним сервисом.
Компонент представляет часть бизнес-логики. Это может быть логика процесса, такого как BPEL- или BPMN-процесс, логика маршрутизации, такая как Mediator или другие компоненты. Компонент - ядро SCA и может быть реализован на любом языке, поддерживаемом данной спецификацией. Будучи однажды определенным, компонент может декларативно конфигурироваться с помощью механизма свойств.
Ссылка - это зависимость от сервиса, предоставляемого другим компонентом, другой SCA-сборкой или внешней сущностью, такой как удаленный веб-сервис. Ссылка на сервис, реализованный вне композита, называется внешней ссылкой. Ссылки позволяют компоненту взаимодействовать с другими сервисами. Ссылки разрешаются во время загрузки или во время исполнения.
Модель сборки описывает как сервисы определяются и настраиваются.
Связь. Сервисы и ссылки объединяются вместе с помощью связей. Связь обозначает зависимость между компонентами или между компонентом и внешней сущностью.
Соединение (wiring). Компоненты объединяются с помощью связей, которые указывают каждому компоненту, какие у него есть источники информации и какие приемники. Соединения описываются декларативно. SCA не требует, чтобы источник и приемник имели одинаковые типы (например, допускается соединение Java и WSDL). Для упрощения разработки SCA поддерживает автоматические соединения (Autowiring). Пока информация о ссылках однозначна,
контейнер имеет возможность соединять компоненты во время исполнения.
Связывание (binding). Модель SCA осуществляет коммуникацию между сервисами и ссылками с помощью механизма связывания, поддерживающего множество
технологий. Все совместимые со спецификацией SCA реализации должны поддерживать SCA Service Binding и WebService Binding. Связывания используются сервисами и ссылками. Сервисы используют связывания для определения того, как они могут вызываться. Ссылки используют связывания для определения того, как они могут вызывать сервисы.
Композит. Компоненты группируются в композиты. В зависимости от описания, композит может использоваться как сервис либо как новый компонент. Таким образом SCA поддерживает рекурсивную сборку.
Quality of Service (QoS) и механизм политик
Для реализации QoS и нефункциональных требований модель SCA предлагает механизм политик (Policy Framework). Политики могут использоваться для обеспечения безопасности, доступности, транзакционности и реализации других требований.
Политики могут быть ассоциированы с каждым компонентом. Сервисы и ссылки могут иметь множественные политики для обеспечения различных способов доступа. Основные элементы механизма политик это Намерения (Intents), Профили (Profiles) и Множества политик (Policy Sets).
Намерение - это абстрактное утверждение об ограничении QoS для реализации компонента. Например, сообщение может быть конфиденциальным, соответственно определяется намерение с названием confidentiality.
Профайл - это набор наименований намерений. Намерения, на которые ссылается Профайл, отображаются на конкретные реализации во множестве политик.
Множество политик соответствует реализации Намерений. Определяет специфичное для технологии ограничение на элементы в модели сборки. Например, описывает использование инфраструктуры публичных ключей для реализации шифрования.
В Oracle SOA Suite политики можно добавлять к компонентам как во время разработки с помощью JDeveloper, так и во время работы с помощью Enterprise Manager'а.
Отличие SCA от ESB
С технической точки зрения SCA описывает несколько другую плоскость, нежели ESB и JBI (JSR 208 - Java Business Integration). Если ESB концентрируется на интеграции отдельных сервисов и существующих приложений, а также на использовании инфраструктурных сервисов трансформации и маршрутизации данных, то SCA предназначен для реализации внутренней архитектуры приложений.
Попросту говоря, сервисная шина предприятия - это концепция промежуточного ПО, а сервисные компоненты - это концепция разработки бизнес-приложений.
Подробнее про то, как сделать правильный выбор между SCA и ESB, можно прочитать в статье Интеграция: Oracle Service Bus vs Oracle SOA Suite.
Реализации SCA
Ситуация с реализацией SCA напоминает ситуацию со спецификацией EJB во времена EJB 2 и более ранние: спецификация есть, есть описание того, как ее нужно реализовывать, есть набор пространств имен, аннотаций, других артефактов, но каждый производитель программного обеспечения все равно реализует спецификацию по-своему, вносит свои пространства имен, конфигурационные файлы и т.д. В итоге композит, разработанный для одной реализации SCA, может не работать под другой реализацией.
Реализации SCA:
- Oracle SOA Suite, Oracle BPM Suite;
- JDeveloper - дизайнер для Oracle SOA Suite;
- IBM WebSphere Application Server V7.0 Feature Pack for SCA;
- IBM Rational Application Developer for WebSphere - дизайнер для IBM WebSphere AS Feature Pack for SCA;
- Apache Tuscany;
- Eclipse SOA Tools Platform Project (STP) - дизайнер с открытым исходным кодом;
- Infiniflow Distributed Service Framework (DSF) from Paremus;
- Service Component Architecture (SCA) Framework for SOA from Covansys;
- ActiveMatrix Service Grid from TIBCO;
- SCA Component for Ruby with IBM WebSphere Process Server;
- Fabric3;
- FraSCAti;
- The Newton Project;
- The Mule Project (MuleSCA);
- Eclipse Persistence Services Project (EclipseLink) - реализация SDO.
Материалы
- David Chappell Introducing SCA;
- Arunava Chatterjee Service-Component Architectures;
- Composite Software Construction.
Понравилось сообщение - подпишитесь на блог и Twitter
2 комментария:
Спасибо за вводную статью!)
Интересен опыт работы с SCA. Насколько удобно? В чем разрабатывает? Какие подводные камни?
Здравствуйте, разрабатываю композиты уже два года. Использую Oracle SOA Suite и, соответственно, JDeveloper. Очень удобно. Из подводных камней назову производительность, разрабатываемую систему нужно очень тонко тюнить.
Отправить комментарий
Любой Ваш комментарий важен для меня, однако, помните, что действует предмодерация. Давайте уважать друг друга!