Абстракция службы - Service abstraction

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

Цель

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

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

Заявление

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

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

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

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

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

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

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

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

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

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

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

Соображения

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

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

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

  1. ^ Служба
  2. ^ Деннис Висноски.Принципы и модели в Министерстве обороны США [Online]. Дата обращения: 13 апреля 2010 г.
  3. ^ Kjell-Sverre Jerijærvi.Модель зрелости контракта SOA [Online]. Дата обращения: 13 апреля 2010 г.
  4. ^ Проверка сообщений
  5. ^ Исключительное экранирование

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

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