Re: [legalxml-courtfiling] CR MDE. Push/Pull modes.

[Serguei Mysko <sergueim@intresys.com>]

Jim,

I agree with your remarks on the process model.
I am not saying the pull mode has advantages.
Rather the push mode does not work in some cases.

Here are the cases we've heard so far:
1. Poor Inet connection
A Court is on a poor Inet connection.
We were told about modem (56 Kbits/sec) connections.
Typically, such Court would have low traffic expectations - few cases to deal with.

Setting up a listening service (web service as one) does not look like a good solution.
Periodic querying (pulling) however might do the trick.


2. Cannot deal with documents
A Court is willing to receive and process RecordFilingRequest XML messages.
It has no provision to keep and manage filing documents.
Even if we may find a way to handle GetDoc, GetCase requests at some other EFM component, the Court also wants to be able getting the documents.
One option would be to tell the Court to act as an EFSP; another one is for EFM to expose something like OASIS CMIS interface.
Both options would deviate from ECF model.


3. Have my software already in place
This one more like a hack.
A Court has its own software to process filings.
It has no resources to develop ECF compliant software. Yet, it wants to stay along with other state Courts in their effort to standardize to ECF.
A Court might be willing to develop a client to pull RecordFilingRequest, delegating the other calls to elsewhere.

Take a look at this use case from the perspective of an EFM, compliant with ECF, serving multiple such Courts.
How would EFM manage it?
One way is to have multiple adapters per Court - quite a work to do with 20-50 Courts.
Another one - is to allow them to pull.

To sum-up.
Intresys does not promote the pull mode.
What we say is:
- the push, as in ECF spec, does not work in some cases.
We are looking for other solutions as well.
At this stage - just sharing. 


-
Serguei M.
Intresys





 

On 7/31/2012 8:43 AM, James E Cabral wrote:

Serguei,

While it is left to the SIP to define the specific transport protocols, Section 3.0 of the core specification defines a specific process model including the direction of each ECF messages and whether it is either synchronous or asynchronous.  I believe that changing the direction of a message (from a push to a pull) would require a change to the process model in the core specification even if it did not necessarily require changes to the message schemas.   I suggest that we consider this issue for ECF 4.1.

Changing from a push to a pull transfers some of the complexity from the receiving to the sending MDE but it typically introduces a polling delay.  Can you summarize the advantages of this approach from the court perspective?

  Thanks,

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.

-----Original Message-----
From: legalxml-courtfiling@lists.oasis-open.org [mailto:legalxml-courtfiling@lists.oasis-open.org] On Behalf Of Serguei Mysko
Sent: Tuesday, July 31, 2012 2:45 AM
To: legalxml-courtfiling@lists.oasis-open.org
Subject: [legalxml-courtfiling] CR MDE. Push/Pull modes.


Dear Colleagues,

Looking for your ideas/comments.

The problem:
- CR MDE. Should we add a 'pull' mode?

ECF spec as of today assumes a 'push' mode only with its CR MDE.
A Court willing to follow ECF spec has to have a CR MDE component that would 'push' a filing into it.

Folks at the trenches however mentioned to us (number of times) a 'pull' 
mode as an option.
That is, instead of having a CR MDE service client to 'push' a filing into 'our Court System', we'd prefer to poll (or else) a service to effectively 'pull' a filing *whenever we want*.

Why not?
Currently CR MDE:
- is a service client to submit a RecordFilingRequest (RFR);
- it is a consumer for NotifyDocketingComplete.
The majors ones, roughly.

Could it be reversed as well, in addition to, to allow the querying?
So that one could query the RFRs available?
Why not?
It should not affect the Core spec; just the SIP, the WebServices one and only.


Your thoughts/ideas/comments are appreciated.

Thank you.
-
Serguei M.
Intresys




---------------------------------------------------------------------
To unsubscribe, e-mail: legalxml-courtfiling-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: legalxml-courtfiling-help@lists.oasis-open.org