Hi Asanka/Vinod, Andes can be considered as the transport whereas Carbon-business-Messaging can be seen as the functional component.
>> Should we allow AMQP transport (Andes) to be configured separately? >> Will other protocols be introduced in future (i.e MQTT) so we have to keep their configs separately? >> All other broker related functional configs (monitoring/JMX/Users) can be kept in as CBM configurations? Thanks On Fri, Sep 15, 2017 at 11:57 AM, Vinod Kavinda <[email protected]> wrote: > Hi Asanka, > I was referring to the configs that are used in Andes (by reading from > broker.xml). Yes, we don't need to keep them in the server config. > > Regards, > Vinod > > On Fri, Sep 15, 2017 at 11:54 AM, Asanka Abeyweera <[email protected]> > wrote: > >> Hi Vinod, >> >> What do you mean by the client configs here? Can you give an example? >> Ideally, we should not keep any client specific configs in >> deployment.yml (or broker.xml) since the client can reside in a completely >> different server instance. >> >> On Fri, Sep 15, 2017 at 11:32 AM, Vinod Kavinda <[email protected]> wrote: >> >>> Hi All, >>> I'm working on providing support for yaml based configuration in MB4 >>> based on the C5 model. >>> >>> In C4, we had a component in the Andes to read configurations from the >>> broker.xml file. With the C5 model, there will be only one config >>> (deployment.yaml) and components can define their own configs with an >>> object model using a unique namespace. >>> >>> So, where should we add the configuration models in MB4? >>> >>> 1. We cannot add in Carbon-business-messaging(CBM) component since >>> this will introduce a circular dependency with the Andes component, >>> because >>> Andes also need to read configurations and CBM already depends on Andes. >>> 2. We can add the configs in Andes component. This is the existing >>> architecture. But, since we have plans to keep Andes only as the client >>> in >>> the future, it will look ugly too when CBM component is reading configs >>> via >>> Andes. >>> 3. We can separate the configurations with two namespaces >>> (broker,andes) and keep the respective configuration models in both >>> places. >>> However, the configs will end-up in the same deployment.yaml file with >>> different namespaces. >>> >>> I would prefer the third option. Because eventually, we will have to do >>> this any way, to separate out the client and broker configs. >>> >>> Please share your thoughts. >>> >>> Regards, >>> Vinod >>> >>> >>> >>> >>> Vinod Kavinda >>> Senior Software Engineer >>> *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.* >>> Mobile : +94 (0) 712 415544 >>> Blog : http://soatechflicks.blogspot.com/ >>> [image: http://wso2.com/signature] >>> <http://wso2.com/signature> >>> >>> >> >> >> -- >> Asanka Abeyweera >> Associate Technical Lead >> WSO2 Inc. >> >> Phone: +94 712228648 <+94%2071%20222%208648> >> Blog: a5anka.github.io >> >> <https://wso2.com/signature> >> > > > > -- > Vinod Kavinda > Senior Software Engineer > *WSO2 Inc. - lean . enterprise . middleware <http://www.wso2.com>.* > Mobile : +94 (0) 712 415544 > Blog : http://soatechflicks.blogspot.com/ > [image: http://wso2.com/signature] > <http://wso2.com/signature> > > -- *Hasitha Abeykoon* Senior Software Engineer; WSO2, Inc.; http://wso2.com *cell:* *+94 719363063* *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
