Несколько замечаний относительно Open Digital API

frameworx9 декабря этого года 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. Но более поздние спецификации постепенно избавляются от детских болезней, обрастают описаниями моделей предметной области и руководствами для бизнес-заказчиков с веселыми картинками, типа приведенной ниже:

mgmtapi

Но мы обратимся к более конкретным вещам, к устройству 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 рассказывают гартнеровские аналитики в своих вебинарах. Картинка с одного из последних

microservices

Рассмотрим, как идеи этой картинки воплощаются в конкретном 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-х, любезно продаваемые им мегавендорами.

Реклама

10 Comments

  1. A question, please, about the pinkish arrows between «message broker» and «another micro-service». In SOA, a service communicates with its consumer ONLY via its interface. But in the picture, «another microservice» has an extra «door» in addition to its normal interface.

    Thus these pinkish arrows either are misplaced or microservices do no follow SOA or something-else. Can you clarify this, please.

    Thanks,
    AS

    Ответить

    1. Я взял этот слайд из презентации Anne Thomas Application Architecture for Digital Business Думаю, что она более профессионально ответит на этот вопрос.

      На мой взгляд, архитектура «сеть микросервисов», о которой речь на вебинаре идет чуть раньше, действительно, не отвечает ограничению сервисной архитектуре/ По крайней мере, если трактовать её в изначальной формулировке. Но думаю, те же аналитики Gartner давно перешли к более общей трактовке SOA, заговорив о трех стилях: RPC-style, EDA, web-oriented architecture.

      Ответить

    1. Большинство материалов доступно после регистрации с почтового адреса из домена организации-участника TMForum. Но можно и просто так зарегистрироваться с любым адресом. Я не уверен, что после этого будут доступны все(!) материалы из Toolkit, но попробовать стоит 🙂

      Ответить

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s