+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 : [email protected] <[email protected]>* *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 <[email protected]> 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 <[email protected]> > 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 <[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 <+94%2077%20333%207238> >> https://wso2.com <https://wso2.com/signature> >> >> >> >> >> >> >> > > > -- > Regards, > *Shafreen* > Software Engineer > WSO2 Inc > Mobile : 077-556-395-1 >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
