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 >
