Noted. Thanks & Best Regards, Irunika
*Irunika Weeraratne* *Software Engineer | WSO2, Inc. <http://wso2.com/>* *Email : [email protected] <[email protected]>* *LinkedIn : https://lk.linkedin.com/in/irunika <https://lk.linkedin.com/in/irunika>* *Mobile : +94712403314* *Lean . Enterprise . Middleware* On Thu, Dec 15, 2016 at 6:18 PM, Kishanthan Thangarajah <[email protected] > wrote: > > > On Thu, Dec 15, 2016 at 11:06 AM, Irunika Weeraratne <[email protected]> > wrote: > >> Hi, >> Since there were issues with the initial design as mentioned in this mail >> thread We came up with a new design. >> >> >> With this design, we can decouple MSF4J from Carbon-Transport. >> The Responder is a newly added interface to Carbon-Messaging and it is >> implemented in Carbon-Transport. This Responder is responsible for >> handling server pushes. >> Also a new CarbonMessage type is added to Carbon-Messaging as >> WebSocketCarbonMessage to handle WebSocket messages. >> This WebSocketCarbonMessage will be extended to work with different kinds >> of WebSocketCarbonMessages >> >> - TextWebSocketMessage >> - BinaryWebSocketMessage >> - PingWebSocketMessage >> - PongWebSocketMessage >> - CloseWebSocketMessage >> >> All the implementations in MSF4J will be done according to JSR 356 spec. >> > > +1, we can proceed with this approach. This will make MSF4J not to depend > on transport f/w directly. > > Thanks, > Kishanthan. > > >> WDYT? >> >> Thanks & Best Regards, >> Irunika >> >> *Irunika Weeraratne* >> *Software Engineer | WSO2, Inc. <http://wso2.com/>* >> *Email : [email protected] <[email protected]>* >> *LinkedIn : https://lk.linkedin.com/in/irunika >> <https://lk.linkedin.com/in/irunika>* >> *Mobile : +94712403314 <+94%2071%20240%203314>* >> *Lean . Enterprise . Middleware* >> >> >> On Fri, Dec 9, 2016 at 4:14 PM, Irunika Weeraratne <[email protected]> >> wrote: >> >>> Hi all, >>> In the current architecture, we can't have multiple Carbon Message >>> Processors. So if we want to give WebSocket support to MSF4J we have to >>> implement it inside MSF4J Core. If we do so MSF4J might get slower since it >>> needs to check whether every incoming message is a WebSocket message or a >>> HTTP message. >>> Also for Server-Push we have to add another interface to Carbon-Messaging >>> So what would be the better approach? >>> >>> Thanks, >>> Irunika >>> >>> *Irunika Weeraratne* >>> *Software Engineer | WSO2, Inc. <http://wso2.com/>* >>> *Email : [email protected] <[email protected]>* >>> *LinkedIn : https://lk.linkedin.com/in/irunika >>> <https://lk.linkedin.com/in/irunika>* >>> *Mobile : +94712403314 <+94%2071%20240%203314>* >>> *Lean . Enterprise . Middleware* >>> >>> >>> On Fri, Dec 9, 2016 at 12:07 PM, Irunika Weeraratne <[email protected]> >>> wrote: >>> >>>> Hi all, >>>> After the offline discussion with Azeez and Kishanthan, we identified 2 >>>> main issues with the current approach >>>> >>>> 1. Current design compromises the very reason of putting the >>>> Carbon-Messaging in between Carbon-Transport and MSF4J which is >>>> decoupling >>>> the Transport layer from MSF4J since it has a direct dependency to >>>> Carbon-Transport from MSF4J. >>>> So now we intend to add new interfaces and extended CarbonMessages >>>> to Carbon-Messaging which are compatible with WebSocket protocol. >>>> 2. We have to think about the Load Balancer awareness of a given >>>> WebSocket connection since the WebSocket connection should be persistent >>>> until the client or the server closes it. So we have to identify how we >>>> can >>>> persist the connection in server side with multiple nodes. >>>> >>>> Will come up with a design and update. >>>> If you have any thoughts please share. >>>> >>>> *Irunika Weeraratne* >>>> *Software Engineer | WSO2, Inc. <http://wso2.com/>* >>>> *Email : [email protected] <[email protected]>* >>>> *LinkedIn : https://lk.linkedin.com/in/irunika >>>> <https://lk.linkedin.com/in/irunika>* >>>> *Mobile : +94712403314 <+94%2071%20240%203314>* >>>> *Lean . Enterprise . Middleware* >>>> >>>> >>>> On Wed, Dec 7, 2016 at 3:31 PM, Irunika Weeraratne <[email protected]> >>>> wrote: >>>> >>>>> Hi, >>>>> I'm currently working on the implementation of WebSocket support for >>>>> MSF4J. >>>>> >>>>> *Overview* >>>>> >>>>> >>>>> Currently, Carbon-Transport only supports HTTP. So we need to give it >>>>> the ability to handle WebSocket Frames. >>>>> Also, we are planning to use existing Carbon-Messaging to process >>>>> incoming messages. But in WebSocket, a response for a request is not a >>>>> must. User has to handle it if there is a need of sending a response. >>>>> Also, we need to give the user the ability to do server pushes using >>>>> the WebSocket Sessions and to do so we need to have the reference of >>>>> Netty's Channel Handler Context. >>>>> >>>>> In MSF4J >>>>> >>>>> - Need a separate Registry to register WebSocket EndPoints since >>>>> WebSoocket EndPoints are different from MicroServices >>>>> - Message Processor gets the correct EndPoint from the registry >>>>> and dispatch the message >>>>> >>>>> >>>>> Any thoughts? >>>>> >>>>> Thanks & Best Regards, >>>>> Irunika >>>>> *Irunika Weeraratne* >>>>> *Software Engineer | WSO2, Inc. <http://wso2.com/>* >>>>> *Email : [email protected] <[email protected]>* >>>>> *LinkedIn : https://lk.linkedin.com/in/irunika >>>>> <https://lk.linkedin.com/in/irunika>* >>>>> *Mobile : +94712403314 <+94%2071%20240%203314>* >>>>> *Lean . Enterprise . Middleware* >>>>> >>>>> >>>> >>> >> > > > -- > *Kishanthan Thangarajah* > Technical Lead, > Platform Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 <+94%2077%20342%206635> > Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* > Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
