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. 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* *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* >>> >>> >> >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
