Request and Response Framework transaction flow

As the Request and Response Framework receives a transaction request, it takes it through a series of predefined steps designed to process a request and generate a transaction response.

The following flow illustrates these actions. This request and response workflow uses the InfoSphere® MDM default XML format as an example.

  1. DWLServiceController receives the request from the client application and dispatches it to the appropriate request handler (in this case, DWLRequestHandler). DWLServiceController uses the RequestType parameter to determine which request handler to use. See DWLServiceController.
  2. DWLRequestHandler interacts with underlying components to carry out the request. See RequestHandler.
  3. RequestParserManager determines the type of parser factory to use (in this case, DWLParserFactory). RequestParserManager uses the same RequestType parameter as DWLServiceController to determine the request parser factory to use.
  4. DWLParserFactory creates a request parser based on the value of the parser key in the HashMap:context (in this case, default XMLRequestParser). The parser is returned to RequestParserManager and then returned to DWLRequestHandler.
  5. XMLRequestParser parses out the DWLTransaction object. In the object, DWLControl and transaction type are set.
  6. HashMap:context contains an optional key: OperationType. If the OperationType has a value of parse, DWLRequestHandler class returns the result of parsing, which is the DWLTransaction object, to the caller. If the OperationType has a value of process, DWLRequestHandler passes the DWLTransaction object on to the business proxy for further processing. OperationType is optional; if it is not set, or if it is set with a value of all, DWLRequestHandler retrieves a parser first, then uses the parser to parse out a DWLTransaction object, followed by business processing through business proxy.
  7. DWLTxnProcessor uses business proxies to invoke the InfoSphere MDM business services layer.
  8. ResponseConstructorManager determines the type of response constructor factory to use, based on the ResponseType parameter, in this case DWLConstructorFactory.
  9. DWLConstructorFactory creates one ResponseConstructor based on the ConstructorParam in context (in this case, it uses the default, XMLResponseConstructor).
  10. Constructor provides a response object and sends the object back to client application.
  11. In the case of MDM transaction failure, rule ID 218 is executed to perform intra-application failover compensation. Invocation of this rule is within a new transaction context that is independent from the main MDM transaction. The default implementation of this rule contains no specific compensation logic.