Архитектура компонентов служб

редактировать

Архитектура компонентов служб (SCA ) - это программная технология, разработанная для предоставления модели для приложений которые следуют принципам сервис-ориентированной архитектуры. Технология, созданная основными поставщиками программного обеспечения, включая IBM, Oracle Corporation и TIBCO Software, охватывает широкий спектр технологий и, как таковая, указана в независимых спецификациях. для сохранения нейтральности языка программирования и среды приложений. Часто он использует служебную шину предприятия (ESB).

Содержание
  • 1 История
  • 2 Определение
  • 3 Артефакты
  • 4 Переход к стандарту
  • 5 См. Также
  • 6 Ссылки
  • 7 Дополнительная литература
  • 8 Внешние ссылки
История

Первыми партнерами, объявленными 30 ноября 2005 г., были: BEA Systems, IBM, IONA Technologies, Oracle Corporation, SAP AG, Sybase, Xcalia и Zend Technologies. 26 июля 2006 г. были объявлены дополнительные члены: Cape Clear, Interface21, Progress Software, Red Hat, Rogue Wave Software., Software AG, Sun Microsystems и TIBCO Software. Siemens AG присоединились к сотрудничеству компаний, работающих над этой технологией в сентябре 18, 2006.

Помимо партнеров, у сообщества SCA было несколько официальных сторонников.

Определение

21 марта 2007 года OSOA Collaboration выпустила первую версию спецификации. В спецификациях сказано, что приложение, разработанное с использованием SCA, должно иметь:

  • отделение бизнес-логики приложения от деталей вызываемых им вызовов служб
  • Целевые службы на множестве языков, включая C ++, Java, COBOL и PHP, а также XML, BPEL и XSLT
  • Возможность работы с различными коммуникационными конструкциями, включая одностороннюю, асинхронную, обратный вызов и уведомление
  • Возможность «привязки» к устаревшим компонентам или службам, к которым обычно получают доступ такие технологии, как Интернет Службы, EJB, JMS, JCA, RMI, RPC, CORBA и другие
  • Возможность декларировать (вне бизнес-логики) требования к качеству обслуживания, такие как безопасность, транзакции и использование надежных сообщений
  • данных может быть представлен в объектах служебных данных

SCA, поэтому был продвинут, чтобы предложить гибкость для составных приложений, гибкое включение повторно используемых компонентов в стиль программирования SOA.

Маркетинговая фирма Gartner Group в декабре 2005 года опубликовала краткое описание SCA и включенной в него технологии Service Data Objects (SDO).

Преимущества:

Недостатки:

  • Спецификация не затрагивает производительность приложений SOA, что по-прежнему препятствует их принятию.
  • Сосредоточение внимания на переносимости (а не на совместимости), что делает его уязвимым для повторения ошибок CORBA.

SCA, как утверждается, обеспечивает совместимость посредством подхода, называемого «Активация». Это метод, который обеспечивает наивысшую степень автономности компонентов по сравнению со старым методом «посредничества» (например, JBI ) или методом «вызова», используемым в JCA, как объяснил архитектор. в SAP.

Артефакты

Модель сборки SCA состоит из серии артефактов, которые определяются элементами, содержащимися в файлах XML. Среда выполнения SCA может иметь другие нестандартные представления артефактов, представленных этими XML-файлами, и может позволять динамически изменять конфигурацию систем. Однако файлы XML определяют переносимое представление артефактов SCA.

Основным артефактом является составной, который является единицей развертывания для SCA и содержит сервисы, к которым можно получить удаленный доступ. Составной элемент содержит один или несколько компонентов, которые содержат бизнес-функцию, предоставляемую модулем. Компоненты предлагают свои функции как службы, которые могут использоваться другими компонентами в том же модуле или которые могут быть доступны для использования вне модуля через точки входа . Компоненты могут также зависеть от служб, предоставляемых другими компонентами - эти зависимости называются ссылками . Ссылки могут быть связаны с услугами, предоставляемыми другими компонентами в том же модуле, или ссылки могут быть связаны с услугами, предоставляемыми вне модуля, которые могут предоставляться другими модулями. Ссылки на услуги, предоставляемые вне модуля, включая услуги, предоставляемые другими модулями, определяются внешними службами в модуле. В модуле также содержатся связи между ссылками и службами, представленные связями .

. Компонент состоит из сконфигурированной реализации, где реализация - это часть программного кода, реализующего бизнес-функции. Компонент настраивает реализацию с определенными значениями для устанавливаемых свойств, объявленных реализацией. Компонент также может настроить реализацию с привязкой ссылок, объявленных реализацией, к конкретным целевым службам.

Композиты развернуты в системе SCA . Система SCA представляет собой набор сервисов, обеспечивающих область бизнес-функций, которая контролируется одной организацией. Например, для бухгалтерии предприятия система SCA может охватывать все функции, связанные с финансами, и может содержать серию модулей, относящихся к конкретным областям бухгалтерского учета, причем один для счетов клиентов, а другой - для кредиторской задолженности. Чтобы помочь построить и настроить систему SCA, композиты могут использоваться как реализации компонентов, так же, как классы Java или процессы BPEL. Другими словами, SCA допускает произвольно глубокую иерархию композитов - такая вложенная модель называется рекурсивной.

Захват и выражение нефункциональных требований, таких как безопасность, является важным аспектом определения сервиса и влияет на SCA на протяжении всего жизненного цикла компонентов и составов. SCA предоставляет Policy Framework для поддержки спецификации ограничений, возможностей и ожидаемого качества обслуживания (QoS), от проектирования компонентов до конкретного развертывания.

Переход к органу по стандартизации

После нескольких лет инкубации в условиях неформального отраслевого сотрудничества, ранние (V1.0) реализации спецификации теперь выходят на рынок. Партнеры по сотрудничеству указали, что формальная отраслевая стандартизация будет подходящим следующим шагом, и объявили о своих намерениях в марте 2007 г. Выбранная организация по разработке стандартов - организация OASIS и новая OASIS Открыт CSA Членская секция создана. Уставы шести новых технических комитетов (ТК) были представлены в OASIS, а внутри организации OASIS был выпущен призыв к участию членов технического комитета. Технические комитеты планировали начать свою работу в сентябре 2007 года. Участие в этих TC OASIS SCA остается открытым для всех компаний, некоммерческих групп, правительств, академических институтов и отдельных лиц. Архивы работы будут доступны как для членов, так и для не членов, и OASIS предложит механизм общественного обсуждения.

См. Также
Ссылки
Дополнительная литература
  • Понимание SCA от экспертов Джима Марино и Майкла Роули [2 ]
  • SOA для бизнес-разработчиков: концепции, BPEL и SCA - ISBN 978-158347-065-7
  • Apache Tuscany в действии, ISBN 978-1-933988-89-4
  • SOA с открытым исходным кодом, ISBN 1-933988-54-1
Внешние ссылки
Последняя правка сделана 2021-06-08 01:23:52
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте