Springboard Issues

[James E Cabral <jec@mtgmc.com>]

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:

• Section 2.4 of the ECF WS SIP states:

• 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.

• The requirement seems to have two issues:

• 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:

• The ECF WS SIP should be revised to clearly define SOAP faults as the mechanism used to communicate error information between web service exchange partners. 

• 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:

• Accept the suggestion from Open Networks.

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:

  • Consistency
  • 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:

• MTOM includes efficient base64 encoding and adds a small amount of additional data that assists with the parsing and file formatting of the data.  Base64 encoding (without MTOM) was included for backward compatibility with previous ECF specifications.  Therefore do not change the current specification and drop support for base64 encoding in future versions of the specification.

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.