[tcljava-user] Potential Uses of Tclblend (maybe a bit OT?)
Brought to you by:
mdejong
From: <ni...@ma...> - 2007-03-13 12:55:42
|
Hello all, I'm a beginning tclblend user and would like to thank all for making and maintaining this package. I'm currently using Mo's win binary and it looks good ;-) The main reason I'm looking into tclblend is for integration of an existing tclhttpd application with additional functionality that will most likely be coded by other developers in java. I've been asked to recommend on how the 2 apps should communicate, so I really could appreciate some feedback from more experienced integrators, if you are not too busy. The basic scenario is that users upload array type of datasets, imagery and then select array processing functions and or models to run on their data. We are currently using tclnap for some array processing and have been quite pleased with the results. The new, java developers will write some modeling sw (environmental risk assessment stuff) in java and use the said input files, process the data and return results (or probably file pointers or url's) back to tcl. Keeping in mind that it would probably be a good idea to kinda layer or separate the processes, possibly on separate machines I've been thinking of a few approaches on how to communicate between the tcl frontend and the java backend. 1. Straight sockets. I've been able to test very basic tclclient with basic java server and it seems to work. I feel this might be too low level and complex for anything realworld. 2. Ask the java guys to create XML/RPC or SOAP wrappers on their methods and call these via tclsoap. Here I feel this could work as long as we are only passing url's to the source files and not any real (big/complex) data sets. Probably not a good idea if we ever have to send any actual data for processing. 3. Use tclblend to talk to the developed java objects. Here I feel alot of work would fall on the tclers understanding the java classes, methods etc. Datatypes might also be a concern.Additionally, we would not be able to separate concerns either, as IIUC, tclblend talks to "resident" java classes. Usage of the java app by third party apps would be limited to java based stuff 4. Have the java guys develop a local (to tcl) java stub/facade that tclblend can talk to, maybe via xml-rpc, and then have their stub talk to remote java methods via java RMI (of which I know nothing about, but the java guys kinda drool over...) I feel this approach addresses most of the areas, such as keeping things simple for the tcl side, xml-rpc would allow third party usage and layer the application and finally let the java guys can worry about datatypes, serialization and stuff like that... thanx in advance for any feedback, nikos |