Very interesting. On the surface this sounds similar to some of Steve Zeck's
initial work
in making a Perl interface to GT.M. In the first level he defined a Perl module
for
implementing MUMPS data objects. These data objects represent MUMPS globals and
have
methods corresponding to all of the standard functions for working with MUMPS
data. In the
second level he has begun defining higher level objects that correspond to the
data
records from the fileman defined data structures.
I haven't seen Zeck's work. But, one thing I decided early on was to
start with a very simple interface - from the bottom. We've already got
the top-down design elements (object models, table models, VistA data
models, etc...) handled, really. What I've focused on was a very simple
bottom-up approach: send a string to the server over a socket and get a
response back.
I think there is quite a bit of common work to be done in analyzing the
functionality and
devising a high level interface to it regardless of your approach and
technology. For
instance, a listing of what data elements are involved in different reports,
interfaces,
and data entry forms, how those relate to functional areas and menus, and how
they map to
data elements from other systems.
Correct - OpenEMed's design takes this approach with respect to
interfaces. This is what CORBA and the CORBAMED standards give us. The
other tasks - identifying discrete data elements/reports/etc... has
received a lot of attention. There's more documentation on that then
anyone has time to read.
Also, some of the challenges anyone faces in laying an object model on
top of a mumps data store are:
* handling the fact that the MUMPS data store is a b-tree structure:
with all the "SQLesque" table design structures out there - including
those in VistA (e.g. fileman) - there's some extra work in mapping
things properly. The irony is that the Greystone data store b-tree is a
natural fit for object-oriented data models, but storing data like that
wasn't a design goal of the original VistA developers. Fileman was
created, rather, to give developers and users kind of a "file systems
view" of VistA. It's easier to export VistA data into flat files right
now than to build up a proper object heirarchy as a result. ESI Objects
addresses this nicely, but I'm not at the point yet where I can spend
the time to take advantage of it.
* limitations mumps places on data storage: mumps references need to be
created properly, and mumps commands have a limit of 255 characters, etc...
Documentation and discussion of the difficulties and complications and other
substantial
findings could be helpful to others considering reverse engineering or
re-engineering with
other languages or approaches.
I don't get the impression that there's an interest by the RPC Broker
creators to have it reverse engineered. it's pretty obvious at the lack
of documentation, isn't it?
It's a valid design choice on their part - just use the Delphi
components. In my case my customers haven't requested that I use
Windows based Delphi components, and it's not an option to build a Java
applicaiton around them anyway.
ESI objects is a valid choice in lieu of Delphi components - if you have
the time to work with that product.
src/tools/gov/lanl/Database/GTM for OEMEDSRV.m).
I looked at it a little. I think I found some minor errors where you are
converting search
filter operators to MUMPS in function convertOperator
http://cvs.sourceforge.net/viewcvs.py/openmed/OpenEMed/src/tools/gov/lanl/Database/GTMSearchFilter.java?rev=1.4&view=auto
">=" (greater_than_or_equal_to) is not a standard MUMPS operator (at least in
GT.M 4.4).
The equivalent is "'<" (not_less_than)
"<=" (less_than_or_equal_to) is not MUMPS. The equivalent is "'>"
(not_greater_than)
An equivalent for "in" might be "[" (contains), except with the operand order
reversed.
How far have you gotten in generating MUMPS search conditions?
This is a very early release of the code - perhaps too early. I'm
working through the issues you mention issues and many others you'll find.
One challenge here is that OpenEMed is designed to work well with SQL
like language structures such as the "LIKE" command. I have some more
work to do to get my code to function under the OpenEMed design model as
it should.
Richard Schilling
Cognition Group, Inc.
Seattle, WA
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
