On Aug 14, 2013 4:55 AM, "Isuru Perera" <[email protected]> wrote: > > Well, if we support other Message Brokers with extension points, there is no need to start internal MB with Cassandra data store. > > I just need to decouple Message Broker from Cloud Controller since it brings lot of dependencies. As a result, I cannot proceed with jclouds upgrade due to dependency issue with guava libraries. (I mentioned this in another thread) >
Well, there should be another way to solve the original problem you have, instead of chosing the lazy path :-) > Since you started the discussion on supporting external topology publisher, I think it would a good starting point to remove MB features. Even running a message broker externally would be okay since this is a PaaS and it is just another process in the system. > Topic resides in whatever the message broker is of utmost importance for Apache Stratos to function properly. If we remove the default embedded MB, what would we ship by default? Initially we used an external MB, but why we decided to get only necessary MB related features was to minimize the # of JVMs and make it easily configurable. > If I understand correctly, your extension point is about adding another class. That is good if the new MB topology publisher is completely different, but we can simply support many more message brokers with a single class by providing relevant parameters, such as java.naming.factory.initial > Well this is an improvement that one could make. You have the foundation built, play wisely. (I personally am not familiar with those other MBs in town.) > For example, see [1] and [2]. Apache Axis2 uses only JMSListener class to support multiple message brokers. > > This is what I expect in the context of Apache Stratos also. As a start we can test Apache ActiveMQ and WSO2 Message Broker. > > I added https://issues.apache.org/jira/browse/STRATOS-52 to track this. > > [1] http://docs.wso2.org/wiki/display/ESB470/Configuring+JMS+Transport > [2] http://axis.apache.org/axis2/java/transports/jms.html > > > On Wed, Aug 14, 2013 at 4:31 PM, Nirmal Fernando <[email protected]> wrote: >> >> >> On Aug 10, 2013 7:14 AM, "Isuru Perera" <[email protected]> wrote: >> > >> > Hi all, >> > >> > >> > On Thu, Aug 8, 2013 at 9:13 AM, Isuru Perera <[email protected]> wrote: >> >> >> >> Hi, >> >> >> >> +1 for the approach! >> >> >> >> I think this is a good start to remove Message Broker features in Cloud Controller eventually. >> >> >> >> Perhaps we could modify the default implementation to be more generic as we could use AMQP. >> > >> > I would like to start working on this. (I think it's better to remove MB features from Cloud Controller and make it more light-weight. Right now it takes about 1 minute to start). >> > >> >> This is a PaaS and you do not do frequent restarts etc. Hence, IMO server start up time isn't a that critical concern. >> >> > We can then allow users to use any MB. Let's see whether we can use ActiveMQ and RabbitMQ >> > >> >> Your statement is misleading. We don't need to remove WSO2 MB features from CC in order to support other MBs. >> >> In fact the sole purpose of the email of mine was to introduce this extension point. >> IMO for the time being we just need to focus on using this extension point and provide support to other MBs. >> >> > I think this will not be a considerable effort. >> > >> > Suggestions? >> >> >> >> >> >> As you said, we could also have generic subscriber in ELB and Stratos Controller. >> >> >> >> I would like to see the code in Apache Git. :) >> >> >> >> Thanks! >> >> >> >> Best Regards, >> >> >> >> >> >> On Wed, Aug 7, 2013 at 10:35 PM, Nirmal Fernando < [email protected]> wrote: >> >>> >> >>> Hi All, >> >>> >> >>> I worked on the $subject as and when I got time. And believe that I clearly separated out and provided an extension point to add any custom topology publisher. >> >>> >> >>> While doing this I had to change the current configuration of topology publisher as below: >> >>> >> >>> <topologySync enable="true"> >> >>> <!-- properties related to topology syncher --> >> >>> <property name="className" value="org.apache.stratos.cloud.controller.ABC"/> >> >>> <property name="mbServerUrl" value="localhost:5674"/> >> >>> <property name="cron" value="1 * * * * ? *"/> >> >>> </topologySync> >> >>> >> >>> >> >>> If you want to plug a new implementation instead of using the default implementation (WSO2MBTopologyPublisher), you should extend the following abstract class and configure it using a property (eg: <property name="className" value="org.apache.stratos.cloud.controller.ABC"/>). >> >>> >> >>> package org.apache.stratos.cloud.controller.interfaces; >> >>> >> >>> /** >> >>> * All custom implementations of Topology Publisher should extend this abstract class. >> >>> */ >> >>> public abstract class TopologyPublisher { >> >>> >> >>> /** >> >>> * This operation will be called once in order to initialize this publisher. >> >>> */ >> >>> public abstract void init(); >> >>> >> >>> /** >> >>> * When a message is ready to be published to a certain topic, this operation will be called. >> >>> * @param topicName name of the topic to be published. >> >>> * @param message message to be published. >> >>> */ >> >>> public abstract void publish(String topicName, String message); >> >>> >> >>> /** >> >>> * Cron expression which explains the frequency that the topology publishing happens. >> >>> * @return cron expression >> >>> */ >> >>> public abstract String getCron(); >> >>> >> >>> } >> >>> >> >>> You have the freedom to get any necessary parameters for your custom topology publisher implementation, due to the nature of the configuration shown above. Any number of properties are allowed and those can be retrieved via the object model. >> >>> >> >>> eg: >> >>> >> >>> TopologyConfig config = FasterLookUpDataHolder.getInstance() >> >>> .getTopologyConfig(); >> >>> String cron = config.getProperty(CloudControllerConstants.CRON_ELEMENT); >> >>> >> >>> With this extension point in hand, you can easily make Cloud Controller to publish topology information into another topic provider (Qpid etc.). >> >>> >> >>> I invite you to leverage this capability and help Apache Stratos to be compatible with other message broker implementations. >> >>> >> >>> Thanks. >> >>> >> >>> PS: We need the same kind of extensibility in the subscriber side. I will have a look on to it too. >> >>> >> >>> -- >> >>> Best Regards, >> >>> Nirmal >> >>> >> >>> C.S.Nirmal J. Fernando >> >>> Senior Software Engineer, >> >>> WSO2 Inc. >> >>> >> >>> Blog: http://nirmalfdo.blogspot.com/ >> >> >> >> >> >> >> >> >> >> -- >> >> Isuru Perera >> >> about.me/chrishantha >> > >> > >> > >> > >> > -- >> > Isuru Perera >> > about.me/chrishantha > > > > > -- > Isuru Perera > about.me/chrishantha
