Абстракция сервиса

Абстракция сервиса — это принцип проектирования, который применяется в рамках ориентированного на сервис, парадигмы проектирования, так что информация, публикуемая в контракте на обслуживание, ограничивается тем, что требуется для эффективного использования сервиса. Контракт службы не должен содержать никакой лишней информации, которая не требуется для его вызова. Кроме того, поскольку информация должна быть ограничена только контрактом на обслуживание (техническим контрактом и соглашением об уровне обслуживания ), никакой другой документ или носитель потребителям услуг не должен быть доступен , кроме контракта на обслуживание, который содержит дополнительную информацию, связанную с обслуживанием.

Цель

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

Сокрытие информации остается одним из ключевых принципов объектно-ориентированной парадигмы, которая способствует абстрагированию внутренней работы программы . Классическим примером может быть использование абстрактных классов для сокрытия фактической логики метода. Та же концепция применяется в принципе абстракции сервиса, чтобы скрыть ненужные подробности о работе сервиса и облегчить его развитие.

Приложение

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

Функциональная абстракция

Эта форма абстракции зависит от того, какая часть логики сервиса представлена ​​как возможности сервиса. Примером может служить класс, в котором некоторые из его методов являются частными, а другие — общедоступными. Класс будет предоставлять общедоступными только те методы, которые он считает важными для своих объектов; любые вспомогательные методы, не относящиеся к объектам, остаются скрытыми.

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

Технологическая информационная абстракция

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

Логическая абстракция

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

Качественная абстракция

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

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

Соображения

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

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

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

• Мауро. и др. Сервис-ориентированная интеграция устройств: анализ шаблонов проектирования SOA. [онлайн], стр. 1–10, 2010 г., 43-я Гавайская международная конференция по системным наукам, 2010 г. Дата обращения: 8 апреля 2010 г.
• Томас Эрл . Сервис-ориентация и объектная ориентация. Часть II: Сравнение принципов проектирования [Онлайн]. Дата обращения: 13 апреля 2010 г.
• Тост. и др. Рекомендации по использованию технологий контрактов веб-сервисов [онлайн]. Дата обращения: 13 апреля 2010 г.
• Пекка Алхо. Применение новых технологий разработки программного обеспечения для автоматизации и технологий интеграции в обучении [онлайн]. Дата обращения: 13 апреля 2010 г.

Внешние ссылки

• Концепции SOA
• Глоссарий терминов SOA