Open APIs

I'm in the process of designing a number of adaptors for existing systems which will façade the systems with TM Forum Open APIs.

In some of the use cases we have ,rather than direct service to service calls, we need the message to use a different transport.

For example, we have a service which exposes a TMF Open API. When a message is received by the service, we want to keep the message in its original form, but retain the contextual information (such as the URL used, http method, etc). This message, including contextual information, might then be transmitted to a service bus in some form for further processing (and so also adding the need for correlation id if the request needs to be satisfied synchronously).

I have supposed there are two options:

1. Wrap the message payload in another message which contains the contextual meta data, with an attribute containing the unmodified payload.
2. Update the message to some how store the contextual information, by either adding custom attributes, or by perhaps using something like RelatedEntity objects to hold the information.

Looking forward to seeing how other teams have approached this.

------------------------------
Lee Walton
KCOM Group PLC
------------------------------

Hi Lee,

We are facing the same design challenge. We use an ESB with queuing for XML document-based transactions today and are looking to move toward the TMF Open API data model. Not everything can be converted to RESTful HTTP calls, however, due to significant code investment on the client side. Instead we are trying a half-step of an Open API data model in JSON placed inside a message that will go on the ESB. We are going to put the important HTTP headers (URL signifying the resource, the action verb, etc.)  into the queue message as headers so that our server-side thinks in RESTful terms. Hopefully this will help us move more easily off the ESB later.

-Doug

------------------------------
Douglas Beeson
Enterprise Architect
Cogeco Connexion
Canada
------------------------------

Original Message:
Sent: Oct 25, 2018 07:17
From: Lee Walton
Subject: Using ESBs to distribute TMF API requests

I'm in the process of designing a number of adaptors for existing systems which will façade the systems with TM Forum Open APIs.

In some of the use cases we have ,rather than direct service to service calls, we need the message to use a different transport.

For example, we have a service which exposes a TMF Open API. When a message is received by the service, we want to keep the message in its original form, but retain the contextual information (such as the URL used, http method, etc). This message, including contextual information, might then be transmitted to a service bus in some form for further processing (and so also adding the need for correlation id if the request needs to be satisfied synchronously).

I have supposed there are two options:

1. Wrap the message payload in another message which contains the contextual meta data, with an attribute containing the unmodified payload.
2. Update the message to some how store the contextual information, by either adding custom attributes, or by perhaps using something like RelatedEntity objects to hold the information.

Looking forward to seeing how other teams have approached this.

------------------------------
Lee Walton
KCOM Group PLC
------------------------------