You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-user@ws.apache.org by Ted Poole <ej...@prismtechnologies.com> on 2000/10/13 17:14:52 UTC

Locating the target object

Hi,

So far I have managed to deploy and run some of the samples, using tomcat
3.1, and everything seems fine. I am now starting to apply the SOAP
implementation in my project and I have two problems:

(1) The lifetime of my target objects (JMS TopicPublisher/QueueSender) are
controlled externally from the SOAP page, request, application or session
scope.

(2) My target objects are located by JNDI lookup rather than class name.

The latter is the bigest problem because the target object resolution
mechanisms in the RPCRouterServlet are not extensible i.e. I cannot plug in
or register a custom resolution mechanism (this would be nice). Failing
this, I have a number of other options:


(1) Deploy a Java class as the target object. This object would have the
same interface as the real target object and act as a wrapper to indirectly
locate the appropriate JMS TopicPublisher or QueueSender using JNDI, and
then call onwards. The problem with this is that there seems to be no way of
obtaining the target object id from within the call on the wrapper. I need
to get the target id in the wrapper call so that I can get the real target
object from JNDI.

(2) If there really is no way of getting the target object id from within a
call on the target object (the wrapper) then I will have to explicitly pass
it as part of the method signatures on the wrapper. Not so nice.

(3) My current approach is to replace the RPCRouterServlet with something
that does exactly what I want i.e. I am replacing the class load/instantiate
and script handling stuff with a JNDI lookup based on the target object ID.

(4) My preferred solution would be to implement something more generic that
would allow custom modules to be registered, allowing new target object
resolution mechanisms to be implemented and registered, possibly replacing
the existing ones.

If anyone is working on this or has any alternatives, comments are welcome.

Cheers,
	Ted