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
|
