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

Service composability principle

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

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

Цель

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

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

Заявление

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

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

Соображения

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

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

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

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

Рекомендации

  1. ^ «Сервисный состав». Архивировано из оригинал на 2010-03-11. Получено 2010-03-04.
  2. ^ а б Майкл Пулен.Эволюция принципов сервисной ориентации: безгражданство сервиса, часть 7[Online]. Дата обращения: 21 апреля 2010 г.
  3. ^ "Контракт на обслуживание". Архивировано из оригинал на 2012-05-01. Получено 2010-03-04.
  4. ^ Красные книги IBM Power Systems и SOA Synergy[Online]. Дата обращения: 21 апреля 2010 г.
  5. ^ типы муфт
  6. ^ "Шаблоны SOA". Шаблоны SOA.
  7. ^ Редди. и другие.Оценка устаревших активов в контексте перехода на SOA[Online] .pp 58. Дата обращения: 21 апреля 2010 г.