[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