axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Susantha Kumara" <susan...@opensource.lk>
Subject RE: Transport Abstraction question
Date Tue, 11 May 2004 06:53:35 GMT
Also I am going to add 2 other functions to SOAPTransport interface

	virtual AXIS_TRANSPORT_STATUS flushOutput()=0;
	virtual AXIS_TRANSPORT_STATUS flushInput()=0;

---
Susantha Kumara
Virtusa (pvt) Ltd.
Office : +94112714385
Mobile : +94777420453

> -----Original Message-----
> From: Susantha Kumara [mailto:susantha@opensource.lk]
> Sent: Tuesday, May 11, 2004 12:20 PM
> To: 'Apache AXIS C Developers List'
> Subject: RE: Transport Abstraction question
> 
> 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
> 



Mime
View raw message