axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Susantha Kumara" <>
Subject RE: Transport Abstraction question
Date Tue, 11 May 2004 06:20:26 GMT

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 []
> 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
> 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
> 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

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  
	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
	 * Used to get part of or all SOAP message. 
    virtual AXIS_TRANSPORT_STATUS getBytes(char* pcBuffer, int*
    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*
    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 ? */
	char* m_pcEndpointUri;


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



> Samisa...
> --- Susantha Kumara <> 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
> > receiving data and gives to Axis.(see getBytes(..) function)
> > Ex : When using Expat parser
> >                   These transport layers want Axis to inform them
> > Axis has finished using the given memory buffer.(see
> > function)
> > 2.       Some transport layers don't allocate memory buffers but
> > 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
> >
> > In above 1st case too Expat internally copies all data passed to it
> > its own buffer. That buffer inside Expat grows finally to the size
> > the whole XML document. But if we get a buffer allocated inside
> > 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
> > is no XML parser that is capable of efficiently parsing (without
> > to its other memory buffer) memory buffers allocated outside of the
> > parser.
> >
> > Those who have experience in writing an XML parsers will understand
> > 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

View raw message