Re: AW: Intermediary node

[Borut Bolcina]

Hello Dimuthu,

On Friday, Nov 14, 2003, at 04:26 Europe/Ljubljana, Dimuthu Leelarathne 
wrote:

Hi Bob,

I would like to comment on the following line.

CLIENT ---> INTERMEDIARY ---> ENDPOINT

Are you talking about the "INTERMEDIARY" mentioned in the SOAP 
specification?

Yes, as the theory says, this would be a solution, but where to find a 
code example in java to do just that?

We (myself and my team mates) had a long discussion \ arguments on this
matter few months back. The question was
What is this "Intermediary"? Can we consider a handler as an 
intermediary?
Or should we call a SOAP node such as a SOAP engine ?

I think a node, but I guess I should do some further reading on what a 
handler is and in which situation to use it (them). Again I have little 
experience.

Our final conclusion was that a Intermediary should be a SOAP engine 
not a
soap handler. Of course we should not argu on mere words - but meaning 
of
the words.

Could decision about using a handler or node be made on the technology 
used for coding? Can you read my other reply to Wolfgang?


Many clients will connect with different "payload weight", which
roughly determines the computational time for each request. The
I am not an ANN expert, but this sounds like a neural network :-), so 
if
you want a network (somethign like a neural network) , are you 
planning to
consider a handler as a node?

Heh, as a matter of fact I did some neural network programming (LVQ 
algorithms and Backpack propagation) for image recognition, but this 
topic is beyond this discussion.

Of course reading through your mail I think you might have to use a
handler as a intermediatry to provide the required functionality, but 
the
problem is Axis engine controls handler chains (you can refer the
architecture guide). Some computations done at a specific handler 
cannot
control the flow of the message. So you will have a hard time 
configuring
a handler as a node in the network - especially if it is going to be 
more
than 2 layers.

If you are really keen about this, one option is you can write a your 
own
engine !!!!

Huh, I am trying to make the result of this equation to be as small as 
possible! :-)

time / money

But than again, many people switch religion.

Until next time,
bob
Regards,
Dimuthu.

My first goal would be just simply the intermediary to receive the
request, read the headers, make some database operations, make some
choices and if everything is ok, forward the request with new headers
to "real" web service (ENDPOINT) to do the job.




--
Lanka Software Foundation  http://www.opensource.lk
Hi,
  am a bit confused by some of your statements. Perhaps you can help 
me
with
that...
Wolfgang

Borut Bolcina [mailto:[EMAIL PROTECTED] wrote:
Hi, again

since I had no luck, nobody answered to my question posted a
month ago
(subject WebServices chaining), i'll try again.


Can you please help me understand just how can one implement this
'simple' scenario.
CLIENT ---> INTERMEDIARY ---> ENDPOINT

Many clients will connect with different "payload weight", which
roughly determines the computational time for each request. The
ultimate goal would be that intermediary node acts as a queue and a
load balancer for a number of endpoints.
so you want to implement something like a communications bus, right?
load balancer ok, but why should it act as a queue?
My first goal would be just simply the intermediary to receive the
request, read the headers, make some database operations, make some
choices and if everything is ok, forward the request with new headers
to "real" web service (ENDPOINT) to do the job. If successful, the
intermediary again does some processing and returns the
result back to
the originator of the request - the CLIENT.
Now, what happens if in the middle of this process another request
comes in? The intermediary should be clever enough to know that the
ENDPOINT is busy and act accordingly.
what do you mean with "busy"? why should the endpoint only receive one
request at a time?
I read about synchronous and
asynchronous requests and other theoretical stuff which I
could find on
the internet, but I am still confused. If asynchronous services would
be a way to go, then I guess the clients will have to be smarter and
the choice of technology narrower. If request-response
mechanism could
do the job, it would be easier, wouldn't be?
yes...

I am aware (it is even a demand) that I will have to
implement several
ENDPOINTs which would work as a farm of the same services to increase
the efficiency and the reliability of service will be one of
the major
questions, so I don't want to start implementing a bad architecture
which will limit my options later on.
Architectures using webserver/servlet engine or application server 
allow
to process more than one request at a time. Clustering is only 
necessary
for failover/load balancing mechanisms.

I have written a client which I installed on several machines
to stress
test the ENDPOINT web service. I bombarded the poor workhorse from
those machines with requests coming apart just under a second from
each. Each response lasted roughly from 15 to 45 seconds, but
they all
got processed successfully. Now, I would be a happy person if I could
be able to squeeze this intermediary in-between to do some logging. I
guess HTTP nature of request-response loop handled the queue for me.
How do I do this with intermediary node?
No queue but several threads to process the requests. Perhaps you use 
a
resource in your webservice that is only available once, so that all
threads have to wait for it?

Does my question narrows down to handling sessions? If client sends a
request which takes a long time to process, how to handle another
client's request which came seconds after the first one?
Sessions/Threading does this for you

Am I missing something very crucial here?

I am developing with Java and WebObjects as the application server,
just to note, but not to disturb you. WO uses Axis engine.
Regards,
bob