[Architecture] WebSocket support for MSF4J
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 : irun...@wso2.com * *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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] WebSocket support for MSF4J
Hi Thusitha, Thank you for the feedback. Best regards, Irunika *Irunika Weeraratne* *Software Engineer | WSO2, Inc. <http://wso2.com/>* *Email : irun...@wso2.com * *LinkedIn : https://lk.linkedin.com/in/irunika <https://lk.linkedin.com/in/irunika>* *Mobile : +94712403314* *Lean . Enterprise . Middleware* On Wed, Dec 7, 2016 at 3:52 PM, Thusitha Thilina Dayaratne < thusit...@wso2.com> wrote: > Hi Irunika, > > +1 for the idea. > As you mentioned we need to have a separate registry for websockets. > We need support this for both OSGi and fat jar mode. > > Thanks > > On Wed, Dec 7, 2016 at 3:31 PM, Irunika Weeraratne > 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 : irun...@wso2.com * >> *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 >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Thusitha Dayaratne > Software Engineer > WSO2 Inc. - lean . enterprise . middleware | wso2.com > > Mobile +94712756809 <+94%2071%20275%206809> > Blog alokayasoya.blogspot.com > Abouthttp://about.me/thusithathilina > <http://wso2.com/signature> > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] WebSocket support for MSF4J
Hi Sagara, Sorry for not mentioning them. I tried out [1] and [2] that you have mentioned in the above mail. All the implementations will be done according to JSR 356 spec. Developers only need to write their endpoints according to JSR 356 spec. [1] - https://www.jcp.org/en/jsr/detail?id=356 [2] - https://tyrus.java.net/ Thanks, Irunika *Irunika Weeraratne* *Software Engineer | WSO2, Inc. <http://wso2.com/>* *Email : irun...@wso2.com * *LinkedIn : https://lk.linkedin.com/in/irunika <https://lk.linkedin.com/in/irunika>* *Mobile : +94712403314* *Lean . Enterprise . Middleware* On Wed, Dec 7, 2016 at 6:11 PM, Sagara Gunathunga wrote: > > > On Wed, Dec 7, 2016 at 3:31 PM, Irunika Weeraratne > 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? >> > > You haven't mention about the programming model and developer experience > here, for MSF4J RESTful services we reuse subset of JAX-RS spec, IMO for > WebSocket we should use sub set of JSR 356 [1] (Java API for WebSocket) > spec instead of inventing our own programming model. You can tryout RI > samples from here [2]. > > > [1] - https://www.jcp.org/en/jsr/detail?id=356 > [2] - https://tyrus.java.net/ > > Thanks ! > > >> >> Thanks & Best Regards, >> Irunika >> *Irunika Weeraratne* >> *Software Engineer | WSO2, Inc. <http://wso2.com/>* >> *Email : irun...@wso2.com * >> *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 >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Sagara Gunathunga > > Associate Director / Architect; WSO2, Inc.; http://wso2.com > V.P Apache Web Services;http://ws.apache.org/ > Linkedin; http://www.linkedin.com/in/ssagara > Blog ; http://ssagara.blogspot.com > > > ___ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] WebSocket support for MSF4J
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 : irun...@wso2.com * *LinkedIn : https://lk.linkedin.com/in/irunika <https://lk.linkedin.com/in/irunika>* *Mobile : +94712403314* *Lean . Enterprise . Middleware* On Wed, Dec 7, 2016 at 3:31 PM, Irunika Weeraratne 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 : irun...@wso2.com * > *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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] WebSocket support for MSF4J
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 : irun...@wso2.com * *LinkedIn : https://lk.linkedin.com/in/irunika <https://lk.linkedin.com/in/irunika>* *Mobile : +94712403314* *Lean . Enterprise . Middleware* On Fri, Dec 9, 2016 at 12:07 PM, Irunika Weeraratne 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 : irun...@wso2.com * > *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 > 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 : irun...@wso2.com * >> *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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Improving clint-side rendering support in UUF
Hi,
Can't we use standard JS libraries approach for this one?
Here we have used zone names.
eg : UUF.renderFragment(fragmentFullyQualifedName, templateFillingObject,
*zoneName*, mode)
But AFAIK in standard JS this is done using Classes or IDs of elements.
For an example can't we have something similar to
*var zone = document.getElementById(zoneName);*
*UFF.renderFragment(par1, par2, par3, zone);*
IMHO I think that it would be better if we can find an approach which JS
developers are more often familiar with.
Also, IMHO I think we can use something similar to Jinja2 [1] kind of
approach from Python Flask for server-side template rendering.
[1] http://jinja.pocoo.org/docs/dev/
Thanks and Best Regards,
Irunika
*Irunika Weeraratne*
*Software Engineer | WSO2, Inc. <http://wso2.com/>*
*Email : irun...@wso2.com *
*LinkedIn : https://lk.linkedin.com/in/irunika
<https://lk.linkedin.com/in/irunika>*
*Mobile : +94712403314*
*Lean . Enterprise . Middleware*
On Wed, Dec 14, 2016 at 8:05 AM, Joseph Fonseka wrote:
> Hi
>
> +1, few clarifications bellow.
>
> 1. I guess the default mode will be OVERWRITE.
> 2. Why did we use comments to propagate Zones to the client side instead
> of Divs.
>
> Thanks
> Jo
>
>
>
> On Tue, Dec 13, 2016 at 10:37 PM, SajithAR Ariyarathna
> wrote:
>
>> Hi All,
>>
>> To do $subject, we are hoping to give a UUF client JS library. With the
>> client-side library, webapp developers will be able to render fragments and
>> push to zones similar to the server-side.
>>
>> Functions in the library:
>>
>> UUF.renderFragment(fragmentFullyQualifedName, templateFillingObject,
>> zoneName, mode)
>>
>> Using this function webapp developers can render a fragment in the
>> client-side and push the content to a given zone.
>>
>> Here,
>>
>> *fragmentFullyQualifedName* - Fully qualified name
>> (.) of the fragment that you want to
>> render. e.g. "org.wso2.carbon.apimgt.store.api-grid"
>> *templateFillingObject* - JSON object which will be used to fill the
>> fragment's template. e.g. {name: "My API", version: "1.0.0"}
>>
>> *zoneName* - Name of the zone that you want to push the rendered HTML.
>> e.g. "grid"
>>
>> *mode* - Dictates how the pushing content orders with the existing
>> content in the zone. Mode can be "PREPEND" (put the pushing content before
>> the existing content), "APPEND" (put the pushing content after the existing
>> content) or "OVERWRITE" (replace the existing content with the pushing
>> content)
>>
>>
>> UUF.renderTemplate(hbsTemplate, templateFillingObject, zoneName, mode)
>>
>> Using this function webapp devs can render a given Handlebars template
>> and push it to a desired zone.
>>
>> Here,
>>
>> *hbsTemplate* - Handlebars template string
>>
>>
>> Bringing zones to the client-side.
>>
>> When rendering a zone in the server-side, we can mark the start and end
>> of a zone's content with HTML comments.
>>
>> e.g.
>>
>>
>> content of zone grid goes here
>> here is a div
>> some more stuff
>>
>>
>> HTML comments can be identified by filtering nodes in the DOM. And
>> further filtering the comments that starts with [UUF-ZONE], we can
>> identify UUF zone marking comments. Jerad did a POC for this. In that we
>> were able to successfully identify zones and push content for all modes.
>>
>>
>> We are hoping to expose this library through the "uuf-client" fragment in
>> the common "foundation" component [1].
>>
>> [1] https://github.com/wso2/carbon-uuf-common/tree/master/compo
>> nents/org.wso2.carbon.uuf.common.foundation
>>
>> WDYT?
>>
>> Thanks.
>> --
>> Sajith Janaprasad Ariyarathna
>> Software Engineer; WSO2, Inc.; http://wso2.com/
>> <https://wso2.com/signature>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * <http://lk.linkedin.com/in/rumeshbandara>*
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] WebSocket support for MSF4J
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 : irun...@wso2.com * *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 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 : irun...@wso2.com * > *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 > 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 : irun...@wso2.com * >> *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 >> 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 : irun...@wso2.com * >>> *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 Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] WebSocket support for MSF4J
Noted. Thanks & Best Regards, Irunika *Irunika Weeraratne* *Software Engineer | WSO2, Inc. <http://wso2.com/>* *Email : irun...@wso2.com * *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 wrote: > > > On Thu, Dec 15, 2016 at 11:06 AM, Irunika Weeraratne > 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 : irun...@wso2.com * >> *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 >> 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 : irun...@wso2.com * >>> *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 >>> 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 : irun...@wso2.com * >>>> *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 >>>> wrote: >>>> >>>>>
Re: [Architecture] WebSocket support for MSF4J
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 : irun...@wso2.com * *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 wrote: > Noted. > > Thanks & Best Regards, > Irunika > > *Irunika Weeraratne* > *Software Engineer | WSO2, Inc. <http://wso2.com/>* > *Email : irun...@wso2.com * > *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 < > kishant...@wso2.com> wrote: > >> >> >> On Thu, Dec 15, 2016 at 11:06 AM, Irunika Weeraratne >> 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 : irun...@wso2.com * >>> *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 >>> 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 : irun...@wso2.com * >>>> *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 >>>> wrote: >>>> >>>>> Hi all, >>>>> After the offline disc
Re: [Architecture] WebSocket support for MSF4J
Hi Lakshman, On Wed, Jan 18, 2017 at 2:57 PM, Lakshman Udayakantha wrote: > I think you don't have to specially implement authentication mechanism for > web socket protocol. According to the spec[1], websocket doesn't provide > a way to authenticate clients. You can use any other mechanism with HTTPS > or HTTP etc. to authenticate the server. > > This protocol doesn't prescribe any particular way that servers can > authenticate clients during the WebSocket handshake. The WebSocket server > can use any client authentication mechanism available to a generic HTTP > server, > > such as cookies, HTTP authentication, or TLS authentication. > > > [1] https://tools.ietf.org/html/rfc6455 > Yes. They are not providing a mechanism and I'm trying to reuse the existing authentication mechanisms for Microservices in MSF4J. Most probably it will work since there is no any difference between a HTTP request and WebSocket Upgrade Request. Now I'm working on it. Thanks, Irunika *Irunika Weeraratne* *Software Engineer | WSO2, Inc. <http://wso2.com/>* *Email : irun...@wso2.com * *LinkedIn : https://lk.linkedin.com/in/irunika <https://lk.linkedin.com/in/irunika>* *Mobile : +94712403314* *Lean . Enterprise . Middleware* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] [CARBON-TRANSPORT][CARBON-MESSAGING] Client Connector Modifications
Hi all, Current client connector is written to work with HTTP request-response model. But protocols like WebSocket are not work in that way. So it is difficult to implement and maintain the code with more complex logic in the application layer. This can be resolved by introducing new APIs to the Client Connector. Please find the doc below for the complete details https://docs.google.com/a/wso2.com/document/d/1FCO_-Q7hGR4u4AWObTuuy5VwS2sXxKvYUDzkN5XCSqI/edit?usp=sharing Thanks, Irunika *Irunika Weeraratne* *Software Engineer | WSO2, Inc. <http://wso2.com/>* *Email : irun...@wso2.com * *LinkedIn : https://lk.linkedin.com/in/irunika <https://lk.linkedin.com/in/irunika>* *Mobile : +94712403314* *Lean . Enterprise . Middleware* ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [CARBON-TRANSPORT][CARBON-MESSAGING] Client Connector Modifications
Hi all, During the implementation, I came across some issues. In Ballerina point of view, there can be multiple WebSocket client connectors for a given server endpoint. Which means according to the above diagram the step 9 is not valid for such a scenario. Because for a given server session there can be multiple client sessions available. IMHO to avoid that we need to have a mapping in the application layer (Ballerina) rather than handling it in the transport layer. WDYT? Thanks, Irunika *Irunika Weeraratne* *Software Engineer | WSO2, Inc. <http://wso2.com/>* *Email : irun...@wso2.com * *LinkedIn : https://lk.linkedin.com/in/irunika <https://lk.linkedin.com/in/irunika>* *Mobile : +94712403314* *Lean . Enterprise . Middleware* On Mon, Jul 10, 2017 at 3:18 PM, Shafreen Anfar wrote: > Hi All, > > Original purpose of this mail was to discuss websockets implementation > changes. Hence this mail :) > > With the new client-connector and server-connector api, it should be able > to return a webscoket session upon connection establishment. Since > websockets is full duplex both client and sever side implementations should > be symmetric. Hence, we are planning to alter the existing implementation a > bit. Suppose, we have a passthrue scenario where inbound and outbound > connections are websockets. In such case, what happens under the hood is > something as below, > > > > Basically what happens is when a client initiate a websockets handshake, > on the server side there will be a new SourceHandler instance. For that > SourceHandler instance, we will be associating the respective > client-session. Similarly on the client side there will be a new > TargetHandler instance for each websockets connection. For that > Targethandler instance will be associating the respective server-session. > None of these sessions will be shared between other users or services. > Numbers explain the order of events. > > Please let us know your opinion as well :) > > @Irunika - Please correct me if I am wrong. > > On Tue, Jul 4, 2017 at 6:14 PM, Irunika Weeraratne > wrote: > >> Hi all, >> Current client connector is written to work with HTTP request-response >> model. But protocols like WebSocket are not work in that way. So it is >> difficult to implement and maintain the code with more complex logic in the >> application layer. >> This can be resolved by introducing new APIs to the Client Connector. >> >> Please find the doc below for the complete details >> https://docs.google.com/a/wso2.com/document/d/1FCO_-Q7hGR4u4 >> AWObTuuy5VwS2sXxKvYUDzkN5XCSqI/edit?usp=sharing >> >> Thanks, >> Irunika >> >> *Irunika Weeraratne* >> *Software Engineer | WSO2, Inc. <http://wso2.com/>* >> *Email : irun...@wso2.com * >> *LinkedIn : https://lk.linkedin.com/in/irunika >> <https://lk.linkedin.com/in/irunika>* >> *Mobile : +94712403314 <+94%2071%20240%203314>* >> *Lean . Enterprise . Middleware* >> >> > > > -- > Regards, > *Shafreen* > Software Engineer > WSO2 Inc > Mobile : 077-556-395-1 > ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [CARBON] C4 Migration from Log4J 1.x to Log4J 2.x
Hi Asma, > > The following approaches were found and evaluated to identify the most > suitable one. > >1. Using pax-logging >- The pax-logging api and the pax-logging-log4j bridge will have to be > used. > - Supposedly, pax-logging will feed the front-end logging into its > log4j back-end using its built-in adapter which we are trying to > achieve at the moment >2. Using Log4J 2.x > - This will need the log4j2-core, log4j2-api and the bridges to map > the front-end logging api to Log4J 2.x back-end > - Also this needs two OSGi fragments to customize the log4j-core > and log4j-api work in OSGi > - This requires the log4j2.properties file to be in the fragment > used with log4j-core and therefore, the file cannot be edited later > - Also, external .jar files are not able to find the logging > implementation which we are still investigating as to why this happens >3. Using both Log4j 1.x and 2.x > - While C4 will use the latter as the back-end, the external jars > needing v1 will use the former > - This could lead to threading issues since appenders from two > log4J versions will write to a single file simultaneously >4. Using the Log4J 1.x bridge [4] > - The Log4J 1.x jar is replaced with the 1.x bridge api and the > required log4j2 files. This will redirect all the logs from Log4j 1.x > to 2.x > - This only works if there are no custom appenders > > IMHO all these approaches also have a common issue. When we try to use any of those APIs we have to have to change our code base again and again according to the API we are using. IMO what we should do is write our own API for Logging and in the implementation, we can use any of those as the backend. So only the implementation will be changed while our code base remains same. Please find the diagram below. [image: Inline image 1] WDYT? Thanks and best regards, Irunika *Irunika Weeraratne* *Software Engineer | WSO2, Inc. <http://wso2.com/>* *Email : irun...@wso2.com * *LinkedIn : https://lk.linkedin.com/in/irunika <https://lk.linkedin.com/in/irunika>* *Mobile : +94712403314* *Lean . Enterprise . Middleware* On Wed, Jul 12, 2017 at 7:53 PM, Asma Jabir wrote: > Hi > > We have been looking into $subject and these are the findings we have > arrived at so far. > > Carbon 4.x.x currently uses Log4J 1.x as the logging back-end and > following will have to be done when migrating to Log4J 2.x. > >1. Rewriting custom appenders >- Current Log4J 1.x method - Rewriting of Logging Events by extending > appropriate classes (i.e.: > AppenderSkeleton/ConsoleAppender/DailyRollingFileAppender) > [1] > - Proposed Log4J 2.x method - Use of plugins to convert the log > record into a required pattern with custom fields [2] >2. Replace log4j.properties with a log4j2.properties file > - The properties file should be changed to log4j2.properties and > the syntax will different from v1 format [3] >3. Remove > - Direct use of log4j in org.wso2.carbon.server.Main - used to > remove all appenders added in the non-OSGi environment > - Package org.wso2.carbon.utils.logging.appenders as this should be > rewritten as converter plugins > > > The following approaches were found and evaluated to identify the most > suitable one. > >1. Using pax-logging >- The pax-logging api and the pax-logging-log4j bridge will have to be > used. > - Supposedly, pax-logging will feed the front-end logging into its > log4j back-end using its built-in adapter which we are trying to > achieve at the moment >2. Using Log4J 2.x > - This will need the log4j2-core, log4j2-api and the bridges to map > the front-end logging api to Log4J 2.x back-end > - Also this needs two OSGi fragments to customize the log4j-core > and log4j-api work in OSGi > - This requires the log4j2.properties file to be in the fragment > used with log4j-core and therefore, the file cannot be edited later > - Also, external .jar files are not able to find the logging > implementation which we are still investigating as to why this happens >3. Using both Log4j 1.x and 2.x > - While C4 will use the latter as the back-end, the external jars > needing v1 will use the former > - This could lead to threading issues since appenders from two > log4J versions will write to a single file simultaneously >4. Using the Log4J 1.x bridge [4] > - The Log4J 1.x jar is replaced with the 1.x bridge api and the > required log4j2 files. This will redirect all the logs from
Re: [Architecture] Restructuring CarbonMessageProcessor, CarbonMessage and CarbonCallBack
+1 for the idea. Followings will be the interfaces exposed from the transport-framework for WebSocket. - WebSocketMessageProcessor <https://github.com/irunika/carbon-transports/blob/websocket-messaging-framework/connector-framework/src/main/java/org/wso2/carbon/connector/framework/websocket/WebSocketMessageProcessor.java> - WebSocketTextMessage - WebSocketBinaryMessage - WebSocketCloseMessage - WebSocketInitMessage - WebSocketControlMessage Those message interfaces will have their own behavior and it can be directly exposed to the developers. This way we can avoid all the unnecessary castings and checks. Also, it will be easy to maintain. connector framework - https://github.com/irunika/carbon-transports/tree/websocket-messaging-framework/connector-framework/src/main/java/org/wso2/carbon/connector/framework Thanks, Irunika *Irunika Weeraratne* *Software Engineer | WSO2, Inc. <http://wso2.com/>* *Email : irun...@wso2.com * *LinkedIn : https://lk.linkedin.com/in/irunika <https://lk.linkedin.com/in/irunika>* *Mobile : +94712403314* *Lean . Enterprise . Middleware* On Tue, Aug 1, 2017 at 5:06 PM, Shafreen Anfar wrote: > Hi All, > > Sorry for the late reply. Was thinking about it deeply with different > options. > > Our plan is to move the interfaces in the carbon-messaging into > connector-framework. For each and every transport we will define the > contract (interfaces) of the service in the carbon-framework. Interested > parties can depend on transport-framework to use different transports. > > In case of HTTP, following are the interfaces that will be exposed from > the transport-framework. > > Common to all the transports > - ConnectorManager > - ServerConnector > > HTTP Specific > - HTTPMessage > - HTTPMessageProcessor > > Using ConnectorManager users of HTTPMessageProcessor can create new > server connectors. Then using HTTPMessageProcessor one can receive and send > requests and responses. Please find the new service contract for > HTTPMessageProcessor at [1]. > > In case of, websockets or any other protocol there might be another set of > specific interfaces. Therefore, whoever implements message processor will > have to do the necessary conversion. > > When it comes to dispatchers, apart from http dispatcher all the other > dispatchers (ftp, mail, jms, etc) are similar. Basically dispatch to the > service using the service name. Hence, I believe we should be able to come > up with a common dispatcher for all of them. > > [1] https://github.com/wso2/carbon-transports/tree/master/ > connector-framework > [2] https://github.com/shafreenAnfar/carbon-transports/blob/transport- > refactor/connector-framework/src/main/java/org/wso2/carbon/ > connector/framework/http/HTTPMessageProcessor.java > > On Fri, Jul 28, 2017 at 3:35 PM, Chanaka Fernando > wrote: > >> Could you also explain where the source code of each of these components >> resides in (e.g. for HTTP transport)? That will decide the extensibility of >> the ballerina transports. In the ESB world, we could write a transport and >> message builder/formatter as an extension and plug into the ESB runtime >> without changing the core ESB runtime. That was really useful for the >> customers when they want to extend the functionality of the ESB. >> >> Based on your diagram I can see 2 options. >> >> 1) Keep HTTP transport listener, HTTP transport sender in the >> carbon-transports repo (or some external repo) and keep HTTP dispatcher in >> the ballerina code base. If we go with this approach, every time we >> introduce a new transport, we have to change the ballerina core runtime >> (with the existing source repository structure). Which means there is >> minimum extensibility for third party users to write their own transports >> and use with ballerina. >> >> 2) Keep all HTTP transport listener, sender and dispatcher (which >> includes the message processor) within the carbon-transports repo (or some >> external repo) and plug them through common APIs to find services/resources >> at ballerina level. Which means that there is a common entry point at >> ballerina layer. This means higher extensibility and third party users can >> write their own transports and use with ballerina. >> >> On Fri, Jul 28, 2017 at 2:50 PM, Shafreen Anfar >> wrote: >> >>> Hi All, >>> >>> We had a meeting to discuss the subject. >>> >>> Participants - Azeez, Sameera, Chanaka, Anjana, Chamil, Pubudu, Irunika >>> and Chathurika >>> >>> Let me quickly explain how components are wired together using >>> CarbonMessageProcessor, CarbonMessage and CarbonCallBack at t
