axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kenneth Chiu <ch...@cs.indiana.edu>
Subject RE: Transport Abstraction question
Date Tue, 11 May 2004 15:37:15 GMT
On Tue, 11 May 2004, John Hawkins wrote:
> Back onto my Object design platform :-)
>
> re:
>           virtual void setTransportProperty(const char** pcKey, const
>  char** pcValue, int count)=0;
>
> Why don't we encapsulate the list of properties into a class. Good
> encapsulation, extraction, easier to debug etc. etc. etc. Simply standard
> OO practice?

I agree.  Also can simplify memory management.

>
>
>
> John Hawkins,
>
>
>
>
>              "Susantha Kumara"
>              <susantha@opensou
>              rce.lk>                                                    To
>                                        "'Apache AXIS C Developers List'"
>              11/05/2004 10:39          <axis-c-dev@ws.apache.org>
>                                                                         cc
>
>              Please respond to                                     Subject
>               "Apache AXIS C           RE: Transport Abstraction question
>              Developers List"
>
>
>
>
>
>
>
>
>
> Hi Samisa,
>
> > -----Original Message-----
> > From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> > Sent: Tuesday, May 11, 2004 1:36 PM
> > To: Apache AXIS C Developers List
> > Subject: RE: Transport Abstraction question
> >
> > Hi Susantha,
> >     This design looks good.
> >
> >     However need to have a look at the full code (i.e. the class
> structure
> > and hierarchy) to get a
> > good understanding.
> >
> >     I doubt if get/setSessionId() should be part of SOAPTransport as
> some
> > transports support
> > session (e.g. HTTP) and others do not have meaning with session (e.g.
> > SMTP)
>
> So SMTP does not have a session kind of a thing ?. Even if there is not
> we can expose any such mechanism through this interface.
>
> >
> >     What is the purpose of setAttachemnt?
>
> May be a binary stream is given to the transport by either client or
> server using this function. And it's the particular transport that
> decides how it is sent as attachment. Ex: a HTTP transport may send it
> as a separate section in http body. But a SMTP may send it as a mail
> attachment.
>
> >
> >     I think it is easier to have:
> >          virtual void setTransportProperty(const char** pcKey, const
> > char** pcValue)=0;
> > where one could set an array of properties at once. (I erquested this
> in
> > an earlier email)
>
> Yes we can provide this. But isn't it easier to use the simpler function
> multiple times (may be in a loop) rather than allocating pointer arrays
> / deallocating it after this function call etc ?. The other thing is how
> does the function know how many properties are there ?. Probably we will
> have to pass the count too. ie:
>           virtual void setTransportProperty(const char** pcKey, const
>  char** pcValue, int count)=0;
>
> >
> >     Also, Axis C++ has Transport handlers. I think we could have a set
> of
> > default transport
> > handlers built into the engine (for http, smtp etc) wehre transport
> > specific jobs could be done.
>
> What do you mean by "built into the engine" ?. Does it mean that these
> handlers are called even if they are not configured in a wsdd file
> (either client side or server side) ?
>
> >
> >     At a glance I think uers could write their own class similar to
> > ApacheTransport and use a
> > secure transport channel (say SSLTransport). Is my understanding
> correct?
>
> Yes.
>
> > How can I use a secure
> > transport of my own with this new desing?
>
> What Axis Engine sees is the SOAPTransport interface. You can write your
> own transport layers with security/encryption and compression if needed.
>
>
> >
> >    (I know I am asking too many questions; but the motive is to
> improve
> > the desing. So I hope you
> > would bare with me :-) )
>
> No!. Questions are always welcome. They make Axis improve.
>
> >
> > Thanks,
> > Samisa...
> >
> > --- Susantha Kumara <susantha@opensource.lk> wrote:
> > >
> > > Hi Samisa,
> > >
> > > This mail has not reached the mailing list. Something was wrong with
> my
> > > mail server. So writing again.
> > >
> > > > -----Original Message-----
> > > > From: Samisa Abeysinghe [mailto:samisa_abeysinghe@yahoo.com]
> > > > Sent: Thursday, May 06, 2004 1:41 PM
> > > > To: Apache AXIS C Developers List
> > > > Subject: Re: Transport Abstraction question
> > > >
> > > > Option 1 is too coupling. Option 2 sounds better (however, option
> 2
> > > needs
> > > > to tacle limited buffer
> > > > sizes)
> > >
> > > If the amount of data arrived at transport layer is larger than the
> > > memory buffer provided by Axis, the transport layer should keep the
> > > excess data till Axis requests again.
> > >
> > > > What is the overall plan for paser and transport abstraction? Have
> you
> > > got
> > > > an initial overall
> > > > design?
> > >
> > > I am proceeding in the way we discussed on the mailing list. At the
> > > moment I could run Axis client and server with the abstract
> transport
> > > layer. Transport layer is dynamically loaded at client side. At the
> > > moment the transport Interface is as follows. I made the existing
> > > AxisTransport class to implement this interface and made it to a
> dynamic
> > > library which is loaded at runtime by Axis. Then Axis calls the
> > > library's export function CreateInstance to create an instance of
> > > transport.
> > >
> > > For server side I created a class called ApacheTransport that
> implements
> > > this interface. ApacheTransport class just wraps the functionality
> of
> > > apache module and provides SOAPTransport interface's functionality.
> > >
> > > class SOAPTransport
> > > {
> > > public:
> > >          virtual ~SOAPTransport(){};
> > >     virtual int openConnection()=0;
> > >     virtual void closeConnection()=0;
> > >          /**
> > >           * Used to send buffers to the transport layer. Axis Engine
> may
> > > call this method multiple
> > >           * times. Its upto the transport to decide how they are sent
> > > (chunked/unchunked etc). This
> > >           * method may return 3 status values. Meanings are given below
> > >           * TRANSPORT_FINISHED - Passed buffer has been sent. So the
> > > caller can re-use the buffer
> > >      * TRANSPORT_IN_PROGRESS - Passed buffer is not sent. So the
> caller
> > > cannot re-use the buffer
> > >      * TRANSPORT_FAILED - Transport layer has failed.
> > >           * In case this function returns TRANSPORT_IN_PROGRESS. The
> > > caller should wait till the transport
> > >           * layer calls the provided callback function with the
> bufferid
> > > to indicate that it can re-use
> > >           * the buffer.
> > >           */
> > >     virtual AXIS_TRANSPORT_STATUS sendBytes(const char*
> pcSendBuffer,
> > > const void* pBufferid)=0;
> > >          /**
> > >           * Method used to register the callback function which is
> called
> > > by transport layer to inform
> > >           * Axis Engine that a buffer given to it is sent and it can be
> > > re-used by Axis Engine.
> > >           *
> > >           */
> > >          virtual void
> > >
> registerReleaseBufferCallback(AXIS_ENGINE_CALLBACK_RELEASE_SEND_BUFFER
> > > pFunct)=0;
> > >          /**
> > >           * Used to get part of or all SOAP message.
> > >           */
> > >     virtual AXIS_TRANSPORT_STATUS getBytes(char* pcBuffer, int*
> > > piRetSize)=0;
> > >     virtual void
> setTransportProperty(AXIS_TRANSPORT_INFORMATION_TYPE
> > > eType, const char* pcValue)=0;
> > >     virtual const char*
> > > getTransportProperty(AXIS_TRANSPORT_INFORMATION_TYPE eType)=0;
> > >     virtual void setTransportProperty(const char* pcKey, const char*
> > > pcValue)=0;
> > >     virtual const char* getTransportProperty(const char* pcKey)=0;
> > >          virtual void setAttachment(const char* pcAttachmentid, const
> > > char* pcAttachment)=0;
> > >          virtual const char* getAttachment(const char*
> pcAttachmentid)=0;
> > >          virtual void setEndpointUri(const char* pcEndpointUri)=0;
> > >          virtual void setSessionId(const char* pcSessionId)=0;
> > >          virtual const char* getSessionId()=0;
> > >          virtual const char* getServiceName()=0;
> > >          virtual AXIS_PROTOCOL_TYPE getProtocol()=0;
> > >          virtual int getSubProtocol()=0; /* is this appropriate name ?
> */
> > > protected:
> > >          char* m_pcEndpointUri;
> > >          AXIS_ENGINE_CALLBACK_RELEASE_SEND_BUFFER
> > > m_pReleaseBufferCallback;
> > >
> > > };
> > >
> > > I am doing the testing on server side and will be able commit the
> code
> > > by tomorrow. Please give me your feedback/comments on this approach.
> We
> > > also can improve/change this interface etc even after commiting this
> > > code.
> > >
> > > Thanks,
> > >
> > > Susantha.
> > >
> > > > Samisa...
> > > >
> > > >
> > > > --- Susantha Kumara <susantha@opensource.lk> wrote:
> > > > > Hi all,
> > > > >
> > > > > I am working on Transport layer and Parser layer abstraction and
> got
> > > > > following question,
> > > > >
> > > > > At the moment Axis assumes that the receiving part of the
> transport
> > > > > layer can behave in 2 ways.
> > > > > 1.       Some transport layers allocate memory buffers / fills
> them
> > > with
> > > > > receiving data and gives to Axis.(see getBytes(..) function)
> > > > > Ex : When using Expat parser
> > > > >                   These transport layers want Axis to inform
> them
> > > when
> > > > > Axis has finished using the given memory buffer.(see
> > > releaseBuffer(..)
> > > > > function)
> > > > > 2.       Some transport layers don't allocate memory buffers but
> > > will
> > > > > fill the given buffers (from Axis).
> > > > > Ex: When using Xerces parser.
> > > > >
> > > > > But generally its VERY difficult for a XML parser to use the
> buffers
> > > > > given by outside. Especially when the XML document is given in
> > > parts.
> > > > >
> > > > > In above 1st case too Expat internally copies all data passed to
> it
> > > into
> > > > > its own buffer. That buffer inside Expat grows finally to the
> size
> > > of
> > > > > the whole XML document. But if we get a buffer allocated inside
> > > Expat
> > > > > and pass it to the transport layer to be filled and given back
> that
> > > > > would be more efficient in terms of memory.
> > > > >
> > > > > In above 2nd case Xerces allocates a buffer of around 48KB and
> > > passes it
> > > > > to transport to be filled.
> > > > >
> > > > > So It seems that there is no point of supporting case 1 as long
> as
> > > there
> > > > > is no XML parser that is capable of efficiently parsing (without
> > > copying
> > > > > to its other memory buffer) memory buffers allocated outside of
> the
> > > > > parser.
> > > > >
> > > > > Those who have experience in writing an XML parsers will
> understand
> > > this
> > > > > problem better.
> > > > >
> > > > > So what about supporting only case 2 in the upcoming transport
> API
> > > ?.
> > > > >
> > > > > ---
> > > > > Susantha
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > __________________________________
> > > > Do you Yahoo!?
> > > > Win a $20,000 Career Makeover at Yahoo! HotJobs
> > > > http://hotjobs.sweepstakes.yahoo.com/careermakeover
> > >
> > >
> >
> >
> >
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Win a $20,000 Career Makeover at Yahoo! HotJobs
> > http://hotjobs.sweepstakes.yahoo.com/careermakeover
>
>
>

Mime
View raw message