Framework Overview
This section describes how you model a client adapter (or driver and responder modules) in Fulfillment Provisioning. The Fulfillment Provisioning approach is extremely flexible, allowing your solution to communicate with any type of service management application.
Client adapters are responsible for communicating with service management applications. Service orders enter a provisioning flow from a service management application by way of a client adapter. And the result of the provisioning is passed back to the service management application by way of a responder.
The client adapter framework is composed of several parts:
Those parts can be administrated and configured with the tools commonly used in a Fulfillment Provisioning application (provadmin command, *.ini configuration files).
The session layer is composed of session managers and sessions. It is designed for efficiently processing incoming messages in parallel.
The Streams layer is composed of the provca::ClientAdapter Streams module which must be deployed in a main Fulfillment Provisioning flow. It provides access to all necessary runtime elements of the client adapter instance as well as configuration and administration callbacks.
A protocol message flow is a versatile flow able to manage protocol message processing, being data transformations or I/O operations.
A client adapter instance can be configured to use two distinct protocol message flow instances : one can be used for receiving protocol messages and the other to send protocol messages.
A protocol message flow configured in the receive direction processes protocol messages (request, ack, response) coming from the service application management. This processing may consist of protocol decoding, framing, parsing etc.
A protocol message flow configured in the send direction processes protocol messages coming from the Fulfillment Provisioning application in order to send data to the service application management. This processing may consists in protocol message formatting, sending etc.
The request and response messages can be in any format (for example, EDIFACT or XML) used by the service management applications. Any communication protocol (for example, TCP/IP or HTTP), or any other means, can be used to interact with the service management applications.
For example, suppose that a management application communicates using XML messages on TCP/IP. The figure depicts this typical example.
The client adapter receives a raw buffer on a socket, instantiates a protocol message with the buffer inside, retrieves the entry point in the reception protocol message and injects the protocol message into this module. The protocol message then goes through the protocol message flow through some specialized modules, which decode the envelop, parse the XML, create service orders, and send an acknowledgment.
At the other end of the provisioning flow, when the provisioning is complete, a service order containing aggregated information comes to the Responder instance. Once inside the Responder, this service order is considered a protocol message. The responder retrieves the entry point of the sending protocol message flow and injects the protocol message into this module. The protocol message then goes through the protocol message flow, through specialized modules which format a TCP buffer that the service application management understands and sends the buffer via TCP/IP to the management application.
Driver is a symbolic name for an instance of Client Adapter used in the context of request reception. Responder is a symbolic name for an instance of Client Adapter used in the context of response sending.
A former data layer is still available as part of the framework. It is based on a service context abstraction and provides framers and parsers responsible for decoding incoming messages.
A Framer/Parser couple can parse the format of messages that the service management application sends. Coupled with a responder is typically a composer that can generate messages in a format that the service management application understands. For details on the framer, parser and composer modules, see the Data processing section.