Question on a possible xsul server without multi-threading, (Re: [xgws-user] Re: xgws-user digest, Vol 1 #98 - 1 msg

Aleksander Slominski aslom_at_cs.indiana.edu
Mon, 20 Feb 2006 01:28:52 -0500


Tobias Anstett wrote:

> I don't know the XSUL architecture exactly and so my answear is a  
> litte bit off topic.
>
> You can establish a message endpoint that acts like a queue and  
> stores all requests. Then it is up to you to take how many requests  
> out of it to process them. So you have not the problem known as  
> Throttling.

sounds good to me and that is what typically is done when HTTP 
scalability is addressed - you get (set of) load balancing endpoints 
that get messages and pushes them into available processing nodes.

in case of XSUL i am looking to add servlet endpoint for XSUL so 
XServices can be easily deployed inside servlet container with little of 
configuration specifying path for it etc. - advanced servlet container 
(like tomcat5+) has many optionsto throttle HTTP/TCP traffic so no need 
reinvent them (and even now with little work you can expose XSUL service 
as a servlet see samples/xsul_sample_hello/EchoServlet.java but you need 
ot modify code touse your service ...)

> In my current study project we have implemented some stateless  
> session beans that acts like a message endpoint and puts all requests  
> in a Queue.
> So you enable better QoS (reliable communication) and in case of a  
> system crash the requests aren't lost.
>
> Hope MessageBox does the same for you...

WS-Dispatcher is meant to help with it - it acts as a WS proxy servicer 
that provides location independent gateway to WS that are not publicly 
accessible and may be load balanced (multiple copies may be running) - 
WSD takes SOAP messages looks into WS-Addressing headers and figures out 
what to do - however we did not do much recently WSD nonetheless the 
code is in xsul modules/dispatcher if you want to take a look (there 
should be even somedocumentation about it and you can check our paper 
about WSD/MessageBox design [1]).

best,

alek
[1] http://www.extreme.indiana.edu/xgws/papers/ws_dispatcher_ipdps2005.pdf

-- 
The best way to predict the future is to invent it - Alan Kay