Принцип компонуемости сервисов

В вычислительной технике компонуемость сервисов — это принцип проектирования, применяемый в рамках парадигмы сервисно-ориентированного проектирования , который поощряет проектирование сервисов , которые можно повторно использовать в нескольких решениях, которые сами состоят из составных сервисов. Возможность перекомпоновки сервиса в идеале не зависит от размера и сложности состава сервиса.

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

Цель

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

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

Приложение

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

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

Соображения

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

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

Некоторые из факторов, определяющих потенциал компонуемости сервиса, включают в себя:

• Способность обеспечивать функциональность на разных уровнях бизнес-процесса.
• Шаблон обмена сообщениями
• Поддерживает ли сервис транзакции и функции отката/компенсации.
• Поддержка обработки исключений.
• Доступность метаданных о возможностях и поведении службы.

См. также

• Исполняемая хореография
• Служебная хореография

Ссылки

• Кьель-Сверре Ериярви. Модель срока действия контракта SOA [онлайн]. Дата обращения: 21 апреля 2010 г.
• Мауро. и др. Сервис-ориентированная интеграция устройств: анализ шаблонов проектирования SOA. [Онлайн], стр. 1–10, 2010 г., 43-я Гавайская международная конференция по системным наукам, 2010 г. Дата доступа: 8 апреля 2010 г.
• Дино Эспозито. Шаблон сообщения HTML [Онлайн]. Дата обращения: 21 апреля 2010 г.
• Принципы сервисной ориентации
• Энн Томас Манес. Манифест SOA [онлайн]. Дата обращения: 21 апреля 2010 г.
• Подвал Войцеха, Сергиуш Стрыковский. Электронное правительство на основе облачных вычислений и сервис-ориентированной архитектуры [Онлайн]. Дата доступа: 22 апреля 2010 г.
• Сунь Л., Донг Х., Хуссейн Ф.К., Хусейн О.К., Чанг Э.: Выбор облачных сервисов: современные и будущие направления исследований. Журнал сетевых и компьютерных приложений [онлайн] 45 (октябрь 2014 г.), стр. 134–150. Дата обращения: 16 июня 2015 г.