Hi all, Now there is a working model of $subject. *Features : *
- Can add WebSocket ServerEndpoints in OSGi environment dynamically. - Support for @PathParam annotation - Server push support These are the decisions made after the code review. - Migrate WebSocket Session implementation from MSF4J to Carbon-Transport so the same implementation can be used in other products too. - Since Carbon-Messaging is not depending on protocols, change the naming conventions of newly added message types so they can be reused. *ex : TextWebSocketMessage -> TextCarbonMessage Then add the protocol as a property to the CarbonMessage so message processor can identify the protocol using the property.* - Implement Secured WebSocket Support (WSS) for MSF4J. - Add authentication support for WebSocket - Implement support for fat jar mode so it can work in standalone mode. 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* *Lean . Enterprise . Middleware* On Fri, Dec 16, 2016 at 11:09 AM, Irunika Weeraratne <[email protected]> wrote: > 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 <+94%2071%20240%203314>* > *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
