For this requirement, can we follow the same approach of how
carbon-transports and carbon-messaging layers have been developed with the
abstraction where you can plugin any transports and/or any message types
associated with transports for processing?

On a related note, In kernel we have the managed transports concept, where
the kernel manages the lifecycle of all transports such as start, stop,
begin maintenance, etc [1].

Thanks,
Kishanthan.
[1]
https://github.com/wso2/carbon-kernel/blob/master/core/src/main/java/org/wso2/carbon/kernel/transports/CarbonTransport.java

On Tue, Feb 9, 2016 at 4:36 PM, Selvaratnam Uthaiyashankar <shan...@wso2.com
> wrote:

>
>
> On Tuesday, February 9, 2016, Pamod Sylvester <pa...@wso2.com> wrote:
>
>> Hi All,
>>
>> Currently transports (AMQP,MQTT) in MB are coupled with the andes core
>> (same bundle). We're in process of identifying a way to abstract the
>> transports from its core, so that we bring in a pluggable architecture
>> which would allow plug in the relevant transport to the broker on demand.
>> This will help to featherweight MB.
>>
>> The abstract message flow would look like the following,
>> [image: Inline image 2]
>> As depicted in the above diagram, if the transport is abstracted into a
>> separate bundle, there will be circular dependency between the core and the
>> transport. i.e when messages are published 'transport' will need to call
>> services in the 'core' and when messages are distributed to the subscribers
>> the 'core' will need to call services in the 'transport'
>>
>
> When we have multiple transports, how the core knows which transport to
> call to distribute messages to subscribers? Isn't the core suppose to call
> an "interface", so that the core doesn't know about any concrete
> transports? If so, there won't be any circular dependencies, right?
>
>
>
>>
>> Currently we're in the process of identifying a solution for the circular
>> dependency, making the cardinality of one of the referencing service
>> optional [1] could be a solution, but we need to understand whether there's
>> a better approach for this.
>>
>> WDYT ?
>>
>> [1]
>> http://docs.spring.io/osgi/docs/current/api/org/springframework/osgi/service/importer/support/Cardinality.html
>>
>> Thanks,
>> Pamod
>> --
>> *Pamod Sylvester *
>>
>> *WSO2 Inc.; http://wso2.com <http://wso2.com>*
>> cell: +94 77 7779495
>>
>
>
> --
> S.Uthaiyashankar
> VP Engineering
> WSO2 Inc.
> http://wso2.com/ - "lean . enterprise . middleware"
>
> Phone: +94 714897591
>
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Kishanthan Thangarajah*
Associate Technical Lead,
Platform Technologies Team,
WSO2, Inc.
lean.enterprise.middleware

Mobile - +94773426635
Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to