Войти
Стандартный контракт на обслуживание - это программное обеспечение Принцип проектирования, применяемый в рамках ориентации на услуги парадигмы проектирования, чтобы гарантировать, что контракты на обслуживание в рамках перечня услуг (предприятия или домена) соответствуют одному и тому же набору стандартов проектирования. Это упрощает стандартизованные контракты на обслуживание в инвентаре услуг.
гибкость, обещанная сервис-ориентированной архитектурой (SOA), обычно измеряется в терминах уровень повторного использования содержащихся в нем сервисов. Однако такая возможность многократного использования напрямую связана с тем, как контракт на обслуживание определяет возможности службы. Служба, построенная на потенциально повторно используемом функциональном контексте, но с контрактом, который неправильно передает эту возможность повторного использования, не достигает своего потенциала повторного использования.
В сервисно-ориентированных решениях контракт на обслуживание представляет собой фундаментальный артефакт, поскольку это единственная среда, через которую службы взаимодействуют друг с другом или с другими потребительскими программами. Это создает острую потребность в стандартизации сервисных контрактов, чтобы сделать сервисы максимально многоразовыми и перекомпонованными. Чтобы достичь этого, необходимо применять принцип разработки стандартизированного контракта на обслуживание, поскольку его применение приводит к созданию стандартизированных контрактов на обслуживание, основанных на стандартах проектирования, установленных в перечне услуг.
Одна из его целей - снизить потребность в преобразовании данных, поскольку две службы взаимодействуют друг с другом, что может быть достигнуто, если в контрактах на службы используются стандартизированные модели данных, например XML-схемы, если службы были реализованы как веб-службы. Это также помогает сделать сервисы более совместимыми. Еще одна важная цель этого шаблона проектирования - использовать стандартизированный способ выражения возможностей службы, чтобы их назначение и возможности можно было легко понять во время разработки.
Обычно заключается контракт на техническое обслуживание состоит из документа WSDL, схем (-ей) XML и документа (-ов) политики. Следовательно, этот принцип должен применяться в трех областях контракта на обслуживание, как описано ниже:
Операции службы должны быть определены с использованием стандартизованных соглашений об именах. Это также применимо к именам составляющих входных и исходящих сообщений и их соответствующим именам типов. Это помогает повысить точность интерпретации контракта на обслуживание, что, в свою очередь, увеличивает возможность повторного использования и взаимодействия услуг. Когда контракты на обслуживание ясно выражают их возможности, вероятность дублирования услуг также снижается.
Две службы, обменивающиеся сообщениями на основе одного и того же типа данных - например, заказ на поставку - могут моделировать эти данные в соответствии с разными схемами, что требует преобразования модели данных. Это явно увеличивает накладные расходы и препятствует взаимодействию и повторному использованию сервисов. Чтобы избежать этого преобразования, принцип стандартизированного контракта на обслуживание требует стандартизированных моделей данных, что дополнительно помогает создать стандартизированную архитектуру представления данных, которую можно повторно использовать на предприятии для определения возможностей стандартизированных услуг. Централизация схемы напрямую поддерживает цели шаблона проектирования стандартизации модели данных, который дополнительно поддерживает создание схем с централизованным управлением.
Политики обслуживания представляют собой условия использования услуги. Итак, чтобы сервис можно было использовать повторно, его поведенческие требования должны быть последовательно выражены с использованием стандартных выражений политики, основанных на стандартных отраслевых словарях. Этот тип стандартизации дополнительно способствует разделению политик из контрактов на обслуживание в отдельные документы политик, что способствует централизованному управлению. В некоторых случаях две политики, хотя синтаксически разные, могут означать одно и то же, поэтому стандарты проектирования должны диктовать приемлемую структуру политики.
Применение этого принципа проектирования зависит от стандартов проектирования на уровне инвентаризации услуг. Это требует дополнительных ресурсов с точки зрения времени и усилий. Во-вторых, для эффективного применения этого принципа проектирования фактический контракт должен быть физически изолирован от логики и реализации сервиса, чтобы он мог быть основан на отраслевых стандартах. Это может быть достигнуто путем применения шаблона проектирования несвязанного контракта. Кроме того, необходимо придерживаться подхода «сначала контракт», чтобы базовая логика использовала только стандартизованные модели данных. Кроме того, потребность в централизованных моделях данных может заканчиваться передачей избыточных данных между службами, поскольку фактические данные, в которых нуждается служба, могут быть только подмножеством данных, определенных в стандартизированной схеме, наложенной на службу.
