legalxml-courtfiling — archive

Re: [legalxml-courtfiling] EFiling Process Models Subcommittee

From: Dallas Powell
To: [email protected]
Date: Tue, 31 Dec 2002 19:53:00 -0000

MHonArc v2.5.2 -->

legalxml-courtfiling message

Subject: Re: [legalxml-courtfiling] EFiling Process Models Subcommittee

From: Dallas Powell <[email protected]>
To: [email protected]
Date: Tue, 31 Dec 2002 17:51:20 -0700

Allen,

You wrote
> I'm still having trouble with one generic EFM/OXCI PUSHing the
> data/images into all the various CMS/DMSs?......

From our experience we find that a process between the EFM and the CMS or
other applications needs to exist and act as a controller of events.  In our
implementations the EFM includes this process.  In a business model where
the EFM, CMS, and the DMS are all controlled by separate vendors, yet all
applications have access to a common network, there needs to exist a state
machine that can define the order of events, and this process must notify
the other applications when it is their turn to do something.  For example
in one implementation the order of events that happens once the submission
is received includes:


1)authenticate source (default part of EFM)
2)authenticate content (default part of EFM)
3)respond with first notice of success (default part of message posted on IP
address)
4)authenticate signatures (special servlet that understands methods and
collects responses to Certificate Authority)
5)respond with second notice of success (default part of EFM)
6)notify CMS of new submission ( special servlet that understands
communication method and collects response)
7)collect fees (special servlet that understands communication method and
collects response)
8)notify CMS of payment or failure (special servlet that understands
communication method and collects response)
9)notify DMS and load submission (special servlet that understands
communication method and collects response)
10)collect all success responses and generate receipt (special servlet)
11)digitally sign receipt or failure notice and respond. (default part of
EFM)

The communications methods between the CMS, the DMS, the credit card
collection, and the financial reporting process were all different.  Non of
the legacy applications were in a position to create a pulling process.  We
needed to activate each process at the appropriate time.

In talking to other courts we find that they do not agree with this order of
processes, which is fine.  Some courts require the payment process before a
case number is issued.  So from our point of view the communications between
the EFM, the CMS, the DMS, the Collections, the finance reports, and any
other process, needs to be configurable such that order can be rearranged.
This means to us a single process needs to control when to activate other
processes.  This single process also needs to be able to accept the response
from each application so that failure and success can control whether the
next step can take place or not.

The interoperability issues effected here are the communication layer
between the EFSP and the EFM.  If the EFSP only accepts a single response
from posting a submission to an EFM then the EFSP must either wait some
length of time for all processes to complete, or accept multiple responses
for each appropriate process, assuming that the EFSP is interested in
knowing if any failures took place.  I think that the issues of
communications between the EFSP and the EFM are of great importance, but the
standardization of the state machine is not.  The reason it is discussed
here is because it effects the communication between the EFSP and the EFM.

As for creating a common standard for such a state machine, the issues I see
there are dependent on the framework the server is running on.  For example,
we use an EJB server, but our state machine is based on a configuration file
and small servlets that the EFM invokes.  This would obviously not work on a
.NET environment.  The configuration file could be standardized across a EJB
server and a .NET environment which could identify the controlling order of
processes, the number of responses the EFM will give to the EFSP, and
possibly error messages.

Now that I stood on a soap box and expressed my desire to support Dwight's
process model and interoperability issues, here are the processes that were
possibly identified here.

1)EFM : receives the submission, creates temp storage for the submission,
authenticates source that sent the submission, parses the envelope to make
sure the content is valid, checks digital signatures against documents,
launches the control processor
2)Control processor: defines the order of communication to each legacy
process whatever that might be.  It can either sit between the EFM and all
legacy systems or exist within the EFM.  It reads a configuration file that
identifies the order of events that must take place to complete the actions
indicated by the submission.  This could include an interrupt condition
where a court clerk manually reviews various states.
3)Legacy communication process: defines how to communicate to a specific
legacy application, defines what to communicate to a legacy application, and
understands and can interpret the response.
4)Communication process between EFM and EFSP: Each EFM needs to publish
whether it will response to the EFSP for each submission with only one
response or multiple responses and what they are.
5)receipt generation process: this process takes all responses and creates a
receipt.  The receipt is an XML document which can be printed as well as
parsed so that the EFSP that sent the original request can automatically
update the application that sent the receipt with the new case number, the
case title (because the CMS names the case), the judge assigned, the time
and date docketed, the authorization code received from the electronic
payment process, and any other information of value to the submission.
5)EFSP: is not described here but is something that send a valid submission


The interoperability levels potentially effected are:
1)Communications - multiple responses or single responses
2)Communications - is the system support two-way automation or one-way
automation -meaning is the response just a success response from the web
server that the posting was received, or can the response include an actual
document so the sending party can act upon the response.
3) Basic validation - There is an issue with the embedding credit card
information into a CourtFiling 1.1 envelope.  Some courts have found that
they need to keep the envelope which exposes live credit card information to
potentially many court clerks and others who have access to the records.
This is an issue that was discussed in the Las Vegas meeting and a more
formal description of how this can be addressed will be sent later.
4) Security - authentication of source that sent the submission

Dallas