[prev in list] [next in list] [prev in thread] [next in thread] 

List:       axis-c-dev
Subject:    RE: Call initilize and uninitialize
From:       Samisa Abeysinghe <samisa_abeysinghe () yahoo ! com>
Date:       2004-05-27 11:23:05
Message-ID: 20040527112305.61714.qmail () web40609 ! mail ! yahoo ! com
[Download RAW message or body]


> 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

Are they stub specific? I do not think so. What about the state of the client engine. If I am to
tell the client engine evrything for each method invocation, client engine becomes just a dummy
unit. I expect it to handle the state for me.

> > 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.

What I am saying is while the things you have mentioned above(transport protocol, SOAP version)
can change between method calls they are not method specific. Logically only parametes and return
values are method specific. Others are options which may or may not change per method invocation.
Hence the engine should hold then in its state.

> > 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 ?.

Yes they should, as there are state information that need to be held with referance to a stub.

 
> 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.
If the same client connects to multiple web services (or to same web service) using several stubs,
with threads, logically each stub should have its own state. If you have 5 threads and 5 stubs in
each thread, there is a chance that each stub will be using serializer concurrently. So the fact
that there is a pool does not mean that you can do the job with 3 serializers. They need 5; one
each. While pooling could make it efficient so that you do not have to face the creation time
overhead when you need one, the pool does not provide means of maintaining minimum no of objects.
That is not the purpose of a pool.

> At the server side this pooling of Axis object is a must for
> performance.
Client side too will benefit from pooling. However do not mix up pooling with state management.

 
> 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;
Well these two are not sufficint to handle the state of the serializer. 
e.g. Do they reflect the SOAP version currently in use?
Theoritically speaking BasicTypeSerializer do tell you how to do the stuff. It is a utility class,
it does not hold any state.

> > > This implies that if there is any persistent data that you want to
> keep
> > > 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
> engine
> > is just like a functional
> > unit.
> 
> Yes my opinion is that it has to be a functional unit.

:-) Its like a huge function.

> 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.

When I talk about state, what I mean is the state in OO terms.

> 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 a SOA, where where the service requests are atomic units, I could reorder this and call 
M1
M3
M2
Now you see why I want state.

Also practically speaking, most of the time I will not switch headers, rather the header content.

> 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.
Well now do not grab my throat for cloning :-) 
I know that it is inefficient. (I never said it is efficient; did I?)
What I did was to live with what I have. I wanted to get the stub level soap header setting
working with existing engine. I did add an external layer with whatever I had inside the engine.
Why I brought this whole argument up is to hihlight that there are some issues.
Cloning can be removed (just comment the line :-) )

Thanks,
Samisa...


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 
[prev in list] [next in list] [prev in thread] [next in thread]