I was talking about the server side, not the client side. The SOAPService is used on both sides for a) service-specific request and response flows, and b) service-specific type mappings. Just seems like a logical place to centralize that stuff. It's potentially a little weird on the client side, since you almost don't need a SOAPService handler, in terms of the Handler functionality, unless you have req/resp handlers.
I've pushed for a long time now for a service metadata class which is common to the client and server (what ServiceDescription was originally intended to be), so I could see going in this direction as well. This would contain type mappings, style information, operation-specific configuration parameters, etc.... --Glen > -----Original Message----- > From: R J Scheuerle Jr [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 19, 2002 11:20 AM > To: [EMAIL PROTECTED] > Cc: 'Axis-Dev (E-mail)' > Subject: Re: Upcoming change - services required to be SOAPServices > > > Glen, > > Currently the org.apache.axis.client.Service class has > getTypeMapping/setTypeMapping methods that are not implemented. > Its my belief (and JAX-RPC) that the Service class should have the > TypeMapping, and the Call should get the TypeMapping from the Service. > > So I guess I don't understand why the TypeMapping info is > obtained via the > SOAPService handler. > > > > Thanks, > > Rich Scheuerle > XML & Web Services Development > 512-838-5115 (IBM TL 678-5115) > > > > > Glen Daniels > > <gdaniels@macrome To: > "'Axis-Dev (E-mail)'" <[EMAIL PROTECTED]> > dia.com> cc: > > Subject: > Upcoming change - services required to be SOAPServices > 02/19/2002 10:04 > > AM > > Please respond to > > axis-dev > > > > > > > > > > Right now our architecture allows someone to directly set the > "serviceHandler" in a MessageContext to be any Handler. > However, even if > you use the "handler" provider in WSDD, the specified Handler > gets wrapped > in a SOAPService (i.e. becomes the provider handler in the > SOAPService), so > in practice unless you get really deep into the API yourself, > you're always > going to have a SOAPService as the serviceHandler. > > I'd like to make this explicit in the API, by making > setService() (formerly > setServiceHandler) in the MessageContext take a SOAPService argument. > > The reason for this is that there are several pieces of > runtime metadata > associated with a service which it would be nice to have in > ALL cases, such > as type mappings and service "style" (document or RPC). I'm currently > working on adding <style>[document/rpc]</style> to WSDD, and > having that do > the right thing with WSDL generation, encoding, etc. and I'd > like to avoid > checking instanceof SOAPService all the time. > > If anyone sees problems with this, please let me know. > > --Glen > > >
