Принцип повторного использования сервиса
Тон или стиль этой статьи могут не отражать энциклопедический тон , используемый в Википедии . ( февраль 2010 г. ) |
Принцип повторного использования сервисов — это принцип проектирования , применяемый в рамках парадигмы сервисно-ориентированного проектирования для создания сервисов. [1] которые можно повторно использовать в бизнесе. [2] Эти повторно используемые сервисы спроектированы таким образом, что логика их решения не зависит от какого-либо конкретного бизнес-процесса или технологии.
Цель
[ редактировать ]Возможность повторного использования службы обычно измеряется тем, сколько дополнительных функций содержит служба, которые можно повторно использовать в будущем, и насколько функциональность службы выходит за рамки текущих требований. Это поощряет сервисы, которые содержат дополнительные возможности, основанные на возможных будущих сценариях использования сервисов. Однако мало что делается для разработки логики сервиса таким образом, чтобы ее можно было повторно использовать для автоматизации множества бизнес-процессов. Это приводит к тому, что больше внимания уделяется оснащению сервисов дополнительной функциональностью, чем концентрации на возможности повторного использования основной логики сервиса, что приводит к созданию «позолоченных» сервисов, разработка которых требует больше времени и усилий. Эта дополнительная функциональность может даже не входить в исходный функциональный контекст. [примечание 1] сервиса и может вообще не использоваться, так как был создан без установления его потребностей. Полученная в результате SOA не сможет обеспечить реальную возможность повторного использования сервисов, как было обещано.
Еще одно заблуждение относительно повторного использования сервиса заключается в том, что повторное использование связано с частотой его использования. В отличие от этого, фактическое повторное использование относится к случаям, когда сервис используется для автоматизации нескольких бизнес-процессов. Это настоящее повторное использование сервиса, поскольку такой сервис устраняет необходимость создания нового сервиса и становится частью множества бизнес-процессов, не будучи частью какого-либо конкретного бизнес-процесса.
Принцип повторного использования сервисов устраняет эти заблуждения, предоставляя набор рекомендаций, которые помогают разрабатывать сервисы, содержащие логику, которая не связана с каким-либо конкретным бизнес-процессом и, следовательно, может быть повторно использована на предприятии для автоматизации нескольких бизнес-процессов. Это еще больше помогает в достижении повышенной рентабельности инвестиций. [3]
Комплексное применение принципов повторного использования сервисов, абстракции сервисов и слабой связи сервисов помогает разрабатывать компонуемые сервисы. [4]
Приложение
[ редактировать ]Этот принцип проектирования предполагает разработку услуг на основе принципов проектирования коммерческих продуктов, которые диктуют разработку программного продукта с правильным типом и правильным количеством логики. Таким образом, основное внимание здесь уделяется качеству логики , встроенной в программу. Концентрируясь на качестве, автоматически увеличивается потенциал повторного использования программного обеспечения. Чтобы сконцентрироваться на качестве логики, возможность повторного использования сервиса требует изучения бизнес-сферы, а также используемых в настоящее время технологий. Некоторые соображения, которые помогают при разработке сервисов с многократно используемой логикой, включают:
- Каковы долгосрочные цели организации?
- Анализ функционального контекста текущих сервисов.
- Текущие устаревшие системы и любые будущие планы вывода из эксплуатации таких устаревших систем.
- Каковы текущие требования, которым должна отвечать услуга?
- Подробная информация о соответствующем домене(ах) бизнеса.
Проведя этот анализ, мы можем прийти к правильному типу многократно используемой логики, которую необходимо включить в сервис. Кроме того, поскольку другие службы также анализируются, вероятность дублирования логики сведена к минимуму. Для применения этого принципа полезно иметь план инвентаризации услуг. [5] (набор услуг-кандидатов), поскольку тогда идентификация независимой логики [примечание 2] становится гораздо проще. Это требует выполнения [6] посредством сервис-ориентированного анализа и процесса проектирования. Применение этого принципа до окончательной доработки возможностей сервиса дает возможность точной настройки и рефакторинга логики для обеспечения возможности ее повторного использования. Это также дает возможность оснастить сервисы дополнительными возможностями, которые могут быть повторно использованы другими бизнес-процессами, помимо того, который сейчас автоматизируется, когда речь идет об автоматизации таких процессов.
Важной концепцией, связанной с применением этого принципа, является централизация логики. С течением времени, когда реализуются различные проекты предоставления услуг, вероятность появления услуг, содержащих дублирующую логику, увеличивается. Этого можно избежать только в том случае, если существует общекорпоративный стандарт, который предписывает анализировать текущие сервисы, когда дело доходит до добавления к ним новой повторно используемой логики. Если сервис уже существует с функциональным контекстом, который соответствует новой логике многократного использования, то вместо создания нового сервиса такая логика должна стать частью существующего сервиса. Это не только помогает избежать дублирования, но и повышает уровень возможности повторного использования сервиса, поскольку теперь повторно используемая логика находится в правильном контексте и, следовательно, имеет больше шансов на повторное использование. Это именно то, что отстаивает модель логической централизации .
Соображения
[ редактировать ]Применение этого принципа проектирования требует выполнения нисходящего процесса сервис-ориентированного анализа. [7] для того, чтобы получить полный набор потенциальных услуг. Это явно требует увеличения ресурсов как в виде времени, так и усилий. Применение шаблона проектирования «Централизация логики» может привести к возникновению культурных проблем, например, разработчики сервисов проявляют нежелание повторно использовать чужие сервисы, менеджеры проектов не желают включать использование существующих сервисов, поскольку может потребоваться адаптация конструкции решения и т. д.
При акцентировании внимания на повторном использовании услуг надежность повторно используемых сервисов становится важной проблемой, поскольку от одного и того же сервиса зависят несколько потребителей услуг. Другие принципы проектирования, такие как принцип автономии службы и принцип безгражданства службы, служат руководством для решения проблем, связанных с надежностью и доступностью.
Примечания
[ редактировать ]- ^ Тип функциональности, которую включает в себя служба, например, служба выставления счетов будет иметь функциональный контекст, который занимается обработкой счетов, но не занимается обработкой заказов на поставку.
- ^ Логика, которая не связана с одним бизнес-процессом, т.е. независима от какого-либо конкретного контекста и, следовательно, может использоваться для автоматизации нескольких бизнес-процессов.
Ссылки
[ редактировать ]- ^ Услуги
- ^ Томас Эрл , Хербьёрн Вильгельмсен Модель недели SOA (№ 4): Нормализация сервиса [Онлайн]. Дата обращения: 14 апреля 2010 г.
- ^ Харихаран. Распространенная ошибка при внедрении SOA [Online]. Дата обращения: 14 апреля 2010 г.
- ^ Кьель-Сверре Ериярви. Модель зрелости контракта SOA [онлайн]. Дата обращения: 14 апреля 2010 г.
- ^ Схема инвентаризации сервисов , заархивированная 11 мая 2010 г. в Wayback Machine.
- ^ Моделирование услуг
- ^ Процесс сервис-ориентированного анализа сверху вниз. Архивировано 9 мая 2010 г. на Wayback Machine.
Дальнейшее чтение
[ редактировать ]- Мауро. и др. Сервис-ориентированная интеграция устройств: анализ шаблонов проектирования SOA. [онлайн], стр. 1–10, 2010 г., 43-я Гавайская международная конференция по системным наукам, 2010 г. Дата обращения: 8 апреля 2010 г.
- Деннис Висноски. Принципы и закономерности Министерства обороны США [онлайн]. Дата обращения: 14 апреля 2010 г.