This document defines a Service Interaction Profile, as
called for in section 5 of [ECF-v4.1]. The purpose
of the Web Services Service Interaction Profile is to provide a web
service-based system in conformance with the WS-I Basic Profile 1.1 ([WS-I
BP 1.1]) and Basic Security Profile 1.0 ([WS-I BP 1.0]) for use with
the [ECF-v4.1] specification. This version improves security support for
tokens, attachments, and rights management through inclusion of WS-Security 1.1
and adds supports for message splitting and assembly through inclusion of
WS-Reliable Messaging 1.0. This specification requires an active network
connection between the sending and receiving MDEs.
1.1 Relationship to ECF
4.1 Specifications
The ECF 4.1 specification describes the technical architecture
and the functional features of an electronic court filing system, that is,
features needed to accomplish electronic filing in a court, pointing out both
normative (required) and non-normative (optional) business processes it
supports. The non-functional requirements associated with electronic filing
transactions, and actions and services needed to accomplish the transactions,
such as network structures and security infrastructures, are defined in related
specifications, namely:
·
Service interaction profile specifications defining
communications infrastructures within which electronic filing transactions can
take place.
·
Document signature profile specifications that define mechanisms
for stating or proving that a person signed a particular document.
This specification represents an ECF 4.1 service interaction
profile based on web-services. It is intended for implementation in
conjunction with the ECF 4.1 specification and at least one ECF 4.1 document
signature profile specification. Specifically, in this service interaction
profile, the implementation details for each of the Major Design Elements
(MDEs), operations, and messages defined in the ECF 4.1 specification, are
defined in Web Services Description Language (WSDL).
Consistent with the ECF 4.1 principle of leveraging other
existing, non-proprietary XML specifications wherever possible, this service
interaction profile specification leverages previous specifications for web
services messaging and security including the following:
·
W3C XML Schema 1.0 ([Schema Part 1, Schema
Part 2]).
·
W3C Namespaces in XML ([Namespaces]).
·
W3C Simple Object Access Protocol (SOAP) 1.1 ([SOAP 1.1]).
·
W3C Web WSDL 1.1 ([WSDL 1.1]).
·
W3C XML-Signature
Syntax and Processing
([XMLSIG]).
·
W3C
SOAP 1.1 Binding for MTOM 1.0
·
WS-I Basic Profile Version 1.1.
·
WS-I Basic Security Profile Version 1.0.
·
OASIS WS-Reliable Messaging 1.0.
The use of each
of these specifications is described below.
The W3C XML Schema 1.0 ([Schema Part 1,
Schema Part 2]) specification defines an application protocol for
imposing constraints on the storage layout and logical structure of data
objects using text tags or “markup.” Compliance with the requirements of the
XML Schema 1.0 specification is REQUIRED for compliance with this service interaction
profile.
The W3C Namespaces in XML ([Namespaces])
specification defines conventions for defining and referring to separate
XML tags. Compliance with the requirements of the Namespaces in XML
specification is REQUIRED for compliance with this service interaction profile.
The W3C SOAP 1.1 ([SOAP 1.1]) specification
defines message exchange patterns and message structures for use with XML.
Compliance with the requirements of the SOAP 1.1 specification is REQUIRED for
compliance with this service interaction profile.
The W3C WSDL ([WSDL 1.1]) specification
enables the description of services as sets of endpoints operating on messages.
Compliance with the requirements of the WSDL 1.1 specification is REQUIRED for
compliance with this service interaction profile.
An MDE implementation MUST consist of a [SOAP
1.1] web service that implements the SOAP HTTP binding for that MDE’s portType
from the corresponding MDE WSDL document provided with this specification (e.g.
CourtRecordMDE.wsdl). Further,
the implementation MUST be accompanied by an implementation-specific WSDL
document that imports the namespace defined in the MDE WDSL, and defines a <wsdl:service>
element containing a <soap:address>
element with a location
attribute whose value provides an HTTP URL at which the MDE implementation can
be invoked.
(Note that in the previous paragraph, a namespace prefix of
“wsdl” is assumed to map to the http://schemas.xmlsoap.org/wsdl/
namespace, while the namespace prefix of “soap” is assumed to map to the http://schemas.xmlsoap.org/wsdl/soap/
namespace.)
An example (non-normative) implementation-specific WSDL
document for each MDE (e.g. wsdl/examples/CourtRecordMDE-ImplementationExample.wsdl)
is provided with this specification.
1.2.5 W3C XML-Signature Syntax and Processing
The W3C XML Signature Syntax and Processing ([XMLSIG])
specification defines representations of signatures of Web resources,
portions of protocol messages (anything that may be referenced by a URI), and
procedures for computing and verifying such signatures. Compliance with the
requirements of the XML Signature Syntax and Processing specification is
REQUIRED for compliance with this service interaction profile.
The WS-Interoperability Basic Profile 1.1 ([WS-I BP 1.1])
specification defines a set of best practices for implementing interoperable
web services. Compliance with the requirements of the [WS-I BP 1.1],
with the exceptions noted in Section 1.2.7, is REQUIRED for compliance with
this service interaction profile.
The SOAP 1.1 Binding for MTOM 1.0 ([ SOAP MTOM 1.0])
defines a set of best practices for implementing interoperable serialization of
the SOAP envelope and its representation in the message. This binding MUST be
used as a replacement for the WS-I Attachments Profile 1.0 and the W3C Simple
SOAP Binding Profile in the WS-I Basic Profile [WS-I BP 1.1]. Compliance
with the requirements of the [ SOAP MTOM 1.0] and the specifications
that this binding references, the SOAP Message Transmission Optimization Mechanism
(MTOM) ([MTOM)] and the W3C XML-binary Optimized Packging (XOP)
specifications ([XOP]), is REQUIRED for compliance with the web services
service interaction profile.
The WS-Interoperability Basic Security Profile Version 1.0 ([WS-I
BSP 1.0]) complements [WS-I BP 1.0] and defines a set of best
practices for implementing interoperable and secure web services. With the
exception of the requirements for use of the WS-I Attachments Profile 1.0 and
the W3C Simple SOAP Binding Profile 1.0, compliance with the requirements of [WS-I
BSP 1.0] is REQUIRED for compliance with this service interaction profile.
However, in many cases, [WS-I BSP 1.0] is underspecified. The following
options in [WS-I BSP 1.0] are REQUIRED for compliance with this web
services service interaction profile:
·
E0002 - Security Tokens - Security tokens MUST be specified in
additional security token profiles. (NOTE: This will be determined in Court
Policy)
·
R3103 - A SIGNATURE MUST be a Detached Signature as defined by
the XML Signature specification.
The WS-Reliability 1.1 ([WS-RM 1.1]) specification
complements [WS-I BP 1.1] and defines a set of extensions for exchanging
SOAP messages with guaranteed delivery, no duplicates, and guaranteed message
ordering.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in [RFC2119].
The key terms used in this specification include:
Attachment
Information transmitted between MDEs that is of an
arbitrary format, and is related to the ECF 4.1 message(s) in the transmission
in a manner defined in the ECF 4.1 specification. An attachment may be in XML
format, non-XML text format, encoded binary format, or un-encoded binary
format.
Callback message
A message transmission returned by some operations some
time after the operation was invoked (asynchronously).
Document
Represents an electronic version of the paper that would
have been sent as paper.
Docketing
The process invoked when a court receives a pleading,
order, or notice, when no errors in transmission or in presence of required
content have occurred, and when the pleading, order, or notice is recorded as a
part of the official record.
Filer
Attorneys or pro se litigants are individuals who assemble
and submit Filings (data and documents).
Filing
Electronic document collection that has been assembled for
filing on a designated court case.
Major Design Element (MDE)
A logical grouping of operations representing a significant
business process supported by ECF 4.1. Each MDE operation receives one or more
ECF 4.1 messages, returns a ECF 4.1 synchronous response message, and
optionally sends an ECF 4.1 asynchronous response message back to the original
sender.
Message
Information transmitted between MDEs that consists of a
well-formed XML document that is valid against one of the defined message
structure schemas in the ECF 4.1 specification. A message may be related to
one or more attachments in a manner defined in the ECF 4.1 specification.
Message Transmission
The sending of one or more ECF 4.1 messages and associated
attachments to an MDE. Each transmission must invoke or respond to an
operation on the receiving MDE, as defined in the ECF 4.1 specification.
Operation (or MDE Operation)
A function provided by an MDE upon receipt of one or more ECF
4.1 messages. The function provided by the operation represents a significant
step in the court filing business process. A sender invokes an operation on an
MDE by transmitting a set of ECF 4.1 messages to that MDE, addressed to that
operation.
Operation signature
A definition of the ECF 4.1 input message(s) and ECF 4.1 synchronous
response message associated with an operation. Each SOAP message is given a
name and a type by the operation. The type is defined by a single one of the
structures defined in the ECF 4.1 specification.
Receiving MDE
In an Electronic Court Filing operation, the MDE that
receives the request with the operation invocation performs the operation and
sends the response.
Sending MDE
In an Electronic Court Filing operation, the MDE that sends
the request including the operation invocation and receives the response with
the results of the operation.
Synchronous response
A message transmission returned immediately (synchronously)
as the result of an operation. Every operation has a synchronous response.
The key symbols and abbreviations used in this specification
include:
ECF 4.1
OASIS LegalXML Electronic Court Filing 4.1
MDE
Major Design Element
OASIS
Organization for the Advancement of Structured Information
Standards
SOAP
Simple Object Access Protocol
XML
eXtensible Markup Language
W3C
World Wide Web Consortium
WSDL
Web Services Description Language
WS-I
Web Services Interoperability Organization
[ECF-v4.1]
Electronic Court Filing Version 4.1. Edited by James
Cabral, Gary Graham, and Philip Baughman. Latest stage: https://docs.oasis-open.org/legalxml-courtfiling/ecf/v4.1/ecf-v4.1.html.
[MTOM]
M.
Gudgin, N Mendelsohn, M Nottingham, H Ruellan, SOAP Message Transmission
Optimization Mechanism, http://www.w3.org/TR/soap12-mtom/,
W3C Recommendation,
January 2005.
[Namespaces]
T. Bray, Namespaces in XML, http://www.w3.org/TR/xml-names/, W3C
Recommendation, December 2009.
[RFC2045]
N. Freed, Multipurpose Internet Mail Extensions (MIME)
Part One: Format of Internet Message Bodies, http://www.ietf.org/rfc/rfc2045.txt,
IETF RFC 2045, November 1996.
[RFC2046]
N. Freed, Multipurpose Internet Mail Extensions (MIME)
Part Two: Media Types, http://www.ietf.org/rfc/rfc2046,
IETF RFC 2046, November 1996.
[RFC2119]
S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, http://www.ietf.org/rfc/rfc2119,
IETF RFC 2119, March 1997.
[RFC2616]
R.
Fielding, et al., Hypertext Transfer Protocol -- HTTP/1.1, http://www.ietf.org/rfc/rfc2616, IETF RFC 2616, June 1999.
[RFC2617]
J. Franks,
P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, E. Sink,
and L. Stewart, HTTP Authentication: Basic and Digest Access Authentication,
http://www.ietf.org/rfc/rfc2617, RFC 2617, June 1999.
[RFC4122]
Leach, et al., A Universally Unique IDentifier (UUID) URN
Namespace, http://www.ietf.org/rfc/rfc4122.txt,
IETF RFC 4112, July 2005.
[Schema Part 1]
H. S.
Thompson, D. Beech. M. Maloney, N. Mendelsohn, XML Schema Part 1: Structures
Second Edition, http://www.w3.org/TR/xmlschema-1/,
W3C Recommendation,
October 28, 2004.
[Schema Part 2]
P.
Biron, A. Malhotra, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/xmlschema-2/,
W3C Recommendation, October
28, 2004.
[SOAP 1.1]
D. Box, et. al., Simple Object Access Protocol (SOAP) 1.1,
http://www.w3.org/TR/2000/NOTE-SOAP-20000508,
W3C Note, May 8, 2000.
[SOAP MTOM 1.0]
D.
Angelov, C. Ferris, A Karmarkar, C Liu, J Marsh, J Mischkinsky, A Nadalin, U Yalçınalp,
SOAP 1.1 Binding for MTOM 1.0, http://www.w3.org/Submission/soap11mtom10/, W3C Member Submission, April 05, 2006.
[WSDL 1.1]
E. Christensen, F Curbera, G Meredith, S. Weerawarana, Web
Services Description Language 1.1, http://www.w3.org/TR/wsdl,
W3C Note, March 15, 2001.
[WS-I BP1.1]
K. Ballinger, D. Ehnebuske, C. Ferris,
M. Gudgin, M. Nottingham, C. K. Liu, P. Yendluri, Basic Profile Version 1.1
(Final Material), http://www.ws-i.org/Profiles/BasicProfile-1.1-2006-04-10.html, WS-I Organization, April 10 2006.
[WS-I BSP 1.1]
M. McIntosh, M. Gudgin, K. Scott Morrison, A. Barbir, Basic
Security Profile Version 1.1 (Final Material), http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html,
WS-I Organization, January 2010.
[WS-RM 1.1]
WS-ReliableMessaging 1.1, 15 November 2004, OASIS Standard, http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1-spec-os.pdf
[XML 1.0]
T. Bray, et al., Extensible Markup Language (XML) 1.0
(Fifth Edition), http://www.w3.org/TR/xml/,
W3C Recommendation, November 2008.
[XMLENC]
D. Eastlake, J. Reagle, XML
Encryption Syntax and Processing, http://www.w3.org/TR/xmlenc-core/,
W3C Recommendation, December 2002.
[XMLSIG]
D. Eastlake., J. Reagle, D. Solo, XML-Signature
Syntax and Processing, http://www.w3.org/TR/xmldsig-core/, W3C Recommendation, June 2008.
[XOP]
M.
Gudgin, N Mendelsohn, M Nottingham, H Ruellan, XML-binary Optimized
Packaging, http://www.w3.org/TR/2005/REC-xop10-20050125/.), W3C Recommendation, January 2005.
[JRA WS-SIP]
Global Justice Reference Architecture Web Services
Service Interaction Profile 1.1, https://bja.ojp.gov/sites/g/files/xyckuh186/files/media/document/ws-sip_aug_31_version_1_1_final3.pdf,
Global Infrastructure/Standards Working Group, August 1, 2007
This section describes the design of the Web Services
Service Interaction Profile and identifies how it satisfies the requirements of
a document signature profile listed in Section 5 of the [ECF-v4.1]
specification. In addition, this profile is intended for compatibility with
the Global Justice Reference Architecture Web Services Service Interaction
Profile [JRA WS-SIP].
Each ECF 4.1 service interaction profile MUST be identified
with a unique URI which is used in the ECF 4.1 court policy to identify the
service interaction profile(s) that a given MDE supports. The ECF 4.1 Web
Services Service Interaction Profile will be identified by the following URI:
urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:WebServices-4.1
With the exception of PaymentMessage and
PaymentReceiptMessage, all ECF 4.1 messages sent via this service
interaction profile MUST include this URI in the <SendingMDEProfileCode>
element. In addition, any court supporting this service interaction profile
MUST include this URI in the <SupportedMessageProfile>
element in the CourtPolicyResponseMessage.
Each ECF 4.1 message transmission sent using this service
interaction profile MUST be encapsulated in a SOAP message over the HTTP 1.1
protocol as defined in the [WSI-I BP 1.1] and [SOAP MTOM]
specifications. Figure 1 illustrates the containment of ECF 4.1 messages and
attachments within a SOAP Message Package. For compliance with this
specification, a SOAP envelope MUST contain one or more ECF 4.1 messages and
MAY contain one or more attachments.
Figure
1. SOAP Envelope with ECF 4.1 Messages and Attachments
Each ECF message transmission sent using this service
interaction profile MUST identify the sending and receiving MDEs with
universally unique address identifiers. The identifier for each MDE will be
assigned by the organization that manages the MDE and MUST be the HyperText
Transfer Protocol (HTTP) or HTTP over Secure Socket Layer (SSL) permanent URL
for the MDE web service.
This URL MUST be the value of the location attribute of the <soap:address>
element contained within the <wsdl:service>
element that binds the MDE’s portType to a service, and that is defined in the
implementation-specific WSDL document discussed in section 1.2.4 above.
For instance, a conformant MDE ID of a web service at
courts.wa.gov using HTTP over SSL on port 8000 would be as follows:
https://courts.wa.gov:8000
Each message transmission MUST either identify the operation
being invoked or be a synchronous response to a previous request. Each
operation MUST be either a REQUIRED operation as defined in the ECF 4.1 specification
or an OPTIONAL operation identified as supported by the court through the
current machine-readable court policy. The response to a request for an
operation not supported by the court MUST be reported using the ECF 4.1 <ErrorCode> element in the core message and MAY also
include a SOAPFault in the SOAP envelope.
2.5 Request and Operation Invocation
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.
2.6
Synchronous Mode Response
Synchronous responses to requests MUST be encoded using the
MIME binding defined in Section 3 of the [SOAP MTOM 1.0] specification.
The receiving MDE MUST deliver the asynchronous response to
a request sent using the web services service interaction profile by sending
the asynchronous response to the sending MDE via the web services service
interaction profile. The response message transmission MUST conform to the
rules for message transmissions established in section 2.5 of this
specification above.
The ECF 4.1 messages MUST be encapsulated in the SOAP Body.
All other attachments MUST be included in separate MIME parts as shown in
Figure 1. The delimiters between the message and the first attachment, and
between attachments, MUST comply with the rules for delimiting MIME parts as
defined in [RFC2045].
Each MIME part that includes an attachment MUST have a
unique “Content-ID” as defined in [RFC2045] that uniquely identifies the
content within that part.
The SOAP message MAY include a digital signature applied to
the SOA Body and all MIME parts that contain messages or attachments. The
digital signature MUST be conformant with Section 8 of the [WS-I BSP 1.0]
specification which references the [XMLSIG] specification. The
algorithms defined by [XMLSIG] support
non-repudiation of the signer and signing date through a digital signature created
using the signer’s private key. Because the sender is the only one with access
to the private key and the date is included in the signature, receivers can be
reasonably assured of the signer and signing date.
The algorithms defined by [XMLSIG]
support message integrity through inclusion of a public-key-based digital
signature. Because the signing date and message hash are included in the
signature and the entire signature is computed using the sender’s private key,
the receiver can compare the hashes to verify that the message has not been
altered since it left the control of the sender on the specified date.
If the Filing Review MDE supports the filing of confidential
filings and publishes the court’s public key in court policy, messages and
attachments MAY be encrypted for filing into the court according to Section 9
of the [WS-I BSP 1.0] specification which references the [XMLENC]
specification. Because the Filing Review MDE is the only one with access to
the court’s private key, filers can be reasonably assured that only the Filing
Review MDE will be able to read the message or attachment.
This mechanism MAY be used to protect sensitive or
confidential information in a filing such as the PaymentMessage
However, this specification does NOT support the transmission of messages and
attachments encrypted with the court’s public key to other parties in the case.
Any messages and attachments transmitted to other parties MUST be either
encrypted with the party’s public key or not encrypted. This specification and
the ECF 4.1 specification do NOT define the exchange or publication of public
keys by persons or organizations other than the court.
Each MDE MAY define HTTP credentials for authentication to
access the operations supported by that MDE. If authentication is required,
the sending MDE MUST include the credentials in the request as defined in [RFC2617].
For instance, the Filing Review MDE MAY assign user ID and
password pairs to each supported Filing Assembly MDE, and require
authentication for ReviewFiling operations but not query operations. In that
case, each Filing Assembly MDE would include the user ID and password assigned
to them in each filing.
If a court expresses support for message reliability in
human-readable court policy, a sending MDE MAY include reliability extensions
to the SOAP envelope as defined in the [WS-RM 1.1] specification. An
MDE that receives a request with a SOAP envelope that includes reliability
extensions MUST include reliability extensions as defined by [WS-RM 1.1]
in the response.
WS-Reliable Messaging defines mechanisms by which messages
MAY be split into multiple pieces that are assigned sequence numbers and transmitted
separately by the RM Source (sending MDE) and reassembled into the complete
message by the RM Destination (receiving MDE).
An implementation of the web services message profile MUST
ensure that the complete SOAP message, including the SOAP envelope, any
attachments, and signatures, is available to the receiving MDE for persisting
and auditing purposes.
Implementation by each MDE of this service interaction
profile MUST be described in WSDL file that imports the service definitions
from the corresponding MDE WSDL file included with this specification.
These WSDL files import the xsd/wrappers.xsd schema file
provided in [ECF-v4.1].
An implementation conforms with the ECF 4.1 Web Services SIP
if the implementation meets the requirements identified by capitalized key
words [RFC2119] in Sections 1 and 2 and publishes a WSDL as required in Section
3.
The following individuals have participated in the creation
of this specification and are gratefully acknowledged:
Participants:
Philip Baughman, Tyler
Technologies, Inc.
James Cabral, InfoTrack US
Eric Eastman, InfoTrack US
Ryan Foley, i3-ImageSoft, LLC
Gary Graham, Arizona Supreme Court
Barbara Holmes, National Center
for State Courts
George Knecht, InfoTrack US
James McMillan, National Center for
State Courts
Enrique Othon, Tyler Technologies,
Inc.
Jim Price, Arizona Supreme Court
Brock Rogers, File &
ServeXpress
Appendix B. (Informative) Revision History
|
Revision
|
Date
|
Editor
|
Changes Made
|
|
Wd01
|
2022-06-18
|
James Cabral
|
Changes to ECF 4.01 Web Services SIP 2.01:
Split the previous WSDL into separate files for each MDE;
changed the WSDLs to use document literals, (aligning operation names and
root elements) and include a SOAP action in the binding; fixed reference to
MTOM specification.
|
|
Wd02
|
2022-08-23
|
James Cabral
Gary Graham
|
Replace references to ECF 4.0 with 4.1.
|
|
Wd03
|
2022-09-12
|
James Cabral
Gary Graham
|
Minor changes to front matter, section 2,5 and D-1.
|
|
WD04
|
2022-11-17
|
James Cabral
Gary Graham
|
Minor typo change to 2.5.
|
|
CSD01
|
2022-12-07
|
James Cabral
Gary Graham
|
Committee Specification Draft approved for public review
|
|
WD05
|
2023-05-10
|
James Cabral
Gary Graham
|
Added a README.txt file in /wsdl. Fixed broken link in
Section 1.6, defined namespaces and references to Related Work in the front
matter, citations to ECF 4.1 throughout, and names of specific messages.
Clarified references to ECF 4.1 vs SOAP messages throughout. Added guidance
in Appendix C for linking the WSDL files and wrappers.xsd. Updated Figure 1. Clarified
the user of xsd/wrappers.xsd in Section 3.
|
|
WD06
|
2023-06-23
|
James Cabral
Gary Graham
|
Removed reference to support for bulk filing in Section 1.
|
This non-normative section provides an example WSDL
implementation of this service interaction profile. This is also included in
the CourtRecordMDE-ImplementationExample.wsdl file included with this specification. Note that the
following is for illustrative purposes only.
<definitions
targetNamespace="urn:oasis:names:tc:legalxml-courtfiling:schema:wsdl:CourtRecordMDE-ImplementationExample-4.1"
xmlns:wsmp="urn:oasis:names:tc:legalxml-courtfiling:schema:wsdl:CourtRecorMDE-4.1"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<import
namespace="urn:oasis:names:tc:legalxml-courtfiling:schema:wsdl:CourtRecordMDE-4.1"
location="CourtRecordMDE.wsdl"/>
<service name="CourtRecordMDEService">
<port name="CourtRecordMDE"
binding="wsmp:CourtRecordMDESoap">
<soap:address
location="https://localhost/..."/>
</port>
</service>
</definitions>
The WSDL files provided in the /wsdl folder on this
specification import the wrappers.xsd file provided in the /xsd folder of the Core
specification. The <import> statements in the WSDL files assume that
the /xsd folder and /wsdl folder share a common parent folder. If not, it will
be necessary to update the <import> statements in the provided WSDL
files.
This non-normative section provides an example transmission
that demonstrates an operation invocation, a synchronous response, and an
asynchronous response using this service interaction profile. Note that these
examples are for illustrative purposes only.
D.1
Operation Invocation
This is an example of a request including a ReviewFiling
operation invocation.
MIME-Version:
1.0
Content-Type: Multipart/Related; boundary=boundary;
type=”application/xop+xml”;
start="Envelope"
start-info=”text/xml”
--boundary
Content-Type:application/xop+xml;
text/xml; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Content-ID: Envelope
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body
xmlns:types="http://example.com/some-namespace">
<wrappers:ReviewFiling>
<wrappers:ReviewFilingRequest>
<core:CoreFilingMessage>
…
</core:CoreFilingMessage>
<payment:PaymentMessage>
…
</payment:PaymentMessage>
</wrappers:ReviewFilingRequest>
</wrappers:ReviewFiling>
</env:Body>
</env:Envelope>
--boundary
Content-Type: application/pdf
Content-Transfer-Encoding: binary
Content-ID: Attachment1
...Lead Document...
--boundary—
Content-Type: application/pdf
Content-Transfer-Encoding: binary
Content-ID: Attachment2
...Connected Document...
--boundary--
This is an example of a MessageReceiptMessage synchronous
response.
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=boundary;
type=”application/xop+xml”;
start="Envelope"
start-info=”text/xml”
--boundary
Content-Type:application/xop+xml;
text/xml; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Content-ID: Envelope
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body
xmlns:types="http://example.com/some-namespace">
<wrappers:ReviewFilingResponse>
<message:MessageReceiptMessage>
…
</message:MessageReceiptMessage>
</wrappers:ReviewFilingResponse>
</env:Body>
</env:Envelope>
This is an example of a NotifyFilingReviewComplete
asynchronous response.
MIME-Version: 1.0
Content-Type: Multipart/Related; boundary=boundary;
type=”application/xop+xml”;
start="Envelope"
start-info=”text/xml”
--boundary
Content-Type:application/xop+xml;
text/xml; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Content-ID: Envelope
<?xml version='1.0' ?>
<env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body
xmlns:types="http://example.com/some-namespace">
<wrappers:NotifyFilingReviewComplete>
<wrappers:NotifyFilingReviewCompleteRequest>
<reviewcb:ReviewFilingCallbackMessage>
…
</reviewcb:ReviewFilingCallbackMessage>
<receipt:PaymentReceiptMessage>
…
</receipt:PaymentReceiptMessage>
</wrappers:NotifyFilingReviewCompleteRequest>
</wrappers:NotifyFilingReviewComplete>
</env:Body>
</env:Envelope>
--boundary
Content-Type: application/pdf
Content-Transfer-Encoding: binary
Content-ID: Attachment1
...Lead Document...
--boundary—
Content-Type: application/pdf
Content-Transfer-Encoding: binary
Content-ID: Attachment2
...Connected Document...
--boundary--
Copyright © OASIS Open 2023. All Rights Reserved.
All capitalized terms in the following text have the
meanings assigned to them in the OASIS Intellectual Property Rights Policy (the
"OASIS IPR Policy"). The full Policy may be
found at the OASIS website: [https://www.oasis-open.org/policies-guidelines/ipr/].
This document and translations of it may be copied and
furnished to others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied, published, and
distributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this section are included on all such
copies and derivative works. However, this document itself may not be modified
in any way, including by removing the copyright notice or references to OASIS,
except as needed for the purpose of developing any document or deliverable
produced by an OASIS Technical Committee (in which case the rules applicable to
copyrights, as set forth in the OASIS IPR Policy, must be followed) or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will
not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is
provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. OASIS AND
ITS MEMBERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THIS DOCUMENT OR ANY PART
THEREOF.
As stated in the OASIS IPR Policy, the following three
paragraphs in brackets apply to OASIS Standards Final Deliverable documents (Committee
Specifications, OASIS Standards, or Approved Errata).
[OASIS requests that any OASIS Party or any other party that
believes it has patent claims that would necessarily be infringed by
implementations of this OASIS Standards Final Deliverable, to notify OASIS TC
Administrator and provide an indication of its willingness to grant patent
licenses to such patent claims in a manner consistent with the IPR Mode of the
OASIS Technical Committee that produced this deliverable.]
[OASIS invites any party to contact the OASIS TC
Administrator if it is aware of a claim of ownership of any patent claims that
would necessarily be infringed by implementations of this OASIS Standards Final
Deliverable by a patent holder that is not willing to provide a license to such
patent claims in a manner consistent with the IPR Mode of the OASIS Technical
Committee that produced this OASIS Standards Final Deliverable. OASIS may
include such claims on its website, but disclaims any obligation to do so.]
[OASIS takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed to pertain to
the implementation or use of the technology described in this OASIS Standards
Final Deliverable or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any effort
to identify any such rights. Information on OASIS' procedures with respect to
rights in any document or deliverable produced by an OASIS Technical Committee
can be found on the OASIS website. Copies of claims of rights made available
for publication and any assurances of licenses to be made available, or the
result of an attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this OASIS Standards
Final Deliverable, can be obtained from the OASIS TC Administrator. OASIS makes
no representation that any information or list of intellectual property rights
will at any time be complete, or that any claims in such list are, in fact,
Essential Claims.]
The name "OASIS" is a trademark of OASIS, the owner and developer of this document,
and should be used only to refer to the organization and its official outputs.
OASIS welcomes reference to, and implementation and use of, documents, while
reserving the right to enforce its marks against misleading uses. Please see https://www.oasis-open.org/policies-guidelines/trademark/
for above guidance.
