Контракт

Интерфейс

Структура Сервиса

Public Enterprise Services

Такие сервисы предоставляют услуги уже не с точки зрения конкретного приложения, но с точки зрения предприятия (или организации) как такового. Т.е. если организация занимается продажей авиабилетов например через WebService, то пользователи, или клиенты организации, по большому счету индифферентны, по отношения к тому какая система отвечает за предоставление этой услуги. Всё что им интересно – это интерфейс сервиса и его контракт.

Являясь основополагающей абстракцией в SOA, сервис полезно рассматривать как нечто обладающее структурой. Последняя полезна как при академическом рассмотрении сервиса, так и при практическом проектировании, документировании и реализации сервисов.

В рамках курса будем считать, что сервис обладает следующими структурными элементами:

• Интерфейс
• Контракт
• Реализация

Интерфейс представляет собой формализованное описание (например, на каком либо языке программирования) набора операций (методов), принимаемых параметров, форматов принимаемых параметров или документов, их кодировку. Следует отметить, что не все сервисы могут экспортировать методы (операции) как таковые. Для сервиса вообще может быть неприменима понятие операция. Т.е. он может принимать на вход некий документ (например, в формате XML) и вообще говоря, если это нигде не оговорено в контракте или ещё где либо, может не выполнять никаких действий наблюдаемых со стороны той системы, которая осуществляет его вызов. Примером может быть сервис, который получает уведомления по подписке.

Существует ряд общепринятых способов задания интерфейса при проектировании сервис-ориентированных систем. Одним из них является протокол WSDL для WebService’ов.

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

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

Под контрактом часто понимают то описание сервиса, которое не может быть охвачено понятием интерфейс. В то время как интерфейс описывает синтаксис и семантику вызова сервиса (т.е. что делает и как этим воспользоваться, иными словами функциональные требования), контракт описывает нефункциональные требования. Т.е., например, требования к производительности сервиса или его доступности. Примером может служить служба (сервис) бронирования билетов, которая доступна по рабочим дням в рабочее время с 10 до 19 часов. При этом дополнительно в контракте задаётся то, что время обработки заказа не превышает 15 минут, после чего сервис должен либо сообщить о недоступности билета, либо выполнить бронирование.

Совершенно понятно, что такая информация не может содержаться в интерфейсе по ряду причин, некоторыми из них являются:

• Практически неограниченный список контрактных ограничений на доступность и качество выполнения услуги. Т.называемый SLA – Service Level Agreement. Вообще SLA является важной и часто неотъемлемой частью контракта сервиса так как именно SLA определяет надлежащее качество обслуживания, и как следствие не только является решающим при выборе провайдера сервиса, но и служит своего рода защитным механизмом как потребителя от ненадлежащего обслуживания, так и провайдера сервиса от необоснованных претензий со стороны потребителя.
• Слабая возможность унификации и стандартизации описания контрактных ограничений, хотя определённые параметры можно вполне успешно задавать в строго формальной форме. Например, доступность.
• Тарификация. По понятным причинам многие услуги являются платными, и как следствие контракт должен включать такую информацию.