Paul and soapliters,
I have been reading up on SOAP and Distributed Object Architectures, and
have slowly been understanding more and more what SOAP really is and what it
is intended to do. Apparently, SOAP is not meant to be an entire solution,
rather just a piece of a new Distrbuted Objects puzzle.
Things SOAP was *not* written to take care of include object persistence,
location, activation, and garbage collection. These (integral)
responsibilities are intended to be covered on a case-by-case basis,
presumably by some higher distrbuted object framework such as CORBA (or
My question is this: How are you implementing what I have described above
between the SOAP::Lite servers and clients? It appears to be a built-in
feature of SOAP::Lite (only) to allow some of these types of things.
Furthermore, is there any chance of being able to make this interoperate
between languages and/or implementations? Is there any type of standard yet
which addresses this issue?
Currently, with Apache SOAP (Java) on the server and SOAP::Lite (Perl) on
the client, I am limited to implementing static class methods in a
relatively flat functional design. Ideally, I would like my Perl client to
be able to take advantage of the power that comes with persistent
server-side Java objects. Do you have any ideas on how I can achieve this?
 In case my use of terms is unclear:
persistence: A way for server-side objects to maintain state between
SOAP client requests.
location: A way for the server to find/identify persistent objects
(i.e. using an object ID & object database).
activation: A way for the client to store a serialized object on the
server so it takes no resources (such as on disk) and then restore it for
use at a later time. Basically an advanced persistence technique.
garbage collection: When the server permanently destroys an unused