Принцип повторного использования услуг

Тон или стиль этой статьи может не отражать энциклопедический тон , используемый в Википедии . См. руководство Википедии по написанию лучших статей для предложений. ( Февраль 2010 ) ( Узнайте, как и когда удалять это сообщение )

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

Возможность повторного использования сервиса обычно измеряется тем, сколько дополнительных функций содержит сервис, которые могут быть повторно использованы в будущем, и насколько функционал сервиса выходит за рамки текущих требований. Это поощряет сервисы, которые содержат дополнительные возможности, построенные вокруг возможных будущих сценариев использования сервиса. Однако мало что делается для проектирования логики сервиса таким образом, чтобы ее можно было повторно использовать для автоматизации нескольких бизнес-процессов. Это приводит к большему вниманию к оснащению сервисов дополнительной функциональностью, чем к концентрации на том, чтобы сделать основную логику сервиса повторно используемой, что приводит к золотым сервисам, разработка которых требует большего времени и усилий. Эта дополнительная функциональность может даже не попадать в исходный функциональный контекст ^{[примечание 1]} сервиса и может даже не использоваться вообще, поскольку она была создана без определения ее потребностей. Полученная SOA не сможет обеспечить настоящую возможность повторного использования сервиса, как было обещано.

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

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

Комплексное применение принципов повторного использования сервисов, абстракции сервисов и слабой связанности сервисов помогает разрабатывать компонуемые сервисы. ^[4]

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

• Каковы долгосрочные цели организации?
• Анализ функциональных контекстов текущих услуг.
• Текущие устаревшие системы и любые будущие планы по выводу из эксплуатации таких устаревших систем.
• Каким текущим требованиям должна соответствовать услуга?
• Подробная информация о соответствующем бизнес-домене(ах).

Проводя этот анализ, мы можем прийти к правильному типу повторно используемой логики, которую необходимо включить в сервис. Кроме того, поскольку другие сервисы также анализируются, вероятность дублирования логики сводится к минимуму. Для применения этого принципа полезно иметь план инвентаризации сервисов ^[5] (набор потенциальных сервисов), поскольку тогда идентификация независимой логики ^{[примечание 2]} становится гораздо проще. Для этого требуется выполнение ^[6] с помощью процесса сервисно-ориентированного анализа и проектирования . Применение этого принципа до завершения возможностей сервиса дает возможность для тонкой настройки и рефакторинга логики в поддержку ее повторного использования. Это также дает шанс оснастить сервисы дополнительными возможностями, которые могут быть повторно использованы другими бизнес-процессами, помимо того, который в настоящее время автоматизируется, когда речь идет об автоматизации таких процессов.

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

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

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

• Mauro. et al. Сервисно-ориентированная интеграция устройств — анализ шаблонов проектирования SOA. [онлайн], стр. 1–10, 2010 г. 43-я Гавайская международная конференция по системным наукам, 2010 г. Дата обращения: 8 апреля 2010 г.
• Деннис Висноски. Принципы и модели Министерства обороны США [Онлайн]. Дата обращения: 14 апреля 2010 г.