Принцип работы без муфты - Service loose coupling principle

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

Цель

Концепция чего-либо Слабая связь в SOA находится под непосредственным влиянием парадигмы объектно-ориентированного проектирования,[4] при этом цель состоит в том, чтобы уменьшить взаимосвязь между классами, чтобы создать среду, в которой оба класса, хотя и связаны друг с другом, могут быть изменены таким образом, чтобы такое изменение не нарушало существующие отношения, которые необходимы для работы. программного обеспечения. Та же концепция применяется и в мире SOA, однако в рамках SOA особое внимание уделяется контракту службы, поскольку контракт службы действует как интерфейс, через который потребители службы взаимодействуют с логикой службы и наоборот. Помимо этого, SOA настоятельно поддерживает разработку физически независимых сервисных контрактов от сервисной логики (несвязанный контракт[5] паттерн проектирования) в пользу взаимодействия и технологической независимости. Поскольку контракты физически независимы, необходимо не только изучить связь между потребителями сервисов и контрактами сервисов, но и между контрактами сервисов и их базовой логикой и реализацией. Именно здесь применение этого принципа проектирования помогает идентифицировать различные типы существующих связей (между услугами и внутри службы) и то, как разрабатывать контракты, чтобы минимизировать типы отрицательных связей и максимизировать типы положительных связей. Сервисно-ориентированное решение, состоящее из сервисов со слабосвязанными контрактами, напрямую поддерживает расширенные возможности разнообразия поставщиков и повышенную совместимость. цели сервисной ориентации.

Заявление

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

Типы муфт

Логика-контракт

Слабое связывание сервисов диктует, что следует отдавать предпочтение этому типу связывания, чтобы логика сервиса разрабатывалась исключительно для поддержки контракта сервиса. Однако для этого необходимо следовать подходу «сначала контракт», как предлагается стандартный договор на обслуживание принцип, так что логика обслуживания связана со стандартизированным контрактом. Таким образом, контракт службы не связан с логикой, поэтому логика может быть заменена в будущем, если это необходимо, без воздействия на потребителей службы.

Контракт-логика

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

От контракта до реализации

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

Контракт-технология

Контракт, который раскрывает элементы запатентованной технологии, используемые логикой службы, например контракт, основанный на технологии .NET Remoting, формирует отрицательную форму связи, поскольку потребители услуг ограничены этой конкретной технологией. Это значительно снижает способность сервиса считаться совместимым корпоративным ресурсом.

От контракта к функциональному

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

Потребитель - реализация

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

Потребитель-контракт

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

Соображения

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

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

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

  1. ^ Принцип дизайна
  2. ^ Услуги
  3. ^ Майкл Пулен.Эволюция принципов сервисной ориентации: свободное связывание и абстракция сервисов, часть 3 [Online]. Дата обращения: 12 апреля 2010 г.
  4. ^ Бернхард Борхес, Керри Холли, Али Арсанджани Углубляемся в сервис-ориентированную архитектуру [Online]. Дата обращения: 12 апреля 2010 г.
  5. ^ Разъединенный шаблон контракта
  6. ^ Tost. и другие.Рекомендации по использованию контрактных технологий веб-служб [Online]. Дата обращения: 12 апреля 2010 г.
  7. ^ Шаблон служебного фасада
  8. ^ Схема централизации контрактов
  • Томас Эрл (2008).Принципы проектирования сервисов SOA. Прентис Холл. ISBN  0-13-234482-3.
  • Мауро. и другие. Сервисно-ориентированная интеграция устройств - анализ шаблонов проектирования SOA. [онлайн], стр. 1–10, 2010 г. 43-я Гавайская международная конференция по системным наукам, 2010 г. Дата обращения: 8 апреля 2010 г.
  • Kjell-Sverre Jerijærvi.Модель зрелости контракта SOA [Online]. Дата обращения: 12 апреля 2010 г.
  • Погреб Войцеха, Сергиуш Стрыковский.Электронное правительство на основе облачных вычислений и сервис-ориентированной архитектуры [Online]. Дата обращения: 12 апреля 2010 г.

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