Fw: [legalxml-courtfiling] Re: WS SIP SOAP samples

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

I’m forwarding Eric’s response.

__
Jim Cabral
502 509-4532

From: Eric Eastman
Sent: ‎Thursday‎, ‎June‎ ‎11‎, ‎2015 ‎1‎:‎34‎ ‎PM
To: James E Cabral

JIm,

I still can't reply to list.  I'm working with OASIS, but they are not responsive.

I did some more research and I may have been wrong.  I'm looking into it more, but I think that wrapper element MAY be added automatically when the server publishes the webservice.  Unfortunately I have a LOT of experience consuming webservices but much less publishing them (I prefer more RESTful approach to webservices when I have control).  It may be early next week before I can get back to it, but it's possible that the example just needs an extra element.

Eric

On Thu, Jun 11, 2015 at 11:21 AM, James E Cabral <jec@mtgmc.com> wrote:

ECF TC,

It appears that we have 2 normative parts of the ECF 4.01 Web Services SIP that are in conflict with each other - the WSDLs and Section 2.5 of the specification.  As Gary summarizes below, the naming of the first element in the soap Body as defined in the WSDLs is inconsistent with Section 2.5 and the SOAP specification.

In ECF 5.0, we should plan to update the WSDLs to conform with the SOAP specification.  The question is which fix to the ECF 4.01 WS SIP will cause the minimum disruption to existing implementations and the Springboard testing framework.  Here are 2 options:

1. Update the WSDLs (and possibly the schemas in the Core Specification) so that the names of the messages defined in the WSDL (and/or schemas) align with the operations named in the specification.
2. Update the WS SIP specification to relax the requirements in Section 2.5 about element naming.  If necessary, we could  provide a mapping between operation names and the schema/WDSL elements.

Are there other options? 

Which would be least disruptive to existing implementations of the ECF 4.01 WS SIP?

__
Jim Cabral
502 509-4532

From: Gary Graham
Sent: ‎Wednesday‎, ‎June‎ ‎10‎, ‎2015 ‎4‎:‎00‎ ‎PM

To: James E Cabral
Cc: legalxml-courtfiling@lists.oasis-open.org

I do not think that relaxing the wording in section 2.5 of the WebServices SIP is the correct answer.

 

Even though Appendix C is non-normative it is correct (the TC has discussed making it normative in ECF 5). Even though Appendix C is currently non-normative, the operation names are normative.

 

This issue was raised previously (see attached email). The answer you provided was:

 

“The names of the operations are defined in the main body of the core specification so the names are normative.” 

 

I understand that element names consistent with ECF operation names are not defined in ECF provided schema. Hence it is incumbent upon implementers to define these in local exchange schema or perhaps in wsdl. This is the approach we have taken in Arizona working with efiling vendors.

 

The requirement expressed in section 2.5 (Request and Operation Invocation) goes back a long way and is unrevised since ECF 3 with the Web Services Messaging Profile 1.0 (Nov. 15, 2005). Compliant implementers  would be undoubtedly harmed by such a revision. Such an approach should also harm the Test Bench ECF certification testing.

 

I do not think that section 2.5 was carelessly worded or mis-worded. As noted, section 2.5 states:

Each message transmission MUST identify the operation being invoked within the SOAP Body only; the (qualified) operation name MUST be the qualified name of the first child element of the SOAP body element, as called for in section 7.1 of the [SOAP 1.1] specification.

 

This requirement is reinforced in the referenced section 7.1 of SOAP 1.1 which provides (highlighting added):

 

SOAP 1.1 –section 7.1 RPC and SOAP Body:

“RPC method calls and responses are both carried in the SOAP Body element (see section 4.3) using the following representation:

• A method invocation is modelled as a struct.
• The method invocation is viewed as a single struct containing an accessor for each [in] or [in/out] parameter. The struct is both named and typed identically to the method name.
• Each [in] or [in/out] parameter is viewed as an accessor, with a name corresponding to the name of the parameter and type corresponding to the type of the parameter. These appear in the same order as in the method signature.
• A method response is modelled as a struct.
• The method response is viewed as a single struct containing an accessor for the return value and each [out] or [in/out] parameter. The first accessor is the return value followed by the parameters in the same order as in the method signature.
• Each parameter accessor has a name corresponding to the name of the parameter and type corresponding to the type of the parameter. The name of the return value accessor is not significant. Likewise, the name of the struct is not significant. However, a convention is to name it after the method name with the string "Response" appended.
• A method fault is encoded using the SOAP Fault element (see section 4.4). If a protocol binding adds additional rules for fault _expression_, those also MUST be followed.

As noted above, method and response structs can be encoded according to the rules in section 5, or other encodings can be specified using the encodingStyle attribute (see section 4.1.1).

Applications MAY process requests with missing parameters but also MAY return a fault.

Because a result indicates success and a fault indicates failure, it is an error for the method response to contain both a result and a fault.”

If as you suggest there are only two alternatives for correction (e.g. “relax wording”, or “update schemas”) then I suggest we should pursue the latter (i.e. “update schemas”).

 

Gary Graham

Arizona Supreme Court

 

 

 

From: legalxml-courtfiling@lists.oasis-open.org [mailto:legalxml-courtfiling@lists.oasis-open.org] On Behalf Of James E Cabral
Sent: Wednesday, June 10, 2015 9:17 AM
To: Graham, Gary
Cc: legalxml-courtfiling@lists.oasis-open.org
Subject: [legalxml-courtfiling] Re: WS SIP SOAP samples

 

Appendix C and the samples are non-normative.

 

I think the fix is probably to relax the wording of Section 2.5 itself since there is no schema that defines an element called “GetCase”.  The alternative would be to update the schemas in the Core Specification.  Do you agree?

 

__
Jim Cabral
502 509-4532

 

From: Gary Graham
Sent: ‎Tuesday‎, ‎June‎ ‎9‎, ‎2015 ‎7‎:‎20‎ ‎PM
To: James E Cabral
Cc: legalxml-courtfiling@lists.oasis-open.org

 

See below

 

From: legalxml-courtfiling@lists.oasis-open.org [mailto:legalxml-courtfiling@lists.oasis-open.org] On Behalf Of James E Cabral
Sent: Tuesday, June 09, 2015 2:54 PM
To: Graham, Gary
Cc: legalxml-courtfiling@lists.oasis-open.org
Subject: [legalxml-courtfiling] WS SIP SOAP samples

 

Gary,

 

On the TC call today, you reported an incompatibility between Section 2.5 of the WS SIP specification and at least some of the SOAP samples, including GetCaseRequest.soap.  I’m hoping you elaborate more on what you see as the incompatibility.  The relevant snippets are included below.   Are you saying that you would expect to see “GetCaseRequest” instead of “CaseQueryMessage” inside of the soapenv:Body? No, there are no ECF operations named GetCaseRequest or CaseQueryMessage. However there is an operation named GetCase that takes CaseQueryMessage as a parameter (see C.3.1 of the ECF specification). Hence, the first child element of <soapenv:Body> MUST be GetCase since ‘GetCase’ is the operation name.

 

-------------------------------

WS SIP Section 2.5:

Each message transmission MUST identify the operation being invoked within the SOAP Body only; the (qualified) operation name MUST be the qualified name of the first child element of the SOAP body element, as called for in section 7.1 of the [SOAP 1.1] specification.

An MDE implementation MAY allow message transmissions that include a SOAPAction HTTP header.

In compliance with the [WSI-I BP 1.1] specification, a receiving MDE MAY NOT rely on the value of the SOAPAction HTTP header in processing the message.

-----------------------------

GetCaseRequest.soap:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">

<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

         …

</wsse:Security>

<wsa:Action>urn:oasis:names:tc:legalxml-courtfiling:wsdl:WebServicesProfile-Definitions-4.0\CourtRecordMDEPort\GetCase</wsa:Action>

<wsa:ReplyTo>

<wsa:Address>https://JEC-SURFACEPRO2:8080/mockFilingAssemblyMDEPortSOAPBinding</wsa:Address>

</wsa:ReplyTo>

<wsa:MessageID>uuid:48a86134-9712-451b-a4ee-036d408b4f07</wsa:MessageID>

<wsa:To>https://JEC-SURFACEPRO2/mockCourtRecordMDEPortSOAPBinding</wsa:To>

</soapenv:Header>

<soapenv:Body wsu:Id="id-53204E93D7C96443EC141342618529211" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

<CaseQueryMessage xsi:schemaLocation="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:CaseQueryMessage-4.0 ../../schemas/information/message/ECF-4.0-CaseQueryMessage.xsd" xmlns="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:CaseQueryMessage-4.0" xmlns:ecf="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:CommonTypes-4.0" xmlns:j="http://niem.gov/niem/domains/jxdm/4.0" xmlns:nc="http://niem.gov/niem/niem-core/2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

         …

</CaseQueryMessage>

</soapenv:Body>

</soapenv:Envelope>

 

 

__
Jim Cabral
502 509-4532

 

--

Eric Dimick Eastman
Green Filing, LLC

Web: www.greenfiling.com

Phone: (801) 448-7268

Cell: (765) 277-4158