9 декабря этого года TMForum опубликовал пресс-релиз о выходе первого Digital Service Toolkit, предназначенного для организации взаимодействия между абонентами и компаниями (операторами и поставщиками услуг) для построения цифровых сервисов и поддержки интернета вещей (Internet of Things). Toolkit представляет собой набор руководств по построению партнерских продуктов и услуг, шаблоны построения бизнес-моделей и организации операционного взаимодействия и спецификации программных интерфейсов. Наверное, наиболее интересно выглядят именно рекомендации по построению бизнес-моделей, собранные в руководстве Online B2B2X Partnering Step by Step Guide, включающем набор готовых шаблонов и примеров, по разработке ценностного предложения (Customer Market Proposition), бизнес-модели, контрактов на совместное предоставления услуги, финансовой и операционной модели. Но мы поговорим о другом: эталонных архитектурах, моделях данных и спецификациях программных интерфейсов.
Написанием спецификаций программных интерфейсов (APIs) TMForum занимается не первый год. Сначала это выглядело как-то не очень убедительно. Так, например, Simple Management API, предназначенный для управления услугами, вышел в двух версиях – REST XML и REST JSON. Но более поздние спецификации постепенно избавляются от детских болезней, обрастают описаниями моделей предметной области и руководствами для бизнес-заказчиков с веселыми картинками, типа приведенной ниже:
Но мы обратимся к более конкретным вещам, к устройству APIs. Сейчас разработаны 12 спецификаций интерфейсов:
- Product ordering API
- Catalog management API
- Trouble ticketing API
- Service level agreement API
- Performance management API
- Customer management API
- Party management API
- Usage API
- Billing API
- Product Inventory API
- Service Inventory API
- Resource Inventory API
и большинство из них сделаны в новой логике, которую можно было бы назвать «логикой микросервисов». Последние пару лет все сообщество разработчиков ПО увлечено идеей микросервисов. Мартин Фаулер не только успевает критиковать идеи SEMAT (см. статью в PCWeek «Анти-SEMAT или каждому свое?«), но и рассказывать нам что же такое микросервисы. Но, пожалуй, доходчивой всего эту next big thing, а заодно и про CQRS и Event sourcing рассказывают гартнеровские аналитики в своих вебинарах. Картинка с одного из последних
Рассмотрим, как идеи этой картинки воплощаются в конкретном API, например в Trouble ticketing (можно было взять и Product ordering или другие интрефейсы, все они сделаны по общим принципам, описанным в книжках REST API Design Guidelines TMF630, TMF631).
Query интерфейс выглядит традиционно. Вызовы:
GET /api/ticket
GET /api/ticket?status=Close&statusResolutionDate.gt=2013-05-01
GET /api/ticket/1
GET /api/ticket/1/status,statusChangeReason
приводят соответственно к получению всех тикетов, выборке тикетов, закрытых после 1 мая 2013 года, получению тикета с номером 1 или же к получению из этого тикета только атрибутов статус и причина его изменения. Довольно типично выглядят интерфейсы создания и редактирования(полного или частичного):
POST /api/ticket
PUT /api/ticket/1
PATCH /api/ticket/1
И, пожалуй, самое интересное – интерфейсы нотификации. Регистрация интерфейс для получения нотификаций выглядит примерно так
REQUEST
POST /api/hub
Accept: application/json
{«callback»: «http://in.listener.com»}
RESPONSE
201
Content-Type: application/json
Location: /api/hub/42
{«id»:»42″,»callback»:»http://in.listener.com»,»query»:null}
После данного вызова реализующий сервис узел начнет посылать нотификации по указанному адресу
POST /client/listener
Accept: application/json
{
«event»: {
EVENT BODY
},
«eventType»: «eventType»
}
Для завершения отправки нотификаций вызываем
DELETE /api/hub/{id}
В общем, выглядит это все довольно современно, совсем не похоже на эксплуатируемые сейчас в телекомах биллинги, CRM и прочие информационные системы поддержки бизнеса. Впрочем, многочисленные сотрудники отечественных операторов связи и компаний предоставляющих дополнительные сервисы вряд ли читают материалы TMForum. И потому еще много лет будут внедрять морально устаревшие решения 90-х, любезно продаваемые им мегавендорами.