THE GLOBAL REFERENCE ARCHITECTURE (GRA) OASIS LEGALXML ELECTRONIC COURT

In the context of the GRA and Service-Oriented Architecture (SOA) in general, a service is the means by which one partner gains access to one or more capabilities offered by another partner. Capabilities generate real-world effects that can be as simple as sharing information or can involve performing a function as part of a complex process or changing the state of other related processes. Government organizations have numerous capabilities and a multitude of partner organizations, both inside and outside of their traditional communities. There are significant benefits for these organizations to share information and have access to each other's capabilities. Achieving interoperability among these organizations requires alignment of business and technical requirements and capabilities. In addition, it is critical to have a consistent way of specifying these requirements and capabilities and sharing them across organizational boundaries. The GRA was developed to facilitate interoperability and to assist in meeting other key requirements common in a complex government information sharing environment. In order to achieve interoperability, a consistent approach must be defined to identify, describe, and package services and their interactions in many different technical environments, across multiple government lines of business, at all levels of government, and with partner organizations.

The GRA defines a service interface as “the means for interacting with a service.” It includes specific protocols, commands, and information exchange by which actions are initiated on the service. A service interface is what a system designer or implementer (programmer) uses to design or build executable software that interacts with the service. That is, the service interface represents the “how” of the interaction. Since the service interface is the physical manifestation of the service, best practices call for service interfaces that can be described in an open-standard, machine-referenceable format (that is, a format which could be automatically processed by a computer).

A Service Specification is a formal document describing the capabilities made available through the service; the service model that defines the semantics of the service by representing its behavioral model, information model, and interactions; the policies that constrain the use of the service; and the service interfaces that provide a means to interacting with the service. A Service Specification is analogous to the software documentation of an Application Programming Interface (API). It provides stakeholders with an understanding of the structure of the service and the rules applicable to its implementation. It gives service consumers the information necessary for consuming a particular service and service providers the information necessary for implementing the service in a consistent and interoperable way.

The main components of a Service Specification are the Service Description, one or more Service Interface Descriptions, and the schemas and the samples used to implement and test the service.

A Service Description contains information about all aspects of the service that are not directly tied to the physical implementation of the service; in other words, the service interface. A Service Interface Description is a description of the physical implementation; specifically, the service interface used in a specific implementation of the service. Since a service can leverage multiple Service Interfaces, the Service Specification might contain more than one Service Interface Description.

This document is a Service Interface Description for OASIS LegalXML Electronic Court Filing 4.01. There are two ECF specification documents relevant to this service description:

OASIS Electronic Court Filing Version 4.01
OASIS Electronic Court Filing 4.0 Web Services Service Interaction Profile Version 4.01

These documents are referenced throughout this service interface description as the “ECF Core Spec” and the “ECF WS-SIP” respectively. Links to these specifications are included in Appendix A.

2.Physical Model

This service interface is an implementation of Operations defined in the OASIS LegalXML Electronic Court Filing 4.01 using web services in accordance with the GRA Web Services Service Interaction Profile, version 1.3 (GRA WS-SIP).

3.Service Interaction Requirements

Requirements	Mandatory (Yes/No)	Specification
Service Consumer Authentication	Yes	WS-I Basic Security Profile (BSP) 1.1 token (client-side digital certificate), Static IP Address via Firewall
Service Consumer Authorization	Yes	WS-I BSP 1.1 token (client-side digital certificate) OR application specific roles
Identity and Attribute Assertion Transmission	No	n/a
Service Authentication	Yes	WS-I BSP 1.1 token (server-side digital certificate) SSL OR XMLSIG
Message Nonrepudiation	No (highly recommended)	XML-SIG
Message Integrity	No (highly recommended)	XML-SIG
Message Confidentiality	No (highly recommended)	WS-I BSP 1.1 token (client-side digital certificate) with XML Encryption (of message body) OR Transport Layer Security (TLS)
Message Addressing	Yes	WS-Addressing 1.0
Reliability	No (highly recommended)	WS-RM 1.1
Transaction Support	No
Service Metadata Availability	No
Interface Description Requirements	Yes	WSDL 1.1
Service Responsiveness	Yes	Determined by implementation. As defined by the specific Service-Level Agreement (SLA).

4.Interface Description Requirements

The service will comply with the GRA Web Services Service Interaction Profile, version 1.3.

5.Message Exchange Patterns

The table below provides information regarding the message exchange patterns under which each of the service actions can be implemented.

Action Name	Message Exchange Patterns
GetPolicy	Request-Reply
GetServiceInformation	Request-Reply
GetFeesCalculation	Request-Reply
ReviewFiling	Request-Reply
ServeFiling	Request-Reply
RecordFiling	Request-Reply
NotifyDocketingComplete	Request-Reply
NotifyFilingReviewComplete	Request-Reply
GetFilingList	Request-Reply
GetFilingStatus	Request-Reply
GetCaseList	Request-Reply
GetCase	Request-Reply
GetDocument	Request-Reply

6.Message Definition Mechanisms

The service will comply with the message definition mechanisms identified in the GRA Web Services Service Interaction Profile, version 1.3.

7.Policies and Contracts

7.1 Automated Service Policies

The web services description language (WSDL) for this service defines security and addressing policies using WS-Policy 1.2.

7.2 Automated Service Contracts

The web services description language (WSDL) file for this service serves as a contract for interaction with this service.

7.3 Nonautomated Service Policies and Contracts

No non-automated service policies and contracts have been identified at this time.

8.Umbrella Agreements

Not applicable

9.Security

This service must adhere to 1] any security rules/policies imposed through Court Policy (as defined in the ECF Core Spec), and 2] security requirements relating to authentication, authorization, non-repudiation and message integrity as called for in the ECF WS-SIP and the Service Interaction Requirements section above.

10.Privacy

This service must adhere to 1) any privacy rules/policies imposed through Court Policy (as defined in the ECF Core Spec), and 2) requirements relating to message confidentiality as called for in the ECF WS-SIP and the Service Interaction Requirements section above.

11.Service Testing

Courts may (or may require their solution provider to) obtain certification of conformance with ECF specifications through the IJIS Institute’s Springboard Program. IJIS has developed an ECF Test Harness to facilitate conformance testing of ECF messages. This is not required. Any service testing requirements should be determined for each implementation.

Appendix A — References

OASIS Electronic Court Filing Version 4.01 Errata 01. 14 July 2014. OASIS Approved Errata (ECF Core Spec)	http://docs.oasis-open.org/legalxml-courtfiling/specs/ecf/v4.01/ecf-v4.01-spec/errata01/os/ Note, a copy of this specification is also provided in the “artifacts/various artifacts” folder of the Service Specification Package for this service.
OASIS Legal XML Electronic Court Filing 4.0 Web Services Service Interaction Profile 2.01 (ECF WS-SIP)	http://docs.oasis-open.org/legalxml-courtfiling/specs/ecf/v4.0/ecf-v4.0-webservices-spec/ Note, a copy of this specification is also provided in the “artifacts/various artifacts” folder of the Service Specification Package for this service.
GRA Web Services Service Interaction Profile, version 1.3 (GRA WS-SIP)	https://it.ojp.gov/gist/56/Global-Reference-Architecture--GRA--Web-Services-Service-Interaction-Profile-Version-1-3
WS-I Basic Security Profile 1.1 (BSP)	http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html
XML Signature (XMLSIG)	http://www.w3.org/TR/xmldsig-core/
Web Services Addressing 1.0 (WS-Addressing)	http://www.w3.org/TR/ws-addr-core/
Web Services Reliable Messaging 1.1 (WS-RM)	http://docs.oasis-open.org/ws-rx/wsrm/200702/wsrm-1.1-spec-os-01.pdf
Web Services Description Language 1.1 (WSDL)	http://www.w3.org/TR/wsdl
IJIS Institute Springboard Certification Program	https://ijis.site-ym.com/?page=Springboard

Appendix B — Glossary

ECF 4.01	OASIS LegalXML Electronic Court Filing 4.0
MDE	Major Design Element
OASIS	Organization for the Advancement of Structured Information Standards
SOAP	Simple Object Access Protocol
XML	eXtensible Markup Language
WSDL	Web Services Description Language
WS-I	Web Services Interoperability Organization

Appendix C — Document History

Date	Version	Editor	Change
04/14/2015	1.0.0	J. Harris
05/19/2015	1.0.1	J. Harris	Updates to incorporate more references to the ECF 4.01 Core Specification and the ECF WS-SIP 2.01 document.

1 EJERCICIO DE LATÍN (PROCEDIMIENTOS) (GLOBAL) CALIF NOMBRE
1 R3 CUSTOMIZING GUIA DE IMPLEMENTACIÓN PARAMETRIZACIONES GLOBALES
11 EISENSTADT • CONTEMPORARY GLOBALIZATION AND NEW CIVILIZATIONAL FORMATIONS

Tags: (gra) oasis, legalxml, (gra), architecture, court, reference, electronic, global, oasis