Ralph,

The approach, I've outlined would work using the Apache SOAP/Java
toolkit although it would be the URN defined in the deployment
descriptor passed via the HTTP SOAP action header which would therefore
identify the database. I think it perfectly legal for the HTTP
SOAP-Action to determine the database as the URL used. In general, the
model is that you connect to a different ZNG SOAP Service for a
different database.

However, if you wanted to determined the database on the with the Apache
SOAP/Java toolkit you would run two instances of the RPC Router on
different URLS.

Both these approaches are fairly trivial and not particularly
non-standard uses of the Apache toolkit

Matthew



> -----Original Message-----
> From: LeVan,Ralph [mailto:[log in to unmask]]
> Sent: 30 October 2001 20:59
> To: [log in to unmask]
> Subject: Re: RPC Context
> 
> I can do all sorts of trickery to make this problem go away.  But, one
of
> the points of this exercise is to do something simple.  By that I mean
> that
> it should use standard tools as much as possible.
> 
> If we are doing standard SOAP RPC, then there are standard ways of
> generating the RPC client and server.  If I use the standard RPC
server
> tools, then I don't have access to context.
> 
> If you know how to do this using standard tools, then please let me
know.
> I've been beating my head against this problem for some time now.
> 
> The problem goes away when we add database to the list of RPC
parameters.
> I've been able to put together a very slim client and server built on
the
> RPC model when I added database.
> 
> Ralph
> 
> > -----Original Message-----
> > From: Matthew Dovey [mailto:[log in to unmask]]
> > Sent: Tuesday, October 30, 2001 3:50 PM
> > To: [log in to unmask]
> > Subject: Re: RPC Context
> >
> >
> > By ID do you mean URL?
> >
> > Basically you bind different URLs to different instantiations of the
> > Java class.
> >
> > One approach would be to write an abstract class with all the ZNG
> > handling, something like
> >
> > public abstract class BaseZNGObject {
> >   String database = null
> >
> >   public Test() {
> >   }
> >
> >   public ZNG(
> >
> > ...
> > // All the ZNG handling, database searching stuff.
> >
> >
> > }
> >
> >
> > Then write classes of the form
> >
> > public class Database1ZNGObject extends BaseZNGObject {
> >
> >   public Database1ZNGObject () {
> >     database="database1";
> >   }
> > }
> >
> > public class Database2ZNGObject extends BaseZNGObject {
> >
> >   public Database1ZNGObject () {
> >     database="database2";
> >   }
> > }
> >
> > And then bind these classes to different URLs using the SOAP
toolkit.
> >
> >
> > Matthew
> >
> > > -----Original Message-----
> > > From: LeVan,Ralph [mailto:[log in to unmask]]
> > > Sent: 30 October 2001 15:20
> > > To: [log in to unmask]
> > > Subject: RPC Context
> > >
> > > I'm still trying to figure out how to tell what database my query
is
> > for.
> > > The problem may be in my toolkit, but I've got to ask this
question
> > again.
> > >
> > > When a SOAP request is received, a special SOAP servlet
> > processes the
> > > message.  It looks at the ID for the message, looks that ID up in
a
> > table
> > > and determines the Java class that contains the method that should
> > process
> > > the message.  It then pulls the parameters for the method out of
the
> > > message.  It then creates an instance of the Java class and
> > calls the
> > > method
> > > (searchRetrieve in our case) with the parameters.
> > >
> > > Nowhere in there does searchRetrieve have access to the URL that
> > contained
> > > the message.  That URL somehow encoded the database to be
searched.
> > That
> > > means that my searchRetrieve method does not know what database it
> > should
> > > be
> > > searching.
> > >
> > > How do we get around this problem without exposing the database
name
> > as a
> > > parameter to searchRetrieve.
> > >
> > > Thanks!
> > >
> > > Ralph
> >