[Openefm-development] Re: OpenEFM question

[Jason V. C. <ja...@co...>]

Quoth Jeremiah Jahn, on Tue, 01 Mar 2005 14:27:54 -0600:

> I had some difficulty getting on the mailing list, So I'll just ask
> directly.

What trouble did you have?  We want to stimulate this list a bit, so we
would help you get onto it.

> Do you have any idea what the major EFP players want to use as far as
> a SOAP API? Do you have any who are connecting to OpenEFM yet?

Here's some text from my superior in regard to that:

"The EFP players . . . tend to use what ever they have to 
for any project.  As far as what they want to use, some want minimal 
transactions and some want complex, ubl based transactions.  The 
OpenEFM is currently used in various production environments, but we 
have not been directly involved with all of them.  Most of these 
projects involve only a courts IT department and no 'big players'.  
Currently it is used in Nebraska and Guam."

> Is it true that I can just point a transceiver to our SOAP
> CMS-interface and implement add Case/Party/Document and call it a day?

We have a SOAP transceiver that includes an OpenEFM-side component and
also an optional CMS-side component.  For the EFM, you just need to
specify the right transceiver in the config' file.  For the CMS, you
might deploy the CMS-side component in (or as) a Java Web app',
specifying in your "web.xml" a servlet that will receive the SOAP/HTTP
calls from OpenEFM and send back confirmation messages, etc.  The last
mile (the hardest), is writing to our CMS-side API:  which is OpenEFM's
CMSAdapter interface.

However, if you have already developed a SOAP transceiver that conforms
to one of OpenEFM's SOAP interfaces, then yes, pointing the EFM thither
should work, and there's no need to implement anything else.  Note that
these interfaces usually involve an asynchronous callback message from
the CMS transceiver to the OpenEFM.

We also have an RMI connection implementation, which works much like the
SOAP interface.

> Does OpenEFM handle more than just LegalXML? The code looks like it
> does, but I haven't managed to find where the decesion is made as to
> what kind of trans port is being used. 2GEFS/LXML/whatever...

OpenEFM is designed to be integrated with a variety of systems.  It
currently supports versions of the 2GEFS spec' and the OXCI interface of
last year (which never actually solidified).  Other interfaces can be
implemented as well.  Which one is determined at runtime based on
OpenEFM's main configuration file, "config.xml".

> Why does the LxmlResponse have both code/text and content? Is it your
> intention that the CMS modify the the sent LXML to include the
> confirmation header or the the EFP just use the error codes that you
> sent back? There seems to be a little redundancy here. I've seen the

It was the OXCI group's on-again, off-again idea, in fact.  (We prefer
simplicity.)  Last year, LxmlResponse went back and forth between
carrying a complete XML document to just carrying a response code and
message, depending on what sort of response it encapsulated.  So we have
both for flexibility.  I believe that in the current OXCI
implementation, the responseText field is used for synchronous
"acknowledgement" messages, and the content field stores a complete
filing confirmation XML message when the CMS sends one.  This changed a
lot during our work with the OXCI group, because they simply couldn't
pin down their SOAP interface.  So what you see is a result of a very
volatile set of requirements.  If the whole 'transport' package seems
too complex, it's because I've been trying to make it as flexible as
possible.

Hope that's helpful.

--Jason Van Cleve
counterclaim