rpc interface supporting specialized objects

[Bryan Goring <bg...@rim.net>]

Having a problem with a SOAP rpc interface that i defined running under
weblogic6.1sp2. The same interface works properly when installed under
weblogic6.0sp1. I am using soap2_2 for both tests.

The effect I desire is to have a rpc method that accepts a generic request
object and returns a generic response object. I want to provide different
processing based on the type of request object supplied, that is different
clients will pass their own particular specialization of request and receive
their own specialization of response after processing. The RPC interface
object described in the dtd acts as a dumb interface that just maps the
request to the appropriate processing bean and fires it off. An example
might be:

public class ServerSideProcess {
	Reponse doit(Request);
}

ClientAResponse extends Response, ClientARequest extends Request
ClientBResponse extends Response, ClientBRequest extends Request

Each specialization of Request and Response conform to the Bean spec so that
it can be marshalled and unmarshalled dynamically.

The dtd deployed to the rpcrouter describes 'ServerSideProcess' service and
the 'doIt' provider type. Also, all specializations of the Request and
Respone objects are included and are mapped to BeanSerializers. The dtd does
not describe the generic Request or Response objects.

I implement two clients that map their own specializations of request and
response with the SoapMappingRegistry, then invoke the rpc through the call.

Now, under weblogic 6.0: 1) client marshalls the Client<A/B>Request properly
and passes the soap message to the rpcrouter. 2) The router correctly
invokes the method doIt on the service. 3) The ServerSideProcess hands off
the processing to the appropriate bean (my processing). 4) Finally the
service correctly marshalls the Client<A/B>Response into a soap message and
passes it back to the client. Even though the interface on the remote object
specifies the superclasses, the soap software composes the underlying
objects correctly according to their class type.

Under weblogic 6.1: Step 4) fails, the soap software is trying to serialize
a Response object rather than a Client<A/B>Response, and it fails because
this class type is not described in the DTD for the service. I was able to
get the demo working properly only by modifying the RPCRouter.invoke()
method so that the response Bean created 
is done using the class type of the response rather than the class type
specified on the method argument:

       Object resultOfCall = m.invoke(targetObject, args);
       // result = new Bean (m.getReturnType (), m.invoke (targetObject,
args));
        result = new Bean(resultOfCall.getClass(), resultOfCall);

Apart from the differences in weblogic version, the only other difference is
the way that I am deploying the soap and bean classes. Under wl6.0, the
soap.war file and ejb.jar file were deployed separately. Under wl6.1 I had
to package the soap.war and ejb jar file into an ear file, but I cant see
what difference this would make to soap.

Anyone with any ideas it would be greatly appreciated.
Bryan