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