Hi Shafreen, +1 for the proposed implementation. In MSF4J point of view, we are wrapping the carbon message with MSF4J Request/Response objects and use the underlying messaging methods provided to retrieve/write back data in/out/.
Are we considering a getting a message body clone with the re architrecture? Thanks Thusitha On Fri, Jul 7, 2017 at 6:18 PM, Shafreen Anfar <[email protected]> wrote: > Hi All, > > In addition to considering all the facts presented above, I also talked to > each transport developer who actually came up with different types of > carbon-messages. Based on those discussion I came up with below design. > > Originally, CarbonMessage is designed to carry data between two components > and I believe it should stay the same. However, it should be able carry > data relevant to each component. For instance, in JMS case, it should be > able carry a map for map messages where as in websockets case it should be > able carry a string. > > Therefore, I thought of creating a CarbonMessage with java generics. Then > we can extend it accordingly. > > > > As you can see above, we can provide a DefaultCarbonMessage > implementation. However, in HTTP case, we have done some specific > implementation to optimize the transport. At the moment those logic also > resides inside the abstract CarbonMessage. With the new design we can > simply move them to something like ByteCarbonMessage<ByteBuffer>. > > I believe with this design we can have proper abstraction while reducing > number of redundant carbon messages. > > > On Thu, Jul 6, 2017 at 12:16 AM, Chanaka Fernando <[email protected]> > wrote: > >> It seems there is room to improve the current CarbonMessage >> implementation. Following are few main areas where we can improve its >> functionality. >> >> - At the moment there are too many ways to get the message body from >> the CarbonMessage >> - getMessageBody() >> - getInputStream() - This is a http specific impl. >> - getMessageDateSource() >> >> The above 3 methods serve 3 different purposes. This design has been done >> mainly thinking about the HTTP messages. In a message passthrough scenario, >> content is kept in the content queue and accessed as a stream. When the >> message content is accessed within intermediate layer (like ballerina), it >> will be retrieved through messageDataSource. >> >> - There are too many types of CarbonMessages in carbon-messaging that >> are only used by a specific transport implementation >> - BinaryCarbonMessage >> - ControlCarbonMessage >> - DefaultCarbonMessage >> - MapCarbonMessage >> - SerializableCarbonMessage >> - StatusCarbonMessage >> - StreamingCarbonMessage >> - TextCarbonMessage >> >> >> - Most of above CarbonMessages do not adhere to the contract that is >> imposed by the CarbonMessage interface. >> >> I agree on the fact that we need to refactor these different types of >> CarbonMessage implementations. I think what Asitha suggested is a viable >> approach to handle different types of messages. >> >> Considering these facts, I believe we should refactor CarbonMessage >> before others starting using it in their implementations. Please let us >> know your thoughts as well :) >> >> +1 for refactoring the carbon message and relevant implementations to >> support non-HTTP use cases. In the meantime, we should support HTTP >> messaging in an efficient manner since that will be the mostly used >> scenario of ballerina. >> >> On Wed, Jul 5, 2017 at 4:55 PM, Irunika Weeraratne <[email protected]> >> wrote: >> >>> Hi Shafreen and Asitha, >>> In the first place, they were introduced after a long discussion in >>> WebSocket scenarios. This was because when the WebSocket messages are >>> arrived to transport level we already knew what kind of message it is. >>> Eg: Text, Binary, Control, Status >>> >>> So I made sense to create the same type of carbon message in the >>> transport. Then carbon message types were used to identify the scenarios we >>> had to address in the application layer. >>> Eg: If the carbon message is an instance of TextCarbonMessage we know >>> what to do in the first place. Also converting text into byte buffer in the >>> transport and then converting it again into text in the application layer >>> doesn't make sense. >>> >>> Because of that, those message types were introduced. IMO while we >>> reduce the no. of carbon message types we might need to keep some of the >>> types because it will affect the performance. >>> Also, we can always override the methods in default carbon message if in >>> order to work with default scenarios. >>> >>> WDYT? >>> >>> 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 <071%20240%203314>* >>> *Lean . Enterprise . Middleware* >>> >>> >>> On Wed, Jul 5, 2017 at 3:54 PM, Asitha Nanayakkara <[email protected]> >>> wrote: >>> >>>> Hi Shafreen, >>>> >>>> I would suggest having a single Carbon Message with the option to set >>>> different types of data sources as the data source for the message. For >>>> that, we might need to go through the existing other message types and >>>> think what kind of functionality to be added to carbon message. If our >>>> intention is not to extend carbon message, we can make it a final class. If >>>> not we have to design it to be extended by other users. >>>> >>>> When reading the payload multiple times (building the message) we need >>>> to clone messages (since data is represented as a stream). In pass through >>>> scenarios, we should avoid cloning the message and use the stream once. >>>> IMO we can implement this functionality by way of having package level >>>> methods for transport to read from the internal blocking queue and write to >>>> the output stream. If we invoke other public methods they will make a clone >>>> of the message data and use. This way we avoid unnecessary cloning in a >>>> pass-through scenario. And reading from the blocking queue can only be done >>>> from the transport. Outside users have to use message data source to read >>>> the content, which might clone the data. >>>> >>>> WDYT? >>>> >>>> Regards, >>>> Asitha >>>> >>>> On Wed, Jul 5, 2017 at 3:14 PM, Shafreen Anfar <[email protected]> >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> It seems there is room to improve the current CarbonMessage >>>>> implementation. Following are few main areas where we can improve its >>>>> functionality. >>>>> >>>>> - At the moment there are too many ways to get the message body >>>>> from the CarbonMessage >>>>> - getMessageBody() >>>>> - getInputStream() - This is a http specific impl. >>>>> - getMessageDateSource() >>>>> >>>>> >>>>> - There are too many types of CarbonMessages in carbon-messaging >>>>> that are only used by a specific transport implementation >>>>> - BinaryCarbonMessage >>>>> - ControlCarbonMessage >>>>> - DefaultCarbonMessage >>>>> - MapCarbonMessage >>>>> - SerializableCarbonMessage >>>>> - StatusCarbonMessage >>>>> - StreamingCarbonMessage >>>>> - TextCarbonMessage >>>>> >>>>> >>>>> - Most of above CarbonMessages do not adhere to the contract that >>>>> is imposed by the CarbonMessage interface. >>>>> >>>>> Considering these facts, I believe we should refactor CarbonMessage >>>>> before others starting using it in their implementations. Please let us >>>>> know your thoughts as well :) >>>>> >>>>> -- >>>>> Regards, >>>>> *Shafreen* >>>>> Software Engineer >>>>> WSO2 Inc >>>>> Mobile : 077-556-395-1 >>>>> >>>> >>>> >>>> >>>> -- >>>> *Asitha Nanayakkara* <http://asitha.github.io/> >>>> Senior Software Engineer >>>> WSO2, Inc. <http://wso2.com/> >>>> Mob: +94 77 853 0682 <+94%2077%20853%200682> >>>> [image: https://wso2.com/signature] <https://wso2.com/signature> >>>> >>>> >>> >> >> >> -- >> Thank you and Best Regards, >> Chanaka Fernando >> Senior Technical Lead >> m: +94 773337238 <+94%2077%20333%207238> >> https://wso2.com <https://wso2.com/signature> >> >> >> >> >> >> >> > > > -- > Regards, > *Shafreen* > Software Engineer > WSO2 Inc > Mobile : 077-556-395-1 > -- Thusitha Dayaratne WSO2 Inc. - lean . enterprise . middleware | wso2.com Mobile +94712756809 Blog alokayasoya.blogspot.com About http://about.me/thusithathilina <http://wso2.com/signature>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
