[ome-devel] updates to back-end, ome-java, and shoola
Harry Hochheiser
hsh at nih.gov
Wed Apr 27 15:27:39 BST 2005
As the changes I've made to various pieces of the xml-rpc server,
ome-java , and shoola are basically complete and solid, I'd like to try
to merge them back into head. A summary of what's been done:
1) Server: Several changes have been made to the back-end, in hopes of
improving XML-RPC performance. These changes include:
- A modified Soap::Lite serializer (OME/Remote/SerializerXMLRPC.pm),
which allows for the possibility of passing appropriately blessed
objects through without trying to serialize them. This is necessary for
the support of facades that construct their own XML-RPC on the fly:
such facades can simply bless the results and have them pass through
the
serializer untouched.
- An alternative XML-RPC handler. OME/Remote/RPC2.pm and
OME/Remote/XMLRPC.pm are modified versions of
a much simpler xml-rpc package. I found that this gave better
performance for our requests, so I added this as an option. This
version also includes the ability to create hand-crafted XMLRPC
responses and have them pass through untouched.
- A revised httpd.omeds-dev.conf file, making /shoola the default
location using the new XML-RPC handler, and /shoolasoap point to
the original handler based on Soap::Lite. These two alternatives play
together quite nicely with minimal changes to Facade.pm
- Special-purpose facades for retrieving data useful for the
Chainbuilder - ChainRetrievalFacade and ModuleRetrievalFacade.
These facades retrieve data using something close to a "one
query/table" approach, and then stitch the results together, directly
into XMLPRC.
- Revision of ome-java code generation components, as described below.
2) OME-JAVA:
- Support for the new facades via new managers.
- Revision to lazy instantiation. Previously, any data returned to
XML-RPC would have all components completely instantiated with DTO
objects upon return. This would require traversing a hash of hashes and
instantiating each object as it was seen. I modified this code to make
this instantiation "lazy": top-level objects are instantiated upon
return, but any sub objects will only be instantiated upon requests,
with results cached as need be. Doing this required changing the dto
code, which meant changing the code generation facilities in the main
ome distirubtion.
- Lazy checking for null strings. Instead of traversing the entire DTO
& replacing the null marker (special string returned by xml-rpc to
indicate a null string) with an actual null string, ome-java now does
this on the retrieval of the value.
- A few miscellaneous test scripts.
3) Shoola
- Some new code in OMEDSGateway and revisions to DMSADapter to expose
the new facilties in ome-java.
I've tested all of these things via OME-SRV-TESTS, my test programs in
OME-JAVA, and informal testing via the Shoola interface.
As these changes are pretty broad, I'd obviously like to merge them
with care. My proposal is to tag everything and then merge the changes
in to ome, OME-JAVA, Shoola, and OME-SRV-TESTS.
Questions/comments/feedback appreciated. I'd be glad to provide more
detail about the changes that I've made. Advice on how best to do do
the merge would be most helpful.
-harry
More information about the ome-devel
mailing list