A transport (whether on the client or the server side) represents a given chunk of transport-specific functionality implemented in Handlers. This includes stuff like the HTTPSender (on the client side), but also potentially things like cookie-setting handlers, URL dispatchers, etc. It is very possible that a given system will want to use multiple transports for a given protocol - for instance, if my client talks to two remote endpoints, one of which expects some kind of transport-specific authorization handshake, and one of which doesn't.
Having the ability to name transports separately from the protocols allows developers to deploy multiple transports in a system (via client-deploy.wsdd/server-deploy.wsdd/etc) and utilize them at will without needing to invent new "protocols". If protocol is the only way to map transport names, we then need to make sure to install a new transport package for each configured transport, so that the URLs will be accepted.... I would much rather we kept the possibility that transports could be named things other than protocol names, and made it work correctly (it doesn't really at present) than removing this potentially very useful function. Essentially this just means having a "setTransport(String name)" on Call, and using the usual default (look for a transport named the same as the protocol) when not explicitly set. Thoughts? --Glen ----- Original Message ----- From: "Russell Butek" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 29, 2002 8:39 AM Subject: Re: [axis] Transport Name > Go for it. I thought about combining these once, but after 5 minutes of > poking about I realized it was more than a 5 minute job, so I decided not > to tackle it just then (ie., I gave up). > org.apache.axis.client.AdminClient makes use of Call.TRANSPORT_NAME, so > SOMEONE is hoping the name is meaningful. What is AdminClient hoping to > accomplish here? > > Russell Butek > [EMAIL PROTECTED] > > > Richard Sitze/Charlotte/IBM@IBMUS on 05/28/2002 06:54:30 PM > > Please respond to [EMAIL PROTECTED] > > To: [EMAIL PROTECTED] > cc: > Subject: Re: [axis] Transport Name > > > > Let me add more context: org.apache.axis.client.Transport > > > ******************************************* > Richard A. Sitze [EMAIL PROTECTED] > CORBA Interoperability & WebServices > IBM WebSphere Development > > > > Richard > Sitze/Charlotte/ To: > [EMAIL PROTECTED] > IBM@IBMUS cc: > Subject: [axis] Transport > Name > 05/28/2002 05:01 > PM > Please respond > to axis-dev > > > > > > > What is the distinction between a transport name and the protocol? By > default, it appears that the name is the protocol. > > Under what circumstances would the name be changed (Call.TRANSPORT_NAME)? > The 'name' doesn't appear to be used for anything (whereas the protocol is > used to find the right Transport class. > > Unless there are objections, I'd like to remove the logic that allows the > name to be changed (again, why?), and change/cleanup the logic to refer to > protocol instead of name. > > Comments? > > ******************************************* > Richard A. Sitze [EMAIL PROTECTED] > CORBA Interoperability & WebServices > IBM WebSphere Development > > > > > >
