Hi Kasun, Does the C5 ESB, GW and Carbon Transport has the message debug capability similarly what you are building with C4 mediation debugger capability at the moment?
If not it would be quite useful to build a mediation debugging capability as a core capability so that every product inherently have the capability. Once DevS team build the visual debugging interface users can use DevS to test and debug the implementations on the fly for any product. Thanks and Regards, Harshana On Tuesday, 19 January 2016, Kasun Indrasiri <[email protected]> wrote: > > > On Tue, Jan 19, 2016 at 11:50 AM, Kasun Indrasiri <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> Hi, >> >> This is a summary of how we support messaging with C5 ESB and GW. >> >> *Carbon Message [1] * >> - This is the generic message representation which contains message >> headers and reference to extract the message body (fully type-aware and no >> canonicalization required) >> - The idea is to use this as the generic message representation across >> the all the products that uses carbon-transport. >> >> *Carbon Transports* >> - Protocol handling layer that converts the wire msg -> carbon message >> (receiving) and carbon-message -> wire msg (sending). >> - The objective is to make sure all products can use same transports with >> generic message representation (without any canonicalized message such as >> SOAP). At the moment with C4, since we don't have a generic message >> representation, different products has to implement their own protocol >> handlers/transports to cater to their specific needs. (eg: ESB, CEP etc.) >> >> *Carbon Message Processor* (API) [2] >> - Any component that want to consume message from transport has to >> implement this and plug that in. >> - We use this mechanism to receive messages into the GW message >> processor/engine through the Netty transport [3]. >> - In addition you can use the TransportSender in case if you want to send >> message out from the message processor impl through any protocol. >> >> *CarbonCallback[4] * >> - We don't use in and out flow model any more in the new architecture. >> So, both request and response flows work asynchronously with the use of >> callbacks. (Idea is to later replace this with RxJava) >> >> I think all these things are completely independent from ESB/GW and can >> be used as the generic messaging architecture for C5. >> >> [1] >> https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonMessage.java >> [2] >> https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonMessageProcessor.java >> >> [3] >> https://github.com/wso2/product-gw/blob/master/carbon-gw/components/org.wso2.carbon.gateway/src/main/java/org/wso2/carbon/gateway/internal/mediation/camel/CamelMediationEngine.java >> >> [4] > https://github.com/wso2/carbon-messaging/blob/master/components/src/main/java/org/wso2/carbon/messaging/CarbonCallback.java > > >> @Shafreen/Senduran : Please add if anything else is missing. >> >> Thanks, >> -- >> Kasun Indrasiri >> Software Architect >> WSO2, Inc.; http://wso2.com >> lean.enterprise.middleware >> >> cell: +94 77 556 5206 >> Blog : http://kasunpanorama.blogspot.com/ >> > > > > -- > Kasun Indrasiri > Software Architect > WSO2, Inc.; http://wso2.com > lean.enterprise.middleware > > cell: +94 77 556 5206 > Blog : http://kasunpanorama.blogspot.com/ > -- Sent from Gmail Mobile for IPhone
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
