Абстракция сервиса - это принцип проектирования, который применяется в парадигме сервис-ориентированного дизайна, так что информация, опубликованная в сервисном контракте, ограничивается тем, что требуется для эффективного использования сервиса. [1] Сервисный контракт не должен содержать никакой лишней информации, которая не требуется для его вызова. Кроме того, информация должна быть ограничена только обслуживаемым контрактом (технический контракт и соглашение об уровне обслуживания ), потребителям услуг не должны предоставляться никакие другие документы или носители, кроме контракта на обслуживание, который содержит дополнительную информацию, относящуюся к услугам.
Цель
Контракт на обслуживание, который содержит подробную информацию о том, что он инкапсулирует (например, логика, реализация и технология, используемые для создания службы), может в конечном итоге использоваться определенным образом, предоставляя потребителю услуги больше знаний о работе службы. В случае ориентации на услуги больше знаний не обязательно лучше. Существует вероятность того, что дополнительная информация может помешать повторному использованию сервиса, поскольку разработчик потребителя сервиса может оптимизировать свой дизайн на основе этих знаний. Однако это повлияет на развитие контракта на обслуживание, поскольку теперь потребитель услуги косвенно связан с реализацией услуги, которую, возможно, потребуется заменить в будущем. Это увеличивает тип соединения " потребитель-контракт ", который является положительным типом соединения. Однако слишком большая зависимость может негативно повлиять на эволюцию как поставщика услуг, так и потребителя услуг.
Скрытие информации остается одним из ключевых принципов объектно-ориентированной парадигмы, которая способствует абстрагированию внутренней работы программы . Классическим примером может быть использование абстрактных классов, чтобы скрыть фактическую логику метода. Та же концепция применяется в принципе абстракции сервиса, чтобы скрыть ненужные детали о работе сервиса с целью облегчения эволюции сервиса. [2]
Заявление
Применение этого принципа проектирования требует изучения четырех различных типов абстракций, которые могут быть применены к сервису.
Функциональная абстракция
Эта форма абстракции зависит от того, какая часть логики службы представлена как возможности службы. Примером может служить класс, в котором некоторые из его методов являются частными, а другие - общедоступными. Класс будет предоставлять только те методы как общедоступные, которые он считает важными для своих объектов, любые вспомогательные методы, которые не имеют отношения к объектам, остаются скрытыми.
Контракт на обслуживание, который не подчиняется этому принципу, можно назвать «подробным контрактом», который раскрывает большую часть бизнес-правил и логики проверки. Как только этот принцип будет применен в достаточной степени, контракт можно будет назвать «кратким контрактом». Дальнейшее применение этого принципа разработки приведет к «оптимизированному контракту», который максимизирует потенциал повторного использования услуги.
Технологическая информационная абстракция
Любая информация о базовой технологии, используемой в службе, приведет к низкотехнологичной абстракции информации, поскольку контракт службы явно сообщает потребителям службы, как спроектирована логика службы и ее реализация. Эта дополнительная информация может привести к тому, что потребители услуг будут спроектированы таким образом, чтобы специально нацеливать эту конкретную реализацию, тем самым развивая связь потребителя с реализацией .
Логическая абстракция
Программные детали логики службы необходимо абстрагировать [3], поскольку знание о том, как служба на самом деле выполняет свои функции, может привести к потребителям службы, которые учитывают эту информацию и, следовательно, разработаны с учетом этих предположений. Это может серьезно затруднить работу по рефакторингу логики сервиса и может рассматриваться как антишаблон по отношению к применению шаблона проектирования рефакторинга сервиса .
Качественная абстракция
Абстракция качества относится к деталям, предоставленным в сопроводительном соглашении об уровне обслуживания. Важно сконцентрироваться только на той информации, которая действительно поможет в определении надежности и доступности услуги, не следует включать никакой другой информации, раскрывающей ненужные детали, например подробности о том, как услуга входит в общий бизнес-процесс и какая другие службы, которые он использует для выполнения своих функций.
Уровень управления доступом, применяемый к сервису, будет определять, сколько абстракций технологии, логики и качества сервиса будут на месте. «Открытый доступ» предоставит свободный доступ всем, кто заинтересован в определении проектных спецификаций услуги. При «контролируемом доступе» доступ предоставляется только авторизованным лицам, а политика «запрета доступа» полностью запрещает любой доступ к проектной документации.
Соображения
Хотя сокрытие информации считается здоровой практикой, тем не менее, слишком большое сокрытие информации может быть контрпродуктивным, поскольку может ограничить уровень повторного использования службы. Это также может привести к избыточным сервисам, поскольку разработчики сервисов не имеют достаточной информации о возможностях сервиса. Для этого каждый контракт на обслуживание должен быть разработан кратким, но всеобъемлющим образом, чтобы возможности службы могли быть эффективно обнаружены и интерпретированы в соответствии с принципом обнаруживаемости службы .
Тип информации, представленной в контракте на обслуживание, также может вызвать некоторые проблемы, связанные с безопасностью. например, служба, распространяющая сведения об используемой базе данных в результате внутренней ошибки, может стать жертвой атаки, когда злоумышленник использует сведения о сообщенной ошибке и пытается подключиться к базе данных. Эту проблему можно решить путем применения шаблонов проектирования фильтрации сообщений [4] и экранирования исключений [5] .
Рекомендации
- ^ Сервис
- ^ Деннис Висноски. Принципы и модели Министерства обороны США [Интернет]. Дата обращения: 13 апреля 2010 г.
- ^ Кьелл-Сверре Jerijærvi. Модель зрелости контрактов SOA [Online]. Дата обращения: 13 апреля 2010 г.
- ^ Проверка сообщений
- ^ Исключительное экранирование
дальнейшее чтение
- Мауро. и другие. Сервисно-ориентированная интеграция устройств - анализ шаблонов проектирования SOA. [онлайн], стр. 1–10, 2010 г. 43-я Гавайская международная конференция по системным наукам, 2010 г. Дата обращения: 8 апреля 2010 г.
- Томас Эрл . Сервис-ориентированность и объектная ориентация, часть II: сравнение принципов проектирования [онлайн]. Дата обращения: 13 апреля 2010 г.
- Tost. и другие. Руководство по использованию контрактных технологий веб-сервисов [Online]. Дата обращения: 13 апреля 2010 г.
- Пекка Альхо. Применение новых технологий автоматизации проектирования и интеграции программного обеспечения в обучении [Онлайн]. Дата обращения: 13 апреля 2010 г.