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/10/18 14:16:48 UTC
Topology Event Message Processors follow 'chain of responsibility'
design pattern
Hi All,
Now $subject! Following is the MessageProcessor interface as of now.
*package org.apache.stratos.messaging.message.processor;
import org.apache.stratos.messaging.domain.topology.Topology;
/**
* Message processor interface. Every Message Processor should implement
this.
*/
public interface MessageProcessor {
/**
* Link a message processor and its successor, if there's any.
* @param nextProcessor
*/
public abstract void setNext(MessageProcessor nextProcessor);
/**
* Message processing and delegating logic.
* @param type type of the message.
* @param message real message body.
* @param topology Topology that will get updated.
* @return whether the processing was successful or not.
*/
public abstract boolean process(String type, String message, Topology
topology);
}*
I've implemented initial Message Processors:
*├── ClusterCreatedEventProcessor.java
├── ClusterRemovedEventProcessor.java
├── CompleteTopologyEventProcessor.java
├── MemberActivatedEventProcessor.java
├── MemberStartedEventProcessor.java
├── MemberSuspendedEventProcessor.java
├── MemberTerminatedEventProcessor.java
├── ServiceCreatedEventProcessor.java
└── ServiceRemovedEventProcessor.java*
Now, it is up to the Message Processor Delegator to build the Message
processor chain.
*// instantiate all the relevant processors
ServiceCreatedEventProcessor processor1 = new
ServiceCreatedEventProcessor();
ServiceRemovedEventProcessor processor2 = new
ServiceRemovedEventProcessor();
ClusterCreatedEventProcessor processor3 = new
ClusterCreatedEventProcessor();
// link all the relevant processors in the required order
processor1.setNext(processor2);
processor2.setNext(processor3);
processor3.setNext(processor4);*
and also it's a duty of the deligator to start the flow:
*boolean hasProcessed = processor1.process(type, json,
TopologyManager.getTopology());*
After the flow started, Processor who is capable of handling the message
would eventually receive it and will process the message and other
Processors will simply delegate the message to its successor.
I've done necessary changes and committed.
--
Best Regards,
Nirmal
Nirmal Fernando.
PPMC Member & Committer of Apache Stratos,
Senior Software Engineer, WSO2 Inc.
Blog: http://nirmalfdo.blogspot.com/
Re: Topology Event Message Processors follow 'chain of
responsibility' design pattern
Posted by Lahiru Sandaruwan <la...@wso2.com>.
On Mon, Oct 21, 2013 at 3:42 PM, Lahiru Sandaruwan <la...@wso2.com> wrote:
> Hi Nirmal,
>
> Cool implementation, I'm trying to understand this with Autoscaler side
> message processing requirements.
> So one question,
>
> On Fri, Oct 18, 2013 at 5:46 PM, Nirmal Fernando <ni...@gmail.com>wrote:
>
>> Hi All,
>>
>> Now $subject! Following is the MessageProcessor interface as of now.
>>
>> *package org.apache.stratos.messaging.message.processor;
>>
>> import org.apache.stratos.messaging.domain.topology.Topology;
>>
>> /**
>> * Message processor interface. Every Message Processor should implement
>> this.
>> */
>> public interface MessageProcessor {
>>
>> /**
>> * Link a message processor and its successor, if there's any.
>> * @param nextProcessor
>> */
>> public abstract void setNext(MessageProcessor nextProcessor);
>>
>> /**
>> * Message processing and delegating logic.
>> * @param type type of the message.
>> * @param message real message body.
>> * @param topology Topology that will get updated.
>> * @return whether the processing was successful or not.
>> */
>> public abstract boolean process(String type, String message, Topology
>> topology);
>> *
>>
>
> MessageProcessor is a common interface for all the messages. How do we
> handle messages that are not involved with Topology when the Topology is
> one parameter?
>
It seems this interface is specific to topology topic subscribers. So i'll
rename it to TopologyMessageProcessor and create separate message
processors for other topic subscribers.
Thanks.
>
> E.g.
>
>> * }*
>>
>> I've implemented initial Message Processors:
>>
>> *├── ClusterCreatedEventProcessor.java
>> ├── ClusterRemovedEventProcessor.java
>> ├── CompleteTopologyEventProcessor.java
>> ├── MemberActivatedEventProcessor.java
>> ├── MemberStartedEventProcessor.java
>> ├── MemberSuspendedEventProcessor.java
>> ├── MemberTerminatedEventProcessor.java
>> ├── ServiceCreatedEventProcessor.java
>> └── ServiceRemovedEventProcessor.java*
>>
>> Now, it is up to the Message Processor Delegator to build the Message
>> processor chain.
>>
>> *// instantiate all the relevant processors
>> ServiceCreatedEventProcessor processor1 = new
>> ServiceCreatedEventProcessor();
>> ServiceRemovedEventProcessor processor2 = new
>> ServiceRemovedEventProcessor();
>> ClusterCreatedEventProcessor processor3 = new
>> ClusterCreatedEventProcessor();
>>
>>
>> // link all the relevant processors in the required order
>> processor1.setNext(processor2);
>> processor2.setNext(processor3);
>> processor3.setNext(processor4);*
>>
>> and also it's a duty of the deligator to start the flow:
>>
>> *boolean hasProcessed = processor1.process(type, json,
>> TopologyManager.getTopology());*
>>
>> After the flow started, Processor who is capable of handling the message
>> would eventually receive it and will process the message and other
>> Processors will simply delegate the message to its successor.
>>
>> I've done necessary changes and committed.
>>
>> --
>> Best Regards,
>> Nirmal
>>
>> Nirmal Fernando.
>> PPMC Member & Committer of Apache Stratos,
>> Senior Software Engineer, WSO2 Inc.
>>
>> Blog: http://nirmalfdo.blogspot.com/
>>
>
>
>
> --
> --
> Lahiru Sandaruwan
> Software Engineer,
> Platform Technologies,
> WSO2 Inc., http://wso2.com
> lean.enterprise.middleware
>
> email: lahirus@wso2.com cell: (+94) 773 325 954
> blog: http://lahiruwrites.blogspot.com/
> twitter: http://twitter.com/lahirus
> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>
>
--
--
Lahiru Sandaruwan
Software Engineer,
Platform Technologies,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
email: lahirus@wso2.com cell: (+94) 773 325 954
blog: http://lahiruwrites.blogspot.com/
twitter: http://twitter.com/lahirus
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: Topology Event Message Processors follow 'chain of
responsibility' design pattern
Posted by Lahiru Sandaruwan <la...@wso2.com>.
Hi Nirmal,
Cool implementation, I'm trying to understand this with Autoscaler side
message processing requirements.
So one question,
On Fri, Oct 18, 2013 at 5:46 PM, Nirmal Fernando <ni...@gmail.com>wrote:
> Hi All,
>
> Now $subject! Following is the MessageProcessor interface as of now.
>
> *package org.apache.stratos.messaging.message.processor;
>
> import org.apache.stratos.messaging.domain.topology.Topology;
>
> /**
> * Message processor interface. Every Message Processor should implement
> this.
> */
> public interface MessageProcessor {
>
> /**
> * Link a message processor and its successor, if there's any.
> * @param nextProcessor
> */
> public abstract void setNext(MessageProcessor nextProcessor);
>
> /**
> * Message processing and delegating logic.
> * @param type type of the message.
> * @param message real message body.
> * @param topology Topology that will get updated.
> * @return whether the processing was successful or not.
> */
> public abstract boolean process(String type, String message, Topology
> topology);
> *
>
MessageProcessor is a common interface for all the messages. How do we
handle messages that are not involved with Topology when the Topology is
one parameter?
E.g.
> * }*
>
> I've implemented initial Message Processors:
>
> *├── ClusterCreatedEventProcessor.java
> ├── ClusterRemovedEventProcessor.java
> ├── CompleteTopologyEventProcessor.java
> ├── MemberActivatedEventProcessor.java
> ├── MemberStartedEventProcessor.java
> ├── MemberSuspendedEventProcessor.java
> ├── MemberTerminatedEventProcessor.java
> ├── ServiceCreatedEventProcessor.java
> └── ServiceRemovedEventProcessor.java*
>
> Now, it is up to the Message Processor Delegator to build the Message
> processor chain.
>
> *// instantiate all the relevant processors
> ServiceCreatedEventProcessor processor1 = new
> ServiceCreatedEventProcessor();
> ServiceRemovedEventProcessor processor2 = new
> ServiceRemovedEventProcessor();
> ClusterCreatedEventProcessor processor3 = new
> ClusterCreatedEventProcessor();
>
>
> // link all the relevant processors in the required order
> processor1.setNext(processor2);
> processor2.setNext(processor3);
> processor3.setNext(processor4);*
>
> and also it's a duty of the deligator to start the flow:
>
> *boolean hasProcessed = processor1.process(type, json,
> TopologyManager.getTopology());*
>
> After the flow started, Processor who is capable of handling the message
> would eventually receive it and will process the message and other
> Processors will simply delegate the message to its successor.
>
> I've done necessary changes and committed.
>
> --
> Best Regards,
> Nirmal
>
> Nirmal Fernando.
> PPMC Member & Committer of Apache Stratos,
> Senior Software Engineer, WSO2 Inc.
>
> Blog: http://nirmalfdo.blogspot.com/
>
--
--
Lahiru Sandaruwan
Software Engineer,
Platform Technologies,
WSO2 Inc., http://wso2.com
lean.enterprise.middleware
email: lahirus@wso2.com cell: (+94) 773 325 954
blog: http://lahiruwrites.blogspot.com/
twitter: http://twitter.com/lahirus
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146