Thanks for your explanation! See my comments below.
> -----Original Message-----
> From: Dennis Sosnoski [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 05, 2002 12:10 PM
> To: Volkmann, Mark
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: Getting Started Sample Doc
>
>
> In general it doesn't make sense to return an interface from a SOAP
> call. The issue here is that you're not actually passing an object -
> you're passing a collection of data values which each end is free to
> interpret in any way it wants. What good does it do to use an
> interface in this situation?
In my case, it's not that I necessarily want my web service to be defined by an interface, but I already have the interface because it is being used for accessing my service through an EJB. The implementation of my "service" is generic Java code and I want to be able to access that through either a stateless session bean or a web service. I'm hiding this detail from Java clients. They just know they are working with something that implements some interface.
An additional complication is that many of the Java objects returned the methods of my service have methods that return interface types. I think this is a fairly common scenario, but apparently not one that Axis handles well ... without significant manual steps. It would be nice if there was a way to tell Java2WSDL and WSDL2Java that whenever they encounters certain interfaces they should assume that at runtime certainly classes will be used.
> If all you want is to be able to define a JavaBean-interface that
> provides get/set methods for some data values, with that interface
> implemented by multiple classes, you should be able to do this using
> custom serialization. I haven't looked into the details of
> making this
> work for a case like yours, but you should be able to
> construct JavaBean
> serializers and deserializers based on a dummy class that just
> implements the interface methods, then have your serializer and
> deserializer basically just pass off to the JavaBean handling. On the
> deserialization side you'd need to override the JavaBean handling to
> construct the appropriate concrete class before doing the actual
> deserialization.
>
> This won't happen automatically using Java2WSDL and
> WSDL2Java, though.
> The closest you could get would be by defining a dummy class that
> implements your interface and using that to define WSDL and in turn
> generate Java. You'd still need to extend that by adding your custom
> serialization handling, though.
I'll try this approach.
> - Dennis
>
> Volkmann, Mark wrote:
>
> > Dennis,
> >
> > Suppose the getPerson method in your PersonLookup class returned a
> > Person instead of a PersonBean where Person is an interface that is
> > implemented by PersonBean. In that case, I don't think running
> > Java2WSDL on PersonLookup would generate sufficient WSDL to
> be used as
> > input to WSDL2Java. Is there are way to handle that case? I'm
> > struggling with this exact case now.
> >
> > > -----Original Message-----
> > > From: Dennis Sosnoski [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, December 04, 2002 12:31 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: Re: Getting Started Sample Doc
> > >
> > >
> > > You can also try taking a look at
> > > http://www.sosnoski.com/presents/java-xml/axis/axis-service.ht
> > > ml which
> > > gives a run through of turning existing Java classes (passing
> > > a bean as
> > > the return value for a method call) into a service and client.
***********************************************************************************
WARNING: All e-mail sent to and from this address will be received or
otherwise recorded by the A.G. Edwards corporate e-mail system and is
subject to archival, monitoring or review by, and/or disclosure to,
someone other than the recipient.
************************************************************************************
