Hi All, We have completed the first phase of refactoring. New API can be found at [1]. Sample usages of server connector and client connector can be found at [2] and [3].
We will schedule a meeting to further explain the new API. [1] https://github.com/wso2/carbon-transports/tree/master/http/org.wso2.carbon.transport.http.netty/src/main/java/org/wso2/carbon/transport/http/netty/contract [2] https://github.com/wso2/carbon-transports/blob/master/http/org.wso2.carbon.transport.http.netty/src/test/java/org/wso2/carbon/transport/http/netty/util/TestUtil.java [3] https://github.com/wso2/carbon-transports/blob/master/http/org.wso2.carbon.transport.http.netty/src/test/java/org/wso2/carbon/transport/http/netty/passthrough/PassthroughMessageProcessorListener.java On Tue, Aug 1, 2017 at 5:30 PM, Irunika Weeraratne <[email protected]> wrote: > +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 <+94%2071%20240%203314>* > *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/co >> nnector-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 >> > > -- 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
