FIMS Media SOA Framework - AMWA

More documents

Recommendations

Info

FIMS Media SOA Framework Phase1 (Preliminary)Code ErrorCodeType The error code. It can be one of the values specified inErrorCodeType. It shall be set to "EXT0000" for serviceclass-level specific errors that are not in the base list. Inthis case the error code shall be set in the "extendedCode"field of the extended fault.Description xsd:string An optional description of the error.Detail xsd:string This optional field shall be used to provide the native errorstack trace from the service provider, if available.8.2.2.4.1.2 ErrorCodeTypeThis type enumerates common error codes that different classes of adapters can share. This code shall be set to“EXT0000” if the adapter provides an extended, class-specific error code. Error codes are classified in threemain categories:• SYSxxxx: system level errors• DATAxxxx: data validation errors• APPxxxx: service level errorsA list of common error codes is shown below. This list is not meant to be a comprehensive listing of all possibleerrors, but it is meant as an example to show only the different type of errors and their range of error codes, asfollows:- SYS0100: System Unavailable- SYS0101: System Timeout- SYS0102: System Internal Error- SYS0103: Unable to connect to the database- DATA0100: Invalid Request XML Format- DATA0102: Invalid Input Media Format- DATA0103: Invalid JobID- DATA0104: Missing required service metadata in request- DATA0105: Duplicate JobGUID detected for new job.- DATA0106: Invalid Request Parameters- DATA0107: Job Command not valid- DATA0108: Queue Command not valid- DATA0109: Invalid Priority- DATA0110: Input Media not found. Invalid Resource URI specified.- APP0100: Job Command is not currently supported by the adapter or the service provider- APP0101: Queue Command is not currently supported by the adapter or the service provider- APP0102: Operation requested is not currently supported by the adapter or the service provider- APP0103: Adapter unable to find/lookup service provider endpointPrivate committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 66 of 89
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
Page 1 and 2:
FIMS Media SOA FrameworkAMWA Specif
Page 3 and 4:
FIMS Media SOA Framework Phase1 (Pr
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Page 13 and 14:
Page 15 and 16: FIMS Media SOA Framework Phase1 (Pr
Page 65: FIMS Media SOA Framework Phase1 (Pr
Page 89: FIMS Media SOA Framework Phase1 (Pr
show all

FIMS Media SOA Framework - AMWA

Create successful ePaper yourself

Delete template?

Save as template?