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 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
