Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Transport Abstraction question
Date: Wed, 12 May 2004 07:21:12 +0600
Message-ID: 
 <28B8E04BCFBEB74B9B19F765DE6598E9C01560@enetslmaili.enetsl.virtusa.com>
Thread-Topic: Transport Abstraction question
Thread-Index: AcQ3PiqjERVAIQHESpGrOanZGIoFkAAgEetA
From: "Samisa Abeysinghe" <SAbeysinghe@virtusa.com>
To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>

Hi John,
 =09No question that encapsulation would help. However, in most cases tra=
nsport properties would be key:value pairs of stirngs.
=09e.g. HTTP headers and SMTP headers
=09Provided that they would not be more than key:value paires, arrays wou=
ld serve the purpose.

Thanks,
Samisa...

-----Original Message-----
From: John Hawkins [mailto:HAWKINSJ@uk.ibm.com]
Sent: Tuesday, May 11, 2004 3:54 PM
To: Apache AXIS C Developers List
Subject: RE: Transport Abstraction question


Back onto my Object design platform :-)

re:
          virtual void setTransportProperty(const char** pcKey, const
 char** pcValue, int count)=3D0;

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?


John Hawkins,


                                                                         =
 =20
             "Susantha Kumara"                                           =
 =20
             <susantha@opensou                                           =
 =20
             rce.lk>                                                    T=
o=20
                                       "'Apache AXIS C Developers List'" =
 =20
             11/05/2004 10:39          <axis-c-dev@ws.apache.org>        =
 =20
                                                                        c=
c=20
                                                                         =
 =20
             Please respond to                                     Subjec=
t=20
              "Apache AXIS C           RE: Transport Abstraction question=
 =20
             Developers List"                                            =
 =20
                                                                         =
 =20
                                                                         =
 =20
                                                                         =
 =20
                                                                         =
 =20
                                                                         =
 =20


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)=3D0;
> 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)=3D0;

>
>     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()=3D0;
> >     virtual void closeConnection()=3D0;
> >          /**
> >           * 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 bel=
ow
> >           * 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)=3D0;
> >          /**
> >           * 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)=3D0;
> >          /**
> >           * Used to get part of or all SOAP message.
> >           */
> >     virtual AXIS_TRANSPORT_STATUS getBytes(char* pcBuffer, int*
> > piRetSize)=3D0;
> >     virtual void
setTransportProperty(AXIS_TRANSPORT_INFORMATION_TYPE
> > eType, const char* pcValue)=3D0;
> >     virtual const char*
> > getTransportProperty(AXIS_TRANSPORT_INFORMATION_TYPE eType)=3D0;
> >     virtual void setTransportProperty(const char* pcKey, const char*
> > pcValue)=3D0;
> >     virtual const char* getTransportProperty(const char* pcKey)=3D0;
> >          virtual void setAttachment(const char* pcAttachmentid, const
> > char* pcAttachment)=3D0;
> >          virtual const char* getAttachment(const char*
pcAttachmentid)=3D0;
> >          virtual void setEndpointUri(const char* pcEndpointUri)=3D0;
> >          virtual void setSessionId(const char* pcSessionId)=3D0;
> >          virtual const char* getSessionId()=3D0;
> >          virtual const char* getServiceName()=3D0;
> >          virtual AXIS_PROTOCOL_TYPE getProtocol()=3D0;
> >          virtual int getSubProtocol()=3D0; /* is this appropriate nam=
e ?
*/
> > 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


-------------------------------------------------------------------------=
------------------------=0AThis message, including any attachments, conta=
ins confidential information intended for a specific individual and purpo=
se, and is intended for the addressee only.  Any unauthorized disclosure,=
 use, dissemination, copying, or distribution of this message or any of i=
ts attachments or the information contained in this e-mail, or the taking=
 of any action based on it, is strictly prohibited.  If you are not the i=
ntended recipient, please notify the sender immediately by return e-mail =
and delete this message.