ECF TC:
Here is additional information for our discussion tomorrow.
I volunteered to look into 2 issues reported by Springboard. In this email, I provide the write-up of the issue and suggestions provided by Open Networks, as well as my suggestion for handling the issue.
I-10.
Error Handling
Issue Details:
-
The response to a request for an operation
not supported by the court MUST be reported using the ECF 4.0 <ErrorCode> element in the core message and MAY also include a SOAPFault in the SOAP envelope.
-
First, in the event that a web service has
not implemented an operation, the client will receive a standard SOAP fault, not an application-level error from the server.
-
Also, a service cannot generate two synchronous
responses to the same message, so either a response with the <ErrorCode> element or a SOAP fault will be sent.
Open Networks Suggestion:
-
All SOAP-based web service applications
must be able to handle standard SOAP faults, which will be the default mechanism used to communicate
non-application errors.
Therefore, using the same method to send
application specific errors, allows interface systems to handle all errors,
infrastructure as well as application, in a common way.
-
The Error element (and associated type)
defined in the ECF-4.0-CommonTypes schema will not be utilized by systems that implement interfaces consistent with the ECF WS SIP.
The ECF-4.0-CommonTypes schema will not need to change, since the WS SIP interfaces will simply ignore any Error elements found in the message responses.
MTG Suggestion:
IO-4.
Binary Encoding
Comments:
-
The ECF WS SIP identifies
the use of MTOM for all request/response message encoding. We recommend consideration of the following aspects of the binary encoding decision:
-
Since MTOM is a SOAP-based solution, an
alternative binary encoding/storage mechanism must be provided for any non-soap SIP. As such, the core data specification must provide another method for encoding binary data.
-
Performance:
-
MTOM encoding has more overhead
than text/xml encoding for simple text-based messages and even small (< 5 KB) binaries. Therefore, the composition of message data is an important factor in determining the encoding mechanism
-
NIEM compliant base64
encoding, which is built into the XML specification, would provide a
consistent mechanism for binary encoding and transport across all SIPs.
MTG Suggestion:
Jim Cabral
MTG Management Consultants, L.L.C.
www.mtgmc.com
(206) 442-5010 Phone
(502) 509-4532 Mobile
Helping our clients make a difference in the lives of the people they serve.
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer.
|