WikiDer > Принцип повторного использования сервиса - Википедия

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

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

Цель

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

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

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

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

Заявление

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

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

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

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

Соображения

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

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

Примечания

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

дальнейшее чтение

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