WikiDer > Рефакторинг сервиса

Service refactoring

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

Обоснование

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

С этой ситуацией необходимо справиться таким образом, чтобы сервис обновлялся, не затрагивая потребителей, которые уже сформировали зависимости от сервиса. Хотя можно утверждать, что реагирование на любое из вышеупомянутых требований не должно быть проблематичным, пока служба соблюдает свой контракт, однако здесь нас беспокоит не только правильность результата, связанного с выполнением возможностей службы.[3] но также с поведением и надежностью службы. Для решения этих проблем шаблон проектирования «Рефакторинг службы» предоставляет стратегию, направленную на обеспечение возможности развития службы без негативного воздействия на ее потребителей.[4]

использование

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

С другой стороны, чтобы изолировать логику сервиса от негативных последствий изменений в реализации сервиса, можно повторно применить шаблон проектирования Service Façade, чтобы ввести еще один фасадный компонент между реализацией сервиса и логикой сервиса. Применение Абстракция службы Принцип может в дальнейшем помочь уменьшить вероятность любых вредных эффектов, вызванных применением этого шаблона проектирования.[9]

Соображения

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

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

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

  1. ^ служба
  2. ^ Джейсон Блумберг.Четыре столпа сервис-ориентированного развития[В сети]. Дата обращения: 27 апреля 2010 г.
  3. ^ Возможности сервиса
  4. ^ Томас Эрл.Знакомство с шаблонами проектирования SOA[В сети]. Дата обращения: 5 апреля 2010 г.
  5. ^ Ваджид Хаттак.Рефакторинг сервиса[В сети]. Дата обращения: 27 апреля 2010 г.
  6. ^ Шаблон проектирования служебного фасада
  7. ^ Разъединенный шаблон проектирования контракта
  8. ^ Шаблон проектирования централизации контрактов
  9. ^ Деннис Висноски.Принципы и модели в Министерстве обороны США[В сети]. Дата обращения: 28 апреля 2010 г.
  10. ^ Шаблон проектирования параллельных контрактов

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

  • Эрл и др., (2009).Шаблоны проектирования SOA. Прентис Холл. ISBN 0-13-613516-1.
  • Мауро. и другие. Сервисно-ориентированная интеграция устройств - анализ шаблонов проектирования SOA. [Online], pp. 1–10, 2010 43-я Гавайская международная конференция по системным наукам, 2010 г. Дата обращения: 5 апреля 2010 г.

внешняя ссылка