Hi Deepal, I realised you have deferent opinion on this project and I respect to your idea but my way of thinking about this project is somewhat different from yours. During recent past I worked on Tomcat and Tyrus WebSocket implementations and inspired by performance gain and new use cases supported, that is why I suggested this idea to Gihan and few other people.
1.) This idea of "SOAP over WebSocket" from Gihan is bit of misleading in fact my original suggestion is to support SOAP and other content types such as POX, JSON as well. For me the main advantage is performance. - Compare to half-duplex HTTP transport WebSocket transport can perform much better due to it's in-built full-duplex nature. - Unlike HTTP WebSocket does not require upstream and downstream connections instead operate on single connection. - Compare to HTTP connection management is much simple. - Can co-exist with HTTP due to connection negotiation at HTTP servers. - Can support almost all the features provided by HTTP ( e.g - secure and insecure communications ) - There are some WebSocket benchmark results available here [1] [2]. - In addition to core WebSocket protocol there are some ongoing effort to further improve performance through WebSocket Extensions in future we can leverage them too. ( As an example - Compression Extensions for WebSocket [3] ) 2.) Axis2 HTTP/S based callbacks architecture is mainly used for asynchronous web service calls and for a given invocation it can send at most one response from server to client, AFAIK it's not fair to compare HTTP half-duplex callbacks architecture with full-duplex notification-like-model facilitated by WebSocket. In WebSocket scenario once the connection established client and server can send-receive messages in full-duplex manner. 3.) In my POV other web service frameworks are also having discussions to support WebSocket transport, as an example refer this [4] where Microsoft is tying to standardise SOAP over WebSocket [4]. 4.) Axis2 Transport is being used as the common transport architecture for both Axis2 and Synapse. I believe Synapse can use WebSocket for number of mediation use cases. Similar mediation framework such as Apache Camel already support for WebSocket I believe Spring-Integration will support too. Of course we can implement this transport under Synapse but implementing this under Axis2 project means it can be used with both projects. [1] - http://eng.42go.com/secure-websockets-vs-https-benchmark/ [2] - http://blog.artillery.com/2012/06/websocket-performance.html [3] - http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-17 [4] - http://msdn.microsoft.com/en-us/library/hh536812.aspx [5] - https://camel.apache.org/websocket.html Thanks ! On Thu, Mar 20, 2014 at 9:30 PM, Deepal jayasinghe <deep...@gmail.com> wrote: > Hi Gihan, Thanks for the updates and information, please see my comments > below. >> >> Hi Andreas, >> >> Thanks for your comment. I prepared following list of use cases and I >> will try to find more use cases. >> >> 1. As WebSocket protocol is based on full-duplex single connection >> above suggested new transport will reduce unnecessary network traffic >> and latency. Due to above advantages WebSocket transport will be a >> preferable choice for performance centric web service applications. >> >> 2. As far as i know existing Axis2 transports are not designed to >> support use cases like notification from server side. > Of course Axis2 supports that, in Axis2 you can send message from one > transport and receive the response from another transport. >> Another use case of this suggested new transport is it can be used to >> develop a server side notification application. As an example after >> opening a connection client can wait to receive notifications from the >> server. > It already there, and we have implemented that using callbacks. >> >> 3. I don't have much knowledge about Apache Synapse project but it >> looks like suggested new transport can be used with Apache Synapse >> too. I found following page from Apache Camel web site >> (https://camel.apache.org/websocket.html) may be suggested new >> transport can be used to develop similar use cases. > > I am not sure who wants to do streaming application on top of very > expensive message format like SOAP. So this transport is YAGNI to me. > But if you really want, go ahead and add support for WebSocket. This is > not mean to discourage you, but I do not see a real use case of a new > transport. > > Deepal >> >> 4. Additionally following two pages contain number of other >> advantages of WebSocket. >> >> https://www.websocket.org/quantum.html >> https://www.engineyard.com/articles/websocket >> >> Regards, >> >> Gihan >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org > For additional commands, e-mail: java-user-h...@axis.apache.org > -- Sagara Gunathunga Blog - http://ssagara.blogspot.com Web - http://people.apache.org/~sagara/ LinkedIn - http://www.linkedin.com/in/ssagara --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@axis.apache.org For additional commands, e-mail: java-user-h...@axis.apache.org
