You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Nirmal Fernando <ni...@gmail.com> on 2013/08/07 19:05:23 UTC
Cloud Controller - Create an extension point to attach different
configuration (topology) publishers
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/
Re: Cloud Controller - Create an extension point to attach different
configuration (topology) publishers
Posted by Nirmal Fernando <ni...@gmail.com>.
On Thu, Aug 15, 2013 at 6:20 PM, Isuru Perera <ch...@gmail.com> wrote:
>
>
>
> On Thu, Aug 15, 2013 at 3:11 AM, Nirmal Fernando <ni...@gmail.com>wrote:
>
>>
>>
>>
>> On Wed, Aug 14, 2013 at 7:58 PM, Isuru Perera <ch...@gmail.com>wrote:
>>
>>>
>>> On Wed, Aug 14, 2013 at 7:02 PM, Nirmal Fernando <nirmal070125@gmail.com
>>> > wrote:
>>>
>>>>
>>>> On Aug 14, 2013 4:55 AM, "Isuru Perera" <ch...@gmail.com> 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 :-)
>>>>
>>> I agree that removing MB features is just an easy path to solve the
>>> original problem! But you cannot call it lazy, since I also plan to
>>> implement a workaround! :-)
>>>
>>> Besides, the problem is with external features and I'm just trying to
>>> solve it within Stratos code base.
>>>
>>>> > 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.
>>>>
>>> My point is that we do not need to bundle a Message Broker with Cloud
>>> Controller. We can initially support Apache ActiveMQ and WSO2 MB. We will
>>> provide detailed configuration steps in Cloud Controller for both. There is
>>> nothing to configure in Message Broker. Then users can choose a Message
>>> Broker of their choice without any complexity. Adding an extra JVM process
>>> in to the system is not an issue in my opinion.
>>>
>>
>> Well, if I am new to Apache Stratos and wanna try it out, I surely don't
>> want to do all those manual configurations etc.
>>
>> We should think from the user perspective as well and should not
>> discourage new users IMO.
>>
> I don't understand how this discourages new users. As I mentioned earlier,
> we will be providing all the required configurations with docs.
>
You'll realize it eventually.
> > 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'm working on the improvement. :)
>>>
>>
>> While you are trying to make a single class to support multiple
>> providers, you're making CC hard to configure.
>>
>> For an example currently to configure topology publisher, you only need
>> following:
>>
>>
>> <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>
>>
>> But if you make this change, a user need to have something like following
>> configuration:
>>
>>
>> <topologySync enable="true">
>> <!-- properties related to topology syncher -->
>> <property name="className"
>> value="org.apache.stratos.cloud.controller.ABC"/>
>> <property name="connectionfactory.qpidConnectionfactory"
>> value="amqp://admin:admin@clientID
>> /carbon?brokerlist='tcp://localhost:5674'"/>
>>
>> <property name="cron" value="1 * * * * ? *"/>
>> <property name="java.naming.factory.initial"
>> value="org.wso2.andes.jndi.PropertiesFileInitialContextFactory"/>
>> </topologySync>
>>
> This is much more cleaner to me than just specifying some class with all
> configuration details hidden. I'm thinking of a similar configuration for
> subscriber also.
>
> I think the current way of configuring the subscriber is also really
> confusing. There are two different ways to configure the subscriber in SC
> and ELB. For ELB you need to edit the loadbalancer.conf and for SC you have
> to use a startup parameter. As I remember, For ELB it's mb_server_url and
> for SC it's mb.server.ip. SC also has the same config in
> cartridge-config.properties as well and user need to have same config in
> both places
>
> We need to fix these inconsistencies.
>
>
Yes, yes. Any Software should be evolved by time, you can't hold a release
till it reach perfection (if you do hold, you will never able to do a
release).
This is my last email to this thread, I've more important work than arguing
here.
>
>> Let the community decide the best approach.
>>
> +1. May be we can start a new discussion thread.
>
>> (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 <
>>>> nirmal070125@gmail.com> wrote:
>>>> >>
>>>> >>
>>>> >> On Aug 10, 2013 7:14 AM, "Isuru Perera" <ch...@gmail.com>
>>>> wrote:
>>>> >> >
>>>> >> > Hi all,
>>>> >> >
>>>> >> >
>>>> >> > On Thu, Aug 8, 2013 at 9:13 AM, Isuru Perera <
>>>> chrishantha@gmail.com> 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 <
>>>> nirmal070125@gmail.com> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Isuru Perera
>>> about.me/chrishantha
>>>
>>
>>
>>
>> --
>> Best Regards,
>> Nirmal
>>
>> C.S.Nirmal J. Fernando
>> Senior Software Engineer,
>> WSO2 Inc.
>>
>> Blog: http://nirmalfdo.blogspot.com/
>>
>
>
>
> --
> Isuru Perera
> about.me/chrishantha
>
--
Best Regards,
Nirmal
C.S.Nirmal J. Fernando
Senior Software Engineer,
WSO2 Inc.
Blog: http://nirmalfdo.blogspot.com/
Re: Cloud Controller - Create an extension point to attach different
configuration (topology) publishers
Posted by Isuru Perera <ch...@gmail.com>.
On Thu, Aug 15, 2013 at 3:11 AM, Nirmal Fernando <ni...@gmail.com>wrote:
>
>
>
> On Wed, Aug 14, 2013 at 7:58 PM, Isuru Perera <ch...@gmail.com>wrote:
>
>>
>> On Wed, Aug 14, 2013 at 7:02 PM, Nirmal Fernando <ni...@gmail.com>wrote:
>>
>>>
>>> On Aug 14, 2013 4:55 AM, "Isuru Perera" <ch...@gmail.com> 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 :-)
>>>
>> I agree that removing MB features is just an easy path to solve the
>> original problem! But you cannot call it lazy, since I also plan to
>> implement a workaround! :-)
>>
>> Besides, the problem is with external features and I'm just trying to
>> solve it within Stratos code base.
>>
>>> > 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.
>>>
>> My point is that we do not need to bundle a Message Broker with Cloud
>> Controller. We can initially support Apache ActiveMQ and WSO2 MB. We will
>> provide detailed configuration steps in Cloud Controller for both. There is
>> nothing to configure in Message Broker. Then users can choose a Message
>> Broker of their choice without any complexity. Adding an extra JVM process
>> in to the system is not an issue in my opinion.
>>
>
> Well, if I am new to Apache Stratos and wanna try it out, I surely don't
> want to do all those manual configurations etc.
>
> We should think from the user perspective as well and should not
> discourage new users IMO.
>
I don't understand how this discourages new users. As I mentioned earlier,
we will be providing all the required configurations with docs.
> > 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'm working on the improvement. :)
>>
>
> While you are trying to make a single class to support multiple providers,
> you're making CC hard to configure.
>
> For an example currently to configure topology publisher, you only need
> following:
>
>
> <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>
>
> But if you make this change, a user need to have something like following
> configuration:
>
>
> <topologySync enable="true">
> <!-- properties related to topology syncher -->
> <property name="className"
> value="org.apache.stratos.cloud.controller.ABC"/>
> <property name="connectionfactory.qpidConnectionfactory"
> value="amqp://admin:admin@clientID
> /carbon?brokerlist='tcp://localhost:5674'"/>
>
> <property name="cron" value="1 * * * * ? *"/>
> <property name="java.naming.factory.initial"
> value="org.wso2.andes.jndi.PropertiesFileInitialContextFactory"/>
> </topologySync>
>
This is much more cleaner to me than just specifying some class with all
configuration details hidden. I'm thinking of a similar configuration for
subscriber also.
I think the current way of configuring the subscriber is also really
confusing. There are two different ways to configure the subscriber in SC
and ELB. For ELB you need to edit the loadbalancer.conf and for SC you have
to use a startup parameter. As I remember, For ELB it's mb_server_url and
for SC it's mb.server.ip. SC also has the same config in
cartridge-config.properties as well and user need to have same config in
both places
We need to fix these inconsistencies.
> Let the community decide the best approach.
>
+1. May be we can start a new discussion thread.
> (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 <
>>> nirmal070125@gmail.com> wrote:
>>> >>
>>> >>
>>> >> On Aug 10, 2013 7:14 AM, "Isuru Perera" <ch...@gmail.com>
>>> wrote:
>>> >> >
>>> >> > Hi all,
>>> >> >
>>> >> >
>>> >> > On Thu, Aug 8, 2013 at 9:13 AM, Isuru Perera <ch...@gmail.com>
>>> 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 <
>>> nirmal070125@gmail.com> 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
>>>
>>
>>
>>
>> --
>> Isuru Perera
>> about.me/chrishantha
>>
>
>
>
> --
> Best Regards,
> Nirmal
>
> C.S.Nirmal J. Fernando
> Senior Software Engineer,
> WSO2 Inc.
>
> Blog: http://nirmalfdo.blogspot.com/
>
--
Isuru Perera
about.me/chrishantha
Re: Cloud Controller - Create an extension point to attach different
configuration (topology) publishers
Posted by Nirmal Fernando <ni...@gmail.com>.
On Wed, Aug 14, 2013 at 7:58 PM, Isuru Perera <ch...@gmail.com> wrote:
>
> On Wed, Aug 14, 2013 at 7:02 PM, Nirmal Fernando <ni...@gmail.com>wrote:
>
>>
>> On Aug 14, 2013 4:55 AM, "Isuru Perera" <ch...@gmail.com> 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 :-)
>>
> I agree that removing MB features is just an easy path to solve the
> original problem! But you cannot call it lazy, since I also plan to
> implement a workaround! :-)
>
> Besides, the problem is with external features and I'm just trying to
> solve it within Stratos code base.
>
>> > 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.
>>
> My point is that we do not need to bundle a Message Broker with Cloud
> Controller. We can initially support Apache ActiveMQ and WSO2 MB. We will
> provide detailed configuration steps in Cloud Controller for both. There is
> nothing to configure in Message Broker. Then users can choose a Message
> Broker of their choice without any complexity. Adding an extra JVM process
> in to the system is not an issue in my opinion.
>
Well, if I am new to Apache Stratos and wanna try it out, I surely don't
want to do all those manual configurations etc.
We should think from the user perspective as well and should not discourage
new users IMO.
> > 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'm working on the improvement. :)
>
While you are trying to make a single class to support multiple providers,
you're making CC hard to configure.
For an example currently to configure topology publisher, you only need
following:
<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>
But if you make this change, a user need to have something like following
configuration:
<topologySync enable="true">
<!-- properties related to topology syncher -->
<property name="className"
value="org.apache.stratos.cloud.controller.ABC"/>
<property name="connectionfactory.qpidConnectionfactory"
value="amqp://admin:admin@clientID
/carbon?brokerlist='tcp://localhost:5674'"/>
<property name="cron" value="1 * * * * ? *"/>
<property name="java.naming.factory.initial"
value="org.wso2.andes.jndi.PropertiesFileInitialContextFactory"/>
</topologySync>
Let the community decide the best approach.
> (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 <
>> nirmal070125@gmail.com> wrote:
>> >>
>> >>
>> >> On Aug 10, 2013 7:14 AM, "Isuru Perera" <ch...@gmail.com> wrote:
>> >> >
>> >> > Hi all,
>> >> >
>> >> >
>> >> > On Thu, Aug 8, 2013 at 9:13 AM, Isuru Perera <ch...@gmail.com>
>> 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 <
>> nirmal070125@gmail.com> 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
>>
>
>
>
> --
> Isuru Perera
> about.me/chrishantha
>
--
Best Regards,
Nirmal
C.S.Nirmal J. Fernando
Senior Software Engineer,
WSO2 Inc.
Blog: http://nirmalfdo.blogspot.com/
Re: Cloud Controller - Create an extension point to attach different
configuration (topology) publishers
Posted by Isuru Perera <ch...@gmail.com>.
On Wed, Aug 14, 2013 at 7:02 PM, Nirmal Fernando <ni...@gmail.com>wrote:
>
> On Aug 14, 2013 4:55 AM, "Isuru Perera" <ch...@gmail.com> 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 :-)
>
I agree that removing MB features is just an easy path to solve the
original problem! But you cannot call it lazy, since I also plan to
implement a workaround! :-)
Besides, the problem is with external features and I'm just trying to solve
it within Stratos code base.
> > 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.
>
My point is that we do not need to bundle a Message Broker with Cloud
Controller. We can initially support Apache ActiveMQ and WSO2 MB. We will
provide detailed configuration steps in Cloud Controller for both. There is
nothing to configure in Message Broker. Then users can choose a Message
Broker of their choice without any complexity. Adding an extra JVM process
in to the system is not an issue in my opinion.
> > 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'm working on the improvement. :)
> (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 <ni...@gmail.com>
> wrote:
> >>
> >>
> >> On Aug 10, 2013 7:14 AM, "Isuru Perera" <ch...@gmail.com> wrote:
> >> >
> >> > Hi all,
> >> >
> >> >
> >> > On Thu, Aug 8, 2013 at 9:13 AM, Isuru Perera <ch...@gmail.com>
> 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 <
> nirmal070125@gmail.com> 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
>
--
Isuru Perera
about.me/chrishantha
Re: Cloud Controller - Create an extension point to attach different
configuration (topology) publishers
Posted by Nirmal Fernando <ni...@gmail.com>.
On Aug 14, 2013 4:55 AM, "Isuru Perera" <ch...@gmail.com> 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 <ni...@gmail.com>
wrote:
>>
>>
>> On Aug 10, 2013 7:14 AM, "Isuru Perera" <ch...@gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> >
>> > On Thu, Aug 8, 2013 at 9:13 AM, Isuru Perera <ch...@gmail.com>
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 <
nirmal070125@gmail.com> 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
Re: Cloud Controller - Create an extension point to attach different
configuration (topology) publishers
Posted by Isuru Perera <ch...@gmail.com>.
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)
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.
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
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 <ni...@gmail.com>wrote:
>
> On Aug 10, 2013 7:14 AM, "Isuru Perera" <ch...@gmail.com> wrote:
> >
> > Hi all,
> >
> >
> > On Thu, Aug 8, 2013 at 9:13 AM, Isuru Perera <ch...@gmail.com>
> 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 <
> nirmal070125@gmail.com> 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
Re: Cloud Controller - Create an extension point to attach different
configuration (topology) publishers
Posted by Nirmal Fernando <ni...@gmail.com>.
On Aug 10, 2013 7:14 AM, "Isuru Perera" <ch...@gmail.com> wrote:
>
> Hi all,
>
>
> On Thu, Aug 8, 2013 at 9:13 AM, Isuru Perera <ch...@gmail.com>
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 <ni...@gmail.com>
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
Re: Cloud Controller - Create an extension point to attach different
configuration (topology) publishers
Posted by Isuru Perera <ch...@gmail.com>.
Hi all,
On Thu, Aug 8, 2013 at 9:13 AM, Isuru Perera <ch...@gmail.com> 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).
We can then allow users to use any MB. Let's see whether we can use
ActiveMQ and RabbitMQ
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 <ni...@gmail.com>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
Re: Cloud Controller - Create an extension point to attach different
configuration (topology) publishers
Posted by Isuru Perera <ch...@gmail.com>.
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.
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 <ni...@gmail.com>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