Hi all,

Following are the areas we have identified that has a tight coupling with
Qpid (AMQP transport) and Andes core.

   - Andes core startup (starting message stores, scheduled tasks, ) is
   done within QPid at the moment. - *Need to seperate this out*
   - Andes Metadata implementation - *Need to come up with a generic model
   to handle metadata of different protocols.*
   - MBeans inside QPid. We used some of the mbeans in previous releases
   for UI. - Need to create a new set of mbeans for Andes core as needed since
   UI won't be relying on this mbeans in future.

In the effort to decouple transports and Andes core we will be looking at
afore mentioned areas to decouple Qpid and Andes core.

Regards,

Asitha





On Tue, Feb 9, 2016 at 11:56 PM, Kasun Indrasiri <ka...@wso2.com> wrote:

>
>
> On Tue, Feb 9, 2016 at 5:48 PM, Kishanthan Thangarajah <
> kishant...@wso2.com> wrote:
>
>> 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?
>>
>>
> Yes, please check the thread "GW/ESB5 messaging architecture" on
> architecture@. For GW/ESB we had a similar requirement and we introduced
> the carbon  message concept as the generic message representation in C5. I
> think you guys should use the same messaging architecture with MB, so that
> you can completely decouple protocol layer from your internal engine/core.
> Otherwise we'll end up having different design for inbound and outbound
> messaging for different products.
>
> Ideally we should use the same transport (for a given protocol) across the
> entire platform (say MQTT or AMQP) but there may some exceptions.
>
>> 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
>>
>>
>
>
> --
> Kasun Indrasiri
> Software Architect
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> cell: +94 77 556 5206
> Blog : http://kasunpanorama.blogspot.com/
>
> _______________________________________________
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Asitha Nanayakkara*
Software Engineer
WSO2, Inc. http://wso2.com/
Mob: +94 77 853 0682
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to