legalxml-courtfiling — archive

RE: [legalxml-courtfiling] EFiling Process Models Subcommittee

From: Allen Jensen
To: [email protected]
Date: Fri, 27 Dec 2002 15:06:00 -0000

MHonArc v2.5.2 -->

legalxml-courtfiling message

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

From: Allen Jensen <[email protected]>
To: [email protected], [email protected]
Date: Fri, 27 Dec 2002 12:02:49 -0800

Thanks.

Paragraph1 - That's why our EFM is 2 parts - EFM1 outside the firewall
to receive the SOAP packets from the EFSP, and EFM2 on the inside of the
firewall to PULL the data inside.  EFM1 cannot do anything but queue the
filings, while EFM2 PULLs in every 30 seconds.  All filings are
encrypted before being sent from EFSP to EFM1 to prevent any access
while queued on the outside of the firewall.  Also, the IP to EFM1 is
blocked by all Internet access except the authorized EFSP sending to
it.

Paragraph3 - Our EFM currently is an SQL server that houses all the
pertinent items from the filing.  I am hoping to enable each CMS Admin
to be able to just query for new filings, and pull them into their
system.

All depending on all these other initiatives and standards of course
:-)



Allen Jensen
Orange County Superior Court
Internet Development / EFiling
949.472.6946



>>> John McClure <[email protected]> 12/27/02 11:58AM >>>
Allen,
A few thoughts.

Although I am not an EF maven, your question of pushing and pulling is
generic.
I think that a critically important function of the architecture must
include
minimization of DOS attacks (Denial of Service) on a judicial system.
Pushing
filings to an EFM opens the door to DOS attacks. I'd suggest a hybrid
approach,
in which a filing REQUEST is pushed to the EFM, and the EFM then pulls
the
filing into its repository from the URI specified in the filing
request. I don't
know whether this represents a refinement or just a restatement of the
current
LegalXML architecture, but I'm sure that I would agree that eliminating
EFM for
a direct EFSP to CMS/DMS data flow is not a useful simplification of
the
architecture. In other words, I see the primary function of the EFM to
be
fielding the filing requests, checking its technical parameters and
payment/case
information, and then performing the pull. An email is then sent to the
filer as
confirmation of the pull completing successfully, or of an error
occurring. An
important related business issue I think concerns whether filing
deadlines would
be relative to receipt of the filing request, rather than to the pull
performed
by the EFM.

I do support John's initiative to orient EFM implementations to be
formal web
services, using SOAP as (one of) its underlying exchange protocols. At
the same
time, I think it's important also to include an SMTP processor in the
EFM for
email-based filings -- the EFM's job in this case would be to convert
email with
its attached filing into a web service request. This would allow a
court to
advertise both filing methods, catering to the varying levels of
technical
sophistication of filers. Email based filings is a good strategy
against someone
wanting to initiate a DOS attack against a court system but, then
again, the
business rules for emailed filings may need to be similarly addressed
as for the
client/server model discussed above. IMO, an email-based filing process
should
have priority over a web service implementation, occupying our
attention until
WSDL becomes fully mature.

With respect to the interface between the EFM and the CMS, another
cycle of the
same loosely-coupled email based architecture or more tightly coupled
web
service could occur, one in which the CMS is notified of the
availability of a
filing to be processed by the CMS. The CMS then pulls that filing from
the EFM
repository, with an email notification to the EFM when the filing has
been
pulled by the CMS. The notification includes not only the URI for the
filing
itself, but also the URI for the Court Policy document that rules the
transfer
process. The recipient CMS can access both documents using standard
XSL.

In no event should an API be used to (too tightly) link these systems.
We don't
need to standardize on CORBA or a custom HTTP negotiating mechanism
given
industry consensus around WSDL. An API to a court policy document I am
concerned
jeopardizes adoption of a standard for the XML encoding of that
document. Ditto
for filing APIs.

John McClure

>