[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [legalxml-courtfiling] EFiling Process Models Subcommittee
Seems like a lot of this thread is dealing with implementation and not process. I think Allen's description of the process is reasonable within the context of security and DOS. The *process* should be described in terms of steps or tasks, not bounded by the technology - existing or proposed. As several others have pointed out, there are several technology alternatives. gary -----Original Message----- From: Allen Jensen [mailto:ajensen@occourts.org] Sent: Friday, December 27, 2002 2:03 PM To: jmcclure@hypergrove.com; legalxml-courtfiling@lists.oasis-open.org Subject: RE: [legalxml-courtfiling] EFiling Process Models Subcommittee 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 <jmcclure@hypergrove.com> 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 >-----Original Message----- >From: Allen Jensen [mailto:ajensen@occourts.org] >Sent: Friday, December 27, 2002 8:18 AM >To: drdaniels@bearingpoint.net; Tom.Clarke@courts.wa.gov; >jmessing@law-on-line.com; Donald.Bergeron@lexisnexis.com; >legalxml-courtfiling@lists.oasis-open.org >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> > ---------------------------------------------------------------- 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> ****************************************************************************** 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. ******************************************************************************
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC