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

[Shanmuga.MUHUNTHAN@fr.thalesgroup.com]

hi everybody,

One of the main advantage of XSUL (compare to axis for example) is that xsul implements its own http server and no need to install APACHE TOMCAT to deploy a service. I choose xsul for that. When you want to use soap on an embedded environement, this aspect is very important (socket reuse too). Even if XServices will be compatible with TOMCAT, it will be great if xsul continues to implement and support its own http server (and can work standalone). That is to say, it will be great if xsul can implements its own HTTP/TCP traffic Throttling(even if this is very simplistic). I think in few years, telecom industry will focuse on embedded soap (SOAP/XML router, web service embedded environment ...) and package with small footprint, little dependency , great robustness and better sacalability will be choosen. Rather than proposing the same functionalities than axis, I think xsul has to support "exotic" functionalities (like usefull ws-dispatcher and msgbox functionalities) in order!
  to cover all industry needs. That is my point of view (perhaps I'm wrong), comments are welcome...

Best regards
Shan

-----Message d'origine-----
De : xgws-user-admin_at_cs.indiana.edu
[mailto:xgws-user-admin_at_cs.indiana.edu]De la part de Aleksander
Slominski
Envoyé : lundi 20 février 2006 07:29
À : Tobias Anstett
Cc : xgws-user_at_cs.indiana.edu
Objet : Re: Question on a possible xsul server without multi-threading,
(Re: [xgws-user] Re: xgws-user digest, Vol 1 #98 - 1 msg


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

_______________________________________________
xgws-user mailing list
xgws-user_at_cs.indiana.edu
http://mailman.cs.indiana.edu/mailman/listinfo/xgws-user