Re: [legalxml-courtfiling] EFiling Process Models Subcommittee

[Dallas Powell <dpowell@tybera.com>]

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


----- Original Message -----
From: "Allen Jensen" <ajensen@occourts.org>
To: <drdaniels@bearingpoint.net>; <Tom.Clarke@courts.wa.gov>;
<jmessing@law-on-line.com>; <Donald.Bergeron@lexisnexis.com>;
<legalxml-courtfiling@lists.oasis-open.org>
Sent: Friday, December 27, 2002 9:18 AM
Subject: RE: [legalxml-courtfiling] EFiling Process Models Subcommittee


> I'm still having trouble with one generic EFM/OXCI PUSHing the
> data/images into all the various CMS/DMSs?  Since every CMS/DMS
> implementation is different, wouldn't it be more likely to have the
> CMS/DMSs PULL the data from EFM?
>
>
>
> Allen Jensen
> Orange County Superior Court
> Internet Development / EFiling
> 949.472.6946
>
>
>
> >>> John Messing <jmessing@law-on-line.com> 12/27/02 08:13AM >>>
> Then in the same spirit I would like to pose a question to the
> consortium whether OXCI can do anything more or better than XSLT and
> ordinary web services such asp.net together. If not, and the latter are
> standardarized and freely available, why not consider using them
> instead?
>
> ---------- Original Message ----------------------------------
> From: Tom.Clarke@courts.wa.gov
> Date:  Fri, 27 Dec 2002 08:02:21 -0800
>
> >Well, I hesitate to speak for the OXCI consortium when some of these
> >architectural decisions have not been finalized by either the OXCI
> >Consortium or Legal XML.  OXCI is intended to be an EFM reference
> >implementation.  As such, it does need API's for interacting with an
> EFSP,
> >Court Policy, Court CDC, a CMS and a DMS.
> >
> >It also assumes the existence of a CMS/DMS-unique Adapter that stands
> >between the EFM and the CMS/DMS.  The Adapter handles some of the
> >translation duties, since the OXCI group suspects that to do otherwise
> would
> >put an unrealistic burden on the EFM, Court Policy and Court CDC.
> Some
> >vendors suggested that might be the case during discussion of the last
> Court
> >Policy version.
> >
> >I would like to refer any additional questions about OXCI to Greg
> Arnold,
> >who leads the OXCI Consortium.
> >
> >-----Original Message-----
> >From: John Messing [mailto:jmessing@comcast.net]
> >Sent: Thursday, December 26, 2002 5:40 PM
> >To: Tom.Clarke@courts.wa.gov; Bergeron, Donald L. (LNG); John
> Messing;
> >Daniels, Dwight (BearingPoint);
> legalxml-courtfiling@lists.oasis-open.org
> >Subject: Re: [legalxml-courtfiling] EFiling Process Models
> Subcommittee
> >
> >I understood that OXCI was a way of parsing the xml and sending it to
> the
> >CMS-API for translation into methods and properties that the legacy
> CMS
> >systems could use. Are you saying that OXCI does otherwise?
> >
> >----- Original Message -----
> >From: <Tom.Clarke@courts.wa.gov>
> >To: <Donald.Bergeron@lexisnexis.com>; <jmessing@law-on-line.com>;
> ><drdaniels@bearingpoint.net>;
> <legalxml-courtfiling@lists.oasis-open.org>
> >Sent: Monday, December 23, 2002 10:48 AM
> >Subject: RE: [legalxml-courtfiling] EFiling Process Models
> Subcommittee
> >
> >
> >> I just want to respond to John's comment about OXCI.  OXCI is
> looking
> >> closely at using a web services approach to all API's and reusing
> >> appropriate parts of Version 3.0 of the Justice XML Data Dictionary
> >schema.
> >> In any case, it is likely that schema will be used instead of DTD's
> and
> >the
> >> standard web services messaging protocol (either SOAP 1.2 or ebXML
> >Messaging
> >> 2.0) will be used.  The California 2GEFS project is the one not
> planning
> >to
> >> use web services.
> >>
> >> -----Original Message-----
> >> From: Bergeron, Donald L. (LNG-DAY)
> >[mailto:Donald.Bergeron@lexisnexis.com]
> >> Sent: Monday, December 23, 2002 6:35 AM
> >> To: 'John Messing'; Bergeron, Donald L. (LNG-DAY); 'Daniels, Dwight
> >> (BearingPoint)'; CourtFiling List (E-mail)
> >> Subject: RE: [legalxml-courtfiling] EFiling Process Models
> Subcommittee
> >>
> >> These are possible effects of effort described. This will occur when
> we
> >look
> >> at the functions supported by these technologies and how they apply
> to a
> >> better defined set of Models required by the community.
> >>
> >>
> >> Regards,
> >>
> >> Don
> >>
> >> Donald L. Bergeron
> >> Data & Systems Architect
> >> donald.bergeron@lexisnexis.com
> >>
> >> 937-865-1276 O
> >> 937-748-2775 H
> >> 937-672-7781 M
> >>
> >>
> >> -----Original Message-----
> >> From: John Messing [mailto:jmessing@comcast.net]
> >> Sent: Monday, December 23, 2002 9:01 AM
> >> To: Bergeron, Donald L. (LNG-DAY); 'Daniels, Dwight
> (BearingPoint)';
> >> CourtFiling List (E-mail); EFiling Process List (E-mail)
> >> Cc: Bergeron, Donald L. (LNG-DAY)
> >> Subject: Re: [legalxml-courtfiling] EFiling Process Models
> Subcommittee
> >>
> >>
> >> I think we need to look at
> >>
> >> 1. web services as a replacement for CMS-API and OXCI, which are
> now
> >> outdated technologies in my opinion, and focus on exposing the
> methods of
> >> the case management systems to the web directly through XML web
> services;
> >> and
> >>
> >> 2. look to Schemas and RDF solutions being developed in parallel so
> as to
> >> stay abreast of the technological curve.
> >>
> >>
> >> ----- Original Message -----
> >> From: "Bergeron, Donald L. (LNG-DAY)"
> <Donald.Bergeron@lexisnexis.com>
> >> To: "'Daniels, Dwight (BearingPoint)'"
> <drdaniels@bearingpoint.net>;
> >> "CourtFiling List (E-mail)"
> <legalxml-courtfiling@lists.oasis-open.org>;
> >> "EFiling Process List (E-mail)"
> >> <legalxml-courtfiling-processmodels@lists.oasis-open.org>
> >> Cc: "Bergeron, Donald L. (LNG-DAY)"
> <Donald.Bergeron@lexisnexis.com>
> >> Sent: Monday, December 23, 2002 6:51 AM
> >> Subject: RE: [legalxml-courtfiling] EFiling Process Models
> Subcommittee
> >>
> >>
> >> > I will join in this effort and urge the members of the community
> to
> >> actively
> >> > participate. Purely technical nor purely court policies and
> procedures
> >> exist
> >> > in a vacuum.  Business Policy(fee charging, fee payment...),
> Security
> >> > Policy(trusted partners, arms length...) and Related
> Telecommunication
> >> > Policy all have different Models from which the courts may choose.
> We
> >must
> >> > as a community look at the interactions between these models and
> their
> >> > implications.
> >> >
> >> > Understanding these will prepare us for doing a sound set of
> >requirements
> >> > for Court Filing Blue and the specification that result.
> >> >
> >> >
> >> > Regards,
> >> >
> >> > Don
> >> >
> >> > Donald L. Bergeron
> >> > Data & Systems Architect
> >> > donald.bergeron@lexisnexis.com
> >> >
> >> > 937-865-1276 O
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: Daniels, Dwight (BearingPoint)
> [mailto:drdaniels@bearingpoint.net]
> >> > Sent: Friday, December 20, 2002 3:54 PM
> >> > To: CourtFiling List (E-mail); EFiling Process List (E-mail)
> >> > Subject: [legalxml-courtfiling] EFiling Process Models
> Subcommittee
> >> >
> >> >
> >> > As you have probably seen from John Greacen's summary of the Las
> Vegas
> >> > meeting, the CMS-API subcommittee has undergone a transformation.
> It is
> >> now
> >> > the EFiling Process Models subcommittee. I am tasked with
> composing the
> >> > first draft of the statement of work for the subcommittee and
> >> disseminating
> >> > it prior to the January 6th conference call, but I wanted to take
> this
> >> > opportunity to give you an idea of what the committee's objectives
> are
> >and
> >> > to encourge participation among those interested.
> >> >
> >> > In a nutshell, the committee felt that we needed to get a better
> >> > understanding of the various conceptual process models for
> electronic
> >> filing
> >> > that exist in the community, document those models and compare
> them for
> >> > commonalities and differences. Through this process we will be
> seeking
> >to
> >> > identify the intersection points among the various models and to
> >evaluate
> >> > those points as candidates for APIs to be defined in subsequent
> work.
> >> >
> >> > The focus of this work is not technical. It is process oriented.
> As
> >such,
> >> > the input and assistance of non-technical practitioners is
> crucial. The
> >> more
> >> > we get, the more likely we will be to succeed. I therefore
> strongly
> >> encourge
> >> > those who have a vision for what the business process flow (or
> flows) of
> >> > electronic filing should look like to join us in this effort.
> >> >
> >> > Dwight R. Daniels | Manager | BearingPoint | Costa Mesa, CA
> >> > Office +1.714.957.4835 | Project +1.714.568.5697 | Mobile
> >+1.805.990.9994
> >> > www.bearingpoint.com
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
>
>***************************************************************************
*
> >> > **
> >> > The information in this email is confidential and may be legally
> >> > privileged.  Access to this email by anyone other than the
> >> > intended addressee is unauthorized.  If you are not the intended
> >> > recipient of this message, any review, disclosure, copying,
> >> > distribution, retention, or any action taken or omitted to be
> taken
> >> > in reliance on it is prohibited and may be unlawful.  If you are
> not
> >> > the intended recipient, please reply to or forward a copy of this
> >> > message to the sender and delete the message, any attachments,
> >> > and any copies thereof from your system.
> >> >
> >>
>
>***************************************************************************
*
> >> > **
> >> >
> >> >
> >> > ----------------------------------------------------------------
> >> > To subscribe or unsubscribe from this elist use the subscription
> >> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >> >
> >> > ----------------------------------------------------------------
> >> > To subscribe or unsubscribe from this elist use the subscription
> >> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >> >
> >>
> >> ----------------------------------------------------------------
> >> To subscribe or unsubscribe from this elist use the subscription
> >> manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>
> >> ----------------------------------------------------------------
> >> To subscribe or unsubscribe from this elist use the subscription
> >> manager: <http://lists.oasis-open.org/ob/adm.pl>
> >>
> >
> >
> >----------------------------------------------------------------
> >To subscribe or unsubscribe from this elist use the subscription
> >manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>