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 <[email protected]> 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 the moment. We > have Carbon-Messaging component which provides all the aforementioned > common classes. Both transport developers and engine developers have to > depend on these common classes to provide their own implementations as in > the below diagram. > > > > However, over time it was realized that having a common abstraction is > difficult and raised a few discussion points. > > Following are the main discussion points we had, > > 1) Different transport implementations require different CarbonMessage > types. > 2) CarbonCallBack only fits in for response/request paradigm. > 3) Having to write different transport dispatchers on the > CarbonMessageProcessor side. > > Considering all the above points it was decided that having a common > abstraction for all the different types of transports is not easy. Mainly > because they are inherently different from one another. After all, > Carbon-Messaging [1] component was only helpful to decouple Transports from > run-time engine at compile time. During run time those two components were > decoupled using OSGi service registry. Hence, necessity for > Carbon-Messaging repo is little. > > With the new design, we are planning to allow each transport > implementation to have their own CarbonMessageProcessor, CarbonMessage and > CarbonCallBack. Therefore, they will be used as different libraries. > Following diagram depicts the concept. > > > > As you can see, the main difference is there is no single entry point from > transport to Ballerina run-time as each transport will have its own > MessageProcessor. To begin with we thought of working on HTTP Transport and > Websockets transport. Will send another mail explaining the required > changes in HTTP and Websockets transport to support the new concept. > > [1] https://github.com/wso2/carbon-messaging > > -- > Regards, > *Shafreen* > Software Engineer > WSO2 Inc > Mobile : 077-556-395-1 > -- Thank you and Best Regards, Chanaka Fernando Senior Technical Lead m: +94 773337238 https://wso2.com <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
