FIMS Media SOA Framework - AMWA

FIMS Media SOA Framework Phase1 (Preliminary)- APP0104: Job Command failed- APP0105: Queue Command failed- APP0106: Adapter unable to connect to service provider endpoint- APP0107: Job Queue is full, locked or stopped. No new jobs being accepted.- APP0108: Job ended with a failure- APP0200: Adapter received no response from service provider.- APP0201: Adapter received an exception from service provider. See description or exception detail.- APP0202: Adapter received an unknown or an internal error from service provider. See description forerror detail.- APP0203: Unable to connect to client's notification service endpoint (replyTo) to send the asynchronousjob result notification response.- APP0204: Unable to connect to client's service endpoint (faultTo) to send the asynchronous job faultresponse.- APP0205: Feature not supported.- APP0300: Internal or Unknown error encountered. See description for error detail.- EXT0000: Extended code. See extended error code for details.8.3 Service Consumer Interface (Service Events Producer Interface ??)The service consumer interface describes the mechanism used to provide the result and the status of longrunning operations. The support for long-running, asynchronous operations for FIMS services shall beimplemented by two different interaction patterns:• Request/response with asynchronous notification pattern: This pattern is composed by asynchronous request/response call to submit a job to the service and an asynchronous call back fromthe service to the invoking client to return the result of a specific media operation, as illustrated inFigure 1. In this scenario, a service client has to implement a client stub, used for invoking the serviceaccording to a traditional synchronous request-response pattern, and a server stub, used to receive theasynchronous reply back from the service. The service has to implement a server stub, to receive thesynchronous request and to acknowledge that the operation request has been received and processinghas started. In addition, this service has to implement a client stub to call back the client when theoperation is completed. The FIMS specifications require each service to implement this pattern byproviding a port for the synchronous exchange, and a port for the asynchronous reply, which should beimplemented as a client stub. During the initial synchronous interaction, the client sends to the servicean endpoint used by the service for the asynchronous response (replyTo); the service stores thisinformation and uses it later for the call back. A set of correlation parameters (IDs) is adopted tocorrelate the asynchronous reply with the operation initiated by the initial synchronous exchange. Theseparameters must be present in the initial synchronous exchange (in the request, in the response, or inboth) and in the asynchronous reply. The FIMS specification identifies a specific parameter used forcorrelation in the synchronous interaction and the asynchronous reply (jobGUID) see sections xxxx).• Request/response with status polling pattern: This pattern is composed by a synchronousrequest/response to submit a job to the service to the service and a periodic call to a status serviceinterface to check the job status (polling). The FIMS specifications require each service to implementthis pattern by providing a port for the status check, as described in section xxx.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 67 of 89