axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Susantha Kumara" <>
Subject RE: Call initilize and uninitialize
Date Thu, 27 May 2004 08:23:58 GMT
Hi Samisa,

> -----Original Message-----
> From: Samisa Abeysinghe []
> Sent: Thursday, May 27, 2004 9:06 AM
> To: Apache AXIS C Developers List
> Subject: RE: Call initilize and uninitialize
> > No not any big objects are allocated and deallocated per each method
> > invocation. Only the request/response specific objects like
> > SoapEnvelope, SoapBody, SoapMethod are allocated and deallocated. We
> > cannot avoid that.
> Say I have 10 method calls in my stub. And I want to use SOAP 1.1 for
> method invocations.
> Why sould I set it in each method invocation unless othervise I decide
> change the SOAP version?
> Where am I supposed to hold this data regarding SOAP version?

We have to change the code to store these stub specific information in
the stub itself (or inside its Call class object). These information
that we should keep in the Call class instance are,

- Stub's style (CPP_RPC_PROVIDER etc)
- Communication protocols (HTTP, SMTP etc)
- Web Service Endpoint URI
- SOAP Version to Use
- And any other stub specific information that are in the original WSDL

> If the client stub is to set this for each method invocation, isnt it
> inefficient?

Yes, Only the method specific information should be set/get within the
stub's generated method.

> Allocation/deallocation should not be based on big or samll. 

Why not ?. Bigger the object is the bigger memory allocation overhead in
system call. And if there are any initializations to be done we have to
do them for each object that we create.

> Rather on the
> life time of objects.

Life time of an object is an important design decision. Are you saying
that every stub object should have its own Serializer / Deserializer /
Transport / Parser objects ?.

Consider a single threaded client application with several stub
instances talking to several web services (or same web service). In such
a case if each stub has its own set of Axis objects it's a waste. If
this is a multi-threaded application the object pools make sure that you
maintain a minimum number of Axis objects.

At the server side this pooling of Axis object is a must for

> >
> > The concept that we have is that a Deserializer or Serializer
> > are never bound to a request. That is they do not keep any
> > data inside them. This applies to both client side and server side.
> Serializer and Deserializer are not bound to request, but they are
used by
> method invocations.


> If you consider them as functions, you have to pass all the data they
> require.
> However if they are objets, they can have state and their memeber
> variables should reflest the
> state. It is not about persistant data, but about state.

No they cannot be considered as functions. Also they do not have state
variables. All variables in them are used to accomplish its task when it
is used by a stub. Please see the purpose of following variable in
SoapSerializer class,

    volatile SerializeBuffers* m_pSZBuffers;
    BasicTypeSerializer m_BTSZ;

> > This implies that if there is any persistent data that you want to
> > across several method invocations, you have to keep them in,
> > 1. A handler
> > 2. The client application (stub)
> > 3. Web service.
> If they are to hold evryting and pass everyting to te engine, the
> is just like a functional
> unit.

Yes my opinion is that it has to be a functional unit.

> However, I expect the engine to hold the state data in an OO design.

My opinion is that either your stub object or your application should
hold the state data. Not the Axis Engine. Axis Engine should be a set of
objects that serves any stub/web service at runtime.

> As an example, once I instruct the engine to set a SOAP header to
> calls, the expectation
> is that the engine will do so for all my calls, until I explicitly
> the engine not to do so.

What if you need to change/remove/add the SOAP headers in between
several method calls of the same stub. Ex: you have Headers H1, H2, H3,
H4 and you have methods M1, M2, M3 and you need to call methods in
following order with the headers

M1 with H1, H2, H3
M2 with H4 only
M3 with H1, H2 

In this case you anyway have to tell AxisEngine what headers you need to
send and what not to. 

> If the client stub has to repetedly tell the samething over and over
> againg, it is far more
> inefficient.

Keeping the created and populated header structures/properties with the
stub and passing them as needed to the engine for each method call is
far more efficient than you everytime creating+populating (or cloning),
passing to axis engine and letting axis engine to delete them everytime.
> Samisa...
> __________________________________
> Do you Yahoo!?
> Friends.  Fun.  Try the all-new Yahoo! Messenger.

View raw message