Angel No, the WSA approach doesn't work through firewalls with HTTP. We just published a spec as part of the WSRM initiative that solves this problem (WS-MakeConnection).
However, other protocols like SMTP and Jabber solve the firewall problem. Paul On 2/13/07, Angel Todorov <[EMAIL PROTECTED]> wrote:
Hi Paul, What about firewall issues and WS clients staying behind NAT ? Is this possible with the current Axis2 WS-Addressing impl, if a client brings up a HTTP server and the "real" server connects back to it ? Thanks. Best, Angel On 2/13/07, Aleksander Slominski <[EMAIL PROTECTED]> wrote: > Paul Fremantle wrote: > > Michele > > > > We (the Synapse team) have written a pure non-blocking HTTP transport > > for Axis2. Its currently in the Synapse repository, but we will check > > it into the core Axis2 SVN when its stable. > > > > However, I wanted to clear up the asynchronous model. This isn't a > > clear area by any means! > > > > The current Axis2 with Addressing is actually already asynchronous. > > What happens is that if the replyTo address is a real HTTP URL > > (useSeparateListener), then the client will start up a mini HTTP > > server. The service will respond instantly with an HTTP 202 OK > > (accepted message but not yet processed), and the HTTP connection will > > be closed. When the response is ready, the server will open a new > > connection to the client's HTTP server and pass the response over > > that. > > > > The reason we wrote the non-blocking transport is that we wanted to be > > asynchronous even in the case where WS-Addressing ISN'T being used. In > > other words, the client has an open socket to the server, but we > > didn't want to block a thread waiting for the socket. > hi Paul, > > but that puts very high burden on server and TCP stack (assuming that > you modified kernel to allow more than usual 1000 socket per process) > and it is not robust in case when client needs to wait for response > longer than few minutes (i have example applications that use WSA to > wait for response for hours or days). > > so what is the advantage of not using WSA? > > > > > > We looked at both Mina and AsyncWeb but AsyncWeb doesn't support a > > client model, so we based our code on the Jakarta HTTPCore project > > which also has NIO support. > > > > BTW Another truly asynchronous protocol we support is SMTP. > SMTP is exactly like WSA+SOAP+HTTP with non-anonymous ReplyTo - and as > history shows that seems to work very well ... > > thanks, > > alek > > > > Paul > > > > On 2/13/07, Michele Mazzucco <[EMAIL PROTECTED]> wrote: > >> Hi all, > >> > >> the addressing module allows for asynchronous messaging. However the > >> used transport mechanisms are synchronous (at least tcp and http). Since > >> alternatives exist (e.g. [1, 2]), is there any future plan to take > >> advantage of fully asynchronous computation? > >> > >> > >> Thanks, > >> Michele > >> > >> > >> [1] http://mina.apache.org/index.html > >> [2] http://docs.safehaus.org/display/ASYNCWEB/Home > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > -- > The best way to predict the future is to invent it - Alan Kay > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Paul Fremantle VP/Technology, WSO2 and OASIS WS-RX TC Co-chair http://bloglines.com/blog/paulfremantle [EMAIL PROTECTED] "Oxygenating the Web Service Platform", www.wso2.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
