LB messages processor chain

[chris snow <ch...@gmail.com>]

In the case of the LB MessageProcessorChain, the following processors have
been added to the list:

org.apache.stratos.messaging.message.processor.topology.ServiceCreatedEventProcessor
org.apache.stratos.messaging.message.processor.topology.ServiceRemovedEventProcessor
org.apache.stratos.messaging.message.processor.topology.ClusterCreatedEventProcessor
org.apache.stratos.messaging.message.processor.topology.ClusterRemovedEventProcessor
org.apache.stratos.messaging.message.processor.topology.InstanceSpawnedEventProcessor
org.apache.stratos.messaging.message.processor.topology.MemberStartedEventProcessor
org.apache.stratos.messaging.message.processor.topology.MemberActivatedEventProcessor
org.apache.stratos.messaging.message.processor.topology.MemberSuspendedEventProcessor
org.apache.stratos.messaging.message.processor.topology.MemberTerminatedEventProcessor
org.apache.stratos.messaging.message.processor.topology.CompleteTopologyEventIgnoreProcessor

In a component that exposes a SOAP/REST API, I would look at the WSDL/WADL
to examine the API.  As a WSDL/WADL aren't available for the LB component,
how can I examine the API without having to run the code and inspect the
MessageProcessorChain?

Many thanks,

Chris

Re: LB messages processor chain

[Nirmal Fernando <ni...@gmail.com>]

Hi Kishanthan,

Via a AMQP transport header which has the event class name.


On Thu, Dec 5, 2013 at 8:22 AM, Kishanthan Thangarajah <
kshanth2101@gmail.com> wrote:

> On Thu, Dec 5, 2013 at 8:00 AM, Imesh Gunaratne <im...@apache.org> wrote:
> > Hi Chris,
> >
> > I totally agree, yes we could think that messaging as the transport and
> the
> > events are as the API.
> >
> > I think we definitely need to add this information to the Wiki. I will
> > prepare some content for this topic and add it to the documentation. For
> the
> > moment please refer the brief description below:
> >
> > Initially Load Balancer waits for the Complete Topology Event:
> > - This is the starting point for building the Topology data structure.
> > - This event has been introduced to make sure that if the Load Balancer
> > restarts it could still build the topology from the right point.
> > - This is only received once. Then on top of it other events are applied.
> >
> > Other events are received in the following order by the Load Balancer:
> >
> > 1. Service Created: This adds a new service to the Topology.
> > 2. Cluster Created: This adds a new cluster to a given service.
> > 3. Instance Spawned: This adds a new member to a given cluster.
> > 4. Member Started: This changes the state of a given member to Starting.
> > 5. Member Activated: This changes the state of a given member to
> Activated.
> > Now this member is ready to serve requests.
>
> Ok, so these events go through the processor chain of LB and when
> matching processor finds it event, it starts to process it.
>
> Then the question would be, how does a processor find its matching
> event? There should a format for the event to differentiate it self
> form other events. For example 'Cluster Created' event is different
> from 'Member Started'. Or do we have a common format for these events,
> and identify each of them based on the name? I think this is a point a
> user would be interested in.
>
> >
> > The following events could received in any order:
> >
> > - Member Suspended: This changes the state of the member to Suspended.
> > - Member Terminated: This changes the state of the member to Terminated.
> > - Cluster Removed: This removes a given cluster from a service.
> > - Service Removed: This removes a given service from the Topology.
> >
> > Really appreciate your concerns on this.
> >
> >
> > Many Thanks
> > Imesh
> >
> >
> > On Thu, Dec 5, 2013 at 2:36 AM, chris snow <ch...@gmail.com> wrote:
> >>
> >> Hi Imesh,
> >>
> >> Messaging is how other components communicate with LB, so I'm thinking
> >> that messaging is the transport, and the objects sent in the messages
> >> represent the API.
> >>
> >> A tester who would want to test the LB as a black box would be
> interested
> >> in the API as that represents the external behaviour of the LB.
> >>
> >> In a soap based component, the API is easy to find because it is
> >> documented by the wsdl.  However, in a component like LB that uses
> messaging
> >> and not soap, how would someone determine the API?
> >>
> >> Does my question make any more sense now?
> >>
> >> Many thanks,
> >>
> >> Chris
> >>
> >> Hi Chris,
> >>
> >> I'm sorry for the confusion.
> >> Actually the load balancer does not expose a service. It communicates
> with
> >> the other components via the message broker.
> >>
> >> The standard is to implement service stubs for each service in place
> them
> >> in incubator-stratos/service-stubs/. There we could find the WSDL of
> each
> >> service. However please note that at the moment we may have number of
> >> un-used service stubs in this folder.
> >>
> >> Thanks
> >> Imesh
> >>
> >>
> >>
> >>
> >> On Tue, Dec 3, 2013 at 2:57 PM, Udara Liyanage <ud...@wso2.com> wrote:
> >>>
> >>> Hi chris,
> >>>
> >>> If it is a web service there is a wsdl for the service. By looking at
> the
> >>> WSDl you can view the exposed methods, the input needed and the output
> >>> returned from them.
> >>>
> >>> For example Cloud Controller has exposed a API called
> >>> CloudControllerService. You can find the related WSDL at the following
> >>> folder.
> >>>
> [stratos]/service-stubs/org.apache.stratos.cloud.controller.service.stub
> >>>
> >>>
> >>>
> >>> On Tue, Dec 3, 2013 at 2:03 AM, chris snow <ch...@gmail.com>
> wrote:
> >>>>
> >>>> Hi Imesh,
> >>>>
> >>>> Sorry, the question was:  "how can a developer/tester/architect
> examine
> >>>> the external API that is exposed by the LB (and other Stratos
> components)?".
> >>>>
> >>>> A software tester would want to view the API so that they can
> determine
> >>>> how they will test the component through that API.
> >>>> An architect would want to view the API so that they can understand
> the
> >>>> services exposed by the component without looking through the code
> base.
> >>>>
> >>>> The API for a stratos component is the list of messages that it
> >>>> supports.  How can an architect or tester find a list of messages
> that each
> >>>> Stratos component supports?
> >>>>
> >>>> Many thanks,
> >>>>
> >>>> Chris
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Dec 3, 2013 at 1:52 AM, Imesh Gunaratne <im...@apache.org>
> >>>> wrote:
> >>>>>
> >>>>> Hi Chris,
> >>>>>
> >>>>> There was no requirement to expose a SOAP/REST API in the load
> >>>>> balancer. Therefore there is no WSDL/WADL added.
> >>>>>
> >>>>> BTW if your requirement is to examine the behaviour of
> >>>>> TopologyEventProcessorChain it shouldn't be that difficult.
> Basically each
> >>>>> processor corresponds to its event, if it didn't find the required
> event it
> >>>>> will pass the call to the next processor. Once it finds the matching
> event
> >>>>> it will build the Topology in Topology Manager and fire the matching
> event
> >>>>> listener.
> >>>>>
> >>>>> Thanks
> >>>>> Imesh
> >>>>>
> >>>>>
> >>>>> On Tue, Dec 3, 2013 at 3:31 AM, chris snow <ch...@gmail.com>
> wrote:
> >>>>>>
> >>>>>> In the case of the LB MessageProcessorChain, the following
> processors
> >>>>>> have been added to the list:
> >>>>>>
> >>>>>>
> >>>>>>
> org.apache.stratos.messaging.message.processor.topology.ServiceCreatedEventProcessor
> >>>>>>
> org.apache.stratos.messaging.message.processor.topology.ServiceRemovedEventProcessor
> >>>>>>
> org.apache.stratos.messaging.message.processor.topology.ClusterCreatedEventProcessor
> >>>>>>
> org.apache.stratos.messaging.message.processor.topology.ClusterRemovedEventProcessor
> >>>>>>
> org.apache.stratos.messaging.message.processor.topology.InstanceSpawnedEventProcessor
> >>>>>>
> org.apache.stratos.messaging.message.processor.topology.MemberStartedEventProcessor
> >>>>>>
> org.apache.stratos.messaging.message.processor.topology.MemberActivatedEventProcessor
> >>>>>>
> org.apache.stratos.messaging.message.processor.topology.MemberSuspendedEventProcessor
> >>>>>>
> org.apache.stratos.messaging.message.processor.topology.MemberTerminatedEventProcessor
> >>>>>>
> org.apache.stratos.messaging.message.processor.topology.CompleteTopologyEventIgnoreProcessor
> >>>>>>
> >>>>>> In a component that exposes a SOAP/REST API, I would look at the
> >>>>>> WSDL/WADL to examine the API.  As a WSDL/WADL aren't available for
> the LB
> >>>>>> component, how can I examine the API without having to run the code
> and
> >>>>>> inspect the MessageProcessorChain?
> >>>>>>
> >>>>>> Many thanks,
> >>>>>>
> >>>>>> Chris
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Check out my professional profile and connect with me on LinkedIn.
> >>>> http://lnkd.in/cw5k69
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> Udara Liyanage
> >>> Software Engineer
> >>> WSO2, Inc.: http://wso2.com
> >>> lean. enterprise. middleware
> >>>
> >>> web: http://udaraliyanage.wordpress.com
> >>> phone: +94 71 443 6897
> >>
> >>
> >
>



-- 
Best Regards,
Nirmal

Nirmal Fernando.
PPMC Member & Committer of Apache Stratos,
Senior Software Engineer, WSO2 Inc.

Blog: http://nirmalfdo.blogspot.com/

Re: LB messages processor chain

[Kishanthan Thangarajah <ks...@gmail.com>]

On Thu, Dec 5, 2013 at 8:00 AM, Imesh Gunaratne <im...@apache.org> wrote:
> Hi Chris,
>
> I totally agree, yes we could think that messaging as the transport and the
> events are as the API.
>
> I think we definitely need to add this information to the Wiki. I will
> prepare some content for this topic and add it to the documentation. For the
> moment please refer the brief description below:
>
> Initially Load Balancer waits for the Complete Topology Event:
> - This is the starting point for building the Topology data structure.
> - This event has been introduced to make sure that if the Load Balancer
> restarts it could still build the topology from the right point.
> - This is only received once. Then on top of it other events are applied.
>
> Other events are received in the following order by the Load Balancer:
>
> 1. Service Created: This adds a new service to the Topology.
> 2. Cluster Created: This adds a new cluster to a given service.
> 3. Instance Spawned: This adds a new member to a given cluster.
> 4. Member Started: This changes the state of a given member to Starting.
> 5. Member Activated: This changes the state of a given member to Activated.
> Now this member is ready to serve requests.

Ok, so these events go through the processor chain of LB and when
matching processor finds it event, it starts to process it.

Then the question would be, how does a processor find its matching
event? There should a format for the event to differentiate it self
form other events. For example 'Cluster Created' event is different
from 'Member Started'. Or do we have a common format for these events,
and identify each of them based on the name? I think this is a point a
user would be interested in.

>
> The following events could received in any order:
>
> - Member Suspended: This changes the state of the member to Suspended.
> - Member Terminated: This changes the state of the member to Terminated.
> - Cluster Removed: This removes a given cluster from a service.
> - Service Removed: This removes a given service from the Topology.
>
> Really appreciate your concerns on this.
>
>
> Many Thanks
> Imesh
>
>
> On Thu, Dec 5, 2013 at 2:36 AM, chris snow <ch...@gmail.com> wrote:
>>
>> Hi Imesh,
>>
>> Messaging is how other components communicate with LB, so I'm thinking
>> that messaging is the transport, and the objects sent in the messages
>> represent the API.
>>
>> A tester who would want to test the LB as a black box would be interested
>> in the API as that represents the external behaviour of the LB.
>>
>> In a soap based component, the API is easy to find because it is
>> documented by the wsdl.  However, in a component like LB that uses messaging
>> and not soap, how would someone determine the API?
>>
>> Does my question make any more sense now?
>>
>> Many thanks,
>>
>> Chris
>>
>> Hi Chris,
>>
>> I'm sorry for the confusion.
>> Actually the load balancer does not expose a service. It communicates with
>> the other components via the message broker.
>>
>> The standard is to implement service stubs for each service in place them
>> in incubator-stratos/service-stubs/. There we could find the WSDL of each
>> service. However please note that at the moment we may have number of
>> un-used service stubs in this folder.
>>
>> Thanks
>> Imesh
>>
>>
>>
>>
>> On Tue, Dec 3, 2013 at 2:57 PM, Udara Liyanage <ud...@wso2.com> wrote:
>>>
>>> Hi chris,
>>>
>>> If it is a web service there is a wsdl for the service. By looking at the
>>> WSDl you can view the exposed methods, the input needed and the output
>>> returned from them.
>>>
>>> For example Cloud Controller has exposed a API called
>>> CloudControllerService. You can find the related WSDL at the following
>>> folder.
>>> [stratos]/service-stubs/org.apache.stratos.cloud.controller.service.stub
>>>
>>>
>>>
>>> On Tue, Dec 3, 2013 at 2:03 AM, chris snow <ch...@gmail.com> wrote:
>>>>
>>>> Hi Imesh,
>>>>
>>>> Sorry, the question was:  "how can a developer/tester/architect examine
>>>> the external API that is exposed by the LB (and other Stratos components)?".
>>>>
>>>> A software tester would want to view the API so that they can determine
>>>> how they will test the component through that API.
>>>> An architect would want to view the API so that they can understand the
>>>> services exposed by the component without looking through the code base.
>>>>
>>>> The API for a stratos component is the list of messages that it
>>>> supports.  How can an architect or tester find a list of messages that each
>>>> Stratos component supports?
>>>>
>>>> Many thanks,
>>>>
>>>> Chris
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Tue, Dec 3, 2013 at 1:52 AM, Imesh Gunaratne <im...@apache.org>
>>>> wrote:
>>>>>
>>>>> Hi Chris,
>>>>>
>>>>> There was no requirement to expose a SOAP/REST API in the load
>>>>> balancer. Therefore there is no WSDL/WADL added.
>>>>>
>>>>> BTW if your requirement is to examine the behaviour of
>>>>> TopologyEventProcessorChain it shouldn't be that difficult. Basically each
>>>>> processor corresponds to its event, if it didn't find the required event it
>>>>> will pass the call to the next processor. Once it finds the matching event
>>>>> it will build the Topology in Topology Manager and fire the matching event
>>>>> listener.
>>>>>
>>>>> Thanks
>>>>> Imesh
>>>>>
>>>>>
>>>>> On Tue, Dec 3, 2013 at 3:31 AM, chris snow <ch...@gmail.com> wrote:
>>>>>>
>>>>>> In the case of the LB MessageProcessorChain, the following processors
>>>>>> have been added to the list:
>>>>>>
>>>>>>
>>>>>> org.apache.stratos.messaging.message.processor.topology.ServiceCreatedEventProcessor
>>>>>> org.apache.stratos.messaging.message.processor.topology.ServiceRemovedEventProcessor
>>>>>> org.apache.stratos.messaging.message.processor.topology.ClusterCreatedEventProcessor
>>>>>> org.apache.stratos.messaging.message.processor.topology.ClusterRemovedEventProcessor
>>>>>> org.apache.stratos.messaging.message.processor.topology.InstanceSpawnedEventProcessor
>>>>>> org.apache.stratos.messaging.message.processor.topology.MemberStartedEventProcessor
>>>>>> org.apache.stratos.messaging.message.processor.topology.MemberActivatedEventProcessor
>>>>>> org.apache.stratos.messaging.message.processor.topology.MemberSuspendedEventProcessor
>>>>>> org.apache.stratos.messaging.message.processor.topology.MemberTerminatedEventProcessor
>>>>>> org.apache.stratos.messaging.message.processor.topology.CompleteTopologyEventIgnoreProcessor
>>>>>>
>>>>>> In a component that exposes a SOAP/REST API, I would look at the
>>>>>> WSDL/WADL to examine the API.  As a WSDL/WADL aren't available for the LB
>>>>>> component, how can I examine the API without having to run the code and
>>>>>> inspect the MessageProcessorChain?
>>>>>>
>>>>>> Many thanks,
>>>>>>
>>>>>> Chris
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Check out my professional profile and connect with me on LinkedIn.
>>>> http://lnkd.in/cw5k69
>>>
>>>
>>>
>>>
>>> --
>>> Udara Liyanage
>>> Software Engineer
>>> WSO2, Inc.: http://wso2.com
>>> lean. enterprise. middleware
>>>
>>> web: http://udaraliyanage.wordpress.com
>>> phone: +94 71 443 6897
>>
>>
>

Re: LB messages processor chain

[Imesh Gunaratne <im...@apache.org>]

Hi Chris,

I totally agree, yes we could think that messaging as the transport and the
events are as the API.

I think we definitely need to add this information to the Wiki. I will
prepare some content for this topic and add it to the documentation. For
the moment please refer the brief description below:

Initially Load Balancer waits for the Complete Topology Event:
- This is the starting point for building the Topology data structure.
- This event has been introduced to make sure that if the Load Balancer
restarts it could still build the topology from the right point.
- This is only received once. Then on top of it other events are applied.

Other events are received in the following order by the Load Balancer:

1. Service Created: This adds a new service to the Topology.
2. Cluster Created: This adds a new cluster to a given service.
3. Instance Spawned: This adds a new member to a given cluster.
4. Member Started: This changes the state of a given member to Starting.
5. Member Activated: This changes the state of a given member to Activated.
Now this member is ready to serve requests.

The following events could received in any order:

- Member Suspended: This changes the state of the member to Suspended.
- Member Terminated: This changes the state of the member to Terminated.
- Cluster Removed: This removes a given cluster from a service.
- Service Removed: This removes a given service from the Topology.

Really appreciate your concerns on this.


Many Thanks
Imesh


On Thu, Dec 5, 2013 at 2:36 AM, chris snow <ch...@gmail.com> wrote:

> Hi Imesh,
>
> Messaging is how other components communicate with LB, so I'm thinking
> that messaging is the transport, and the objects sent in the messages
> represent the API.
>
> A tester who would want to test the LB as a black box would be interested
> in the API as that represents the external behaviour of the LB.
>
> In a soap based component, the API is easy to find because it is
> documented by the wsdl.  However, in a component like LB that uses
> messaging and not soap, how would someone determine the API?
>
> Does my question make any more sense now?
>
> Many thanks,
>
> Chris
>  Hi Chris,
>
> I'm sorry for the confusion.
> Actually the load balancer does not expose a service. It communicates with
> the other components via the message broker.
>
> The standard is to implement service stubs for each service in place them
> in incubator-stratos/service-stubs/. There we could find the WSDL of each
> service. However please note that at the moment we may have number of
> un-used service stubs in this folder.
>
> Thanks
> Imesh
>
>
>
>
> On Tue, Dec 3, 2013 at 2:57 PM, Udara Liyanage <ud...@wso2.com> wrote:
>
>> Hi chris,
>>
>> If it is a web service there is a wsdl for the service. By looking at the
>> WSDl you can view the exposed methods, the input needed and the output
>> returned from them.
>>
>> For example Cloud Controller has exposed a API called
>> CloudControllerService. You can find the related WSDL at the following
>> folder.
>> [stratos]/service-stubs/org.apache.stratos.cloud.controller.service.stub
>>
>>
>>
>> On Tue, Dec 3, 2013 at 2:03 AM, chris snow <ch...@gmail.com> wrote:
>>
>>> Hi Imesh,
>>>
>>> Sorry, the question was:  "how can a developer/tester/architect examine
>>> the external API that is exposed by the LB (and other Stratos
>>> components)?".
>>>
>>>  A software tester would want to view the API so that they can
>>> determine how they will test the component through that API.
>>> An architect would want to view the API so that they can understand the
>>> services exposed by the component without looking through the code base.
>>>
>>> The API for a stratos component is the list of messages that it
>>> supports.  How can an architect or tester find a list of messages that each
>>> Stratos component supports?
>>>
>>> Many thanks,
>>>
>>> Chris
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Dec 3, 2013 at 1:52 AM, Imesh Gunaratne <im...@apache.org>wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> There was no requirement to expose a SOAP/REST API in the load
>>>> balancer. Therefore there is no WSDL/WADL added.
>>>>
>>>> BTW if your requirement is to examine the behaviour
>>>> of TopologyEventProcessorChain it shouldn't be that difficult. Basically
>>>> each processor corresponds to its event, if it didn't find the required
>>>> event it will pass the call to the next processor. Once it finds the
>>>> matching event it will build the Topology in Topology Manager and fire the
>>>> matching event listener.
>>>>
>>>> Thanks
>>>> Imesh
>>>>
>>>>
>>>> On Tue, Dec 3, 2013 at 3:31 AM, chris snow <ch...@gmail.com> wrote:
>>>>
>>>>> In the case of the LB MessageProcessorChain, the following processors
>>>>> have been added to the list:
>>>>>
>>>>> org.apache.stratos.messaging.message.processor.topology.ServiceCreatedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.ServiceRemovedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.ClusterCreatedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.ClusterRemovedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.InstanceSpawnedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.MemberStartedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.MemberActivatedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.MemberSuspendedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.MemberTerminatedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.CompleteTopologyEventIgnoreProcessor
>>>>>
>>>>> In a component that exposes a SOAP/REST API, I would look at the
>>>>> WSDL/WADL to examine the API.  As a WSDL/WADL aren't available for the LB
>>>>> component, how can I examine the API without having to run the code and
>>>>> inspect the MessageProcessorChain?
>>>>>
>>>>> Many thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Check out my professional profile and connect with me on LinkedIn.
>>> http://lnkd.in/cw5k69
>>>
>>
>>
>>
>> --
>> Udara Liyanage
>> Software Engineer
>>  WSO2, Inc.: http://wso2.com
>> lean. enterprise. middleware
>>
>> web: http://udaraliyanage.wordpress.com
>> phone: +94 71 443 6897
>>
>
>

Re: LB messages processor chain

[Lahiru Sandaruwan <la...@wso2.com>]

Good question Chris,

We use messaging as the backbone of Stratos 4 architecture and most of the
components become plugable with that.
Json is the message type that is agreed to send over message broker. So I
think having the knowledge about the Json message formats and the topics
that are listened by LB solves the issue.

I do not find anyway to examine LB and get those information. Someone got
to know those from Stratos community/ documents etc. if he/she need them.

Thanks.


On Thu, Dec 5, 2013 at 2:36 AM, chris snow <ch...@gmail.com> wrote:

> Hi Imesh,
>
> Messaging is how other components communicate with LB, so I'm thinking
> that messaging is the transport, and the objects sent in the messages
> represent the API.
>
> A tester who would want to test the LB as a black box would be interested
> in the API as that represents the external behaviour of the LB.
>
> In a soap based component, the API is easy to find because it is
> documented by the wsdl.  However, in a component like LB that uses
> messaging and not soap, how would someone determine the API?
>
> Does my question make any more sense now?
>
> Many thanks,
>
> Chris
>  Hi Chris,
>
> I'm sorry for the confusion.
> Actually the load balancer does not expose a service. It communicates with
> the other components via the message broker.
>
> The standard is to implement service stubs for each service in place them
> in incubator-stratos/service-stubs/. There we could find the WSDL of each
> service. However please note that at the moment we may have number of
> un-used service stubs in this folder.
>
> Thanks
> Imesh
>
>
>
>
> On Tue, Dec 3, 2013 at 2:57 PM, Udara Liyanage <ud...@wso2.com> wrote:
>
>> Hi chris,
>>
>> If it is a web service there is a wsdl for the service. By looking at the
>> WSDl you can view the exposed methods, the input needed and the output
>> returned from them.
>>
>> For example Cloud Controller has exposed a API called
>> CloudControllerService. You can find the related WSDL at the following
>> folder.
>> [stratos]/service-stubs/org.apache.stratos.cloud.controller.service.stub
>>
>>
>>
>> On Tue, Dec 3, 2013 at 2:03 AM, chris snow <ch...@gmail.com> wrote:
>>
>>> Hi Imesh,
>>>
>>> Sorry, the question was:  "how can a developer/tester/architect examine
>>> the external API that is exposed by the LB (and other Stratos
>>> components)?".
>>>
>>>  A software tester would want to view the API so that they can
>>> determine how they will test the component through that API.
>>> An architect would want to view the API so that they can understand the
>>> services exposed by the component without looking through the code base.
>>>
>>> The API for a stratos component is the list of messages that it
>>> supports.  How can an architect or tester find a list of messages that each
>>> Stratos component supports?
>>>
>>> Many thanks,
>>>
>>> Chris
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Dec 3, 2013 at 1:52 AM, Imesh Gunaratne <im...@apache.org>wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> There was no requirement to expose a SOAP/REST API in the load
>>>> balancer. Therefore there is no WSDL/WADL added.
>>>>
>>>> BTW if your requirement is to examine the behaviour
>>>> of TopologyEventProcessorChain it shouldn't be that difficult. Basically
>>>> each processor corresponds to its event, if it didn't find the required
>>>> event it will pass the call to the next processor. Once it finds the
>>>> matching event it will build the Topology in Topology Manager and fire the
>>>> matching event listener.
>>>>
>>>> Thanks
>>>> Imesh
>>>>
>>>>
>>>> On Tue, Dec 3, 2013 at 3:31 AM, chris snow <ch...@gmail.com> wrote:
>>>>
>>>>> In the case of the LB MessageProcessorChain, the following processors
>>>>> have been added to the list:
>>>>>
>>>>> org.apache.stratos.messaging.message.processor.topology.ServiceCreatedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.ServiceRemovedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.ClusterCreatedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.ClusterRemovedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.InstanceSpawnedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.MemberStartedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.MemberActivatedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.MemberSuspendedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.MemberTerminatedEventProcessor
>>>>> org.apache.stratos.messaging.message.processor.topology.CompleteTopologyEventIgnoreProcessor
>>>>>
>>>>> In a component that exposes a SOAP/REST API, I would look at the
>>>>> WSDL/WADL to examine the API.  As a WSDL/WADL aren't available for the LB
>>>>> component, how can I examine the API without having to run the code and
>>>>> inspect the MessageProcessorChain?
>>>>>
>>>>> Many thanks,
>>>>>
>>>>> Chris
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Check out my professional profile and connect with me on LinkedIn.
>>> http://lnkd.in/cw5k69
>>>
>>
>>
>>
>> --
>> Udara Liyanage
>> Software Engineer
>>  WSO2, Inc.: http://wso2.com
>> lean. enterprise. middleware
>>
>> web: http://udaraliyanage.wordpress.com
>> phone: +94 71 443 6897
>>
>
>


-- 
--
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: LB messages processor chain

[chris snow <ch...@gmail.com>]

Hi Imesh,

Messaging is how other components communicate with LB, so I'm thinking that
messaging is the transport, and the objects sent in the messages represent
the API.

A tester who would want to test the LB as a black box would be interested
in the API as that represents the external behaviour of the LB.

In a soap based component, the API is easy to find because it is documented
by the wsdl.  However, in a component like LB that uses messaging and not
soap, how would someone determine the API?

Does my question make any more sense now?

Many thanks,

Chris
 Hi Chris,

I'm sorry for the confusion.
Actually the load balancer does not expose a service. It communicates with
the other components via the message broker.

The standard is to implement service stubs for each service in place them
in incubator-stratos/service-stubs/. There we could find the WSDL of each
service. However please note that at the moment we may have number of
un-used service stubs in this folder.

Thanks
Imesh




On Tue, Dec 3, 2013 at 2:57 PM, Udara Liyanage <ud...@wso2.com> wrote:

> Hi chris,
>
> If it is a web service there is a wsdl for the service. By looking at the
> WSDl you can view the exposed methods, the input needed and the output
> returned from them.
>
> For example Cloud Controller has exposed a API called
> CloudControllerService. You can find the related WSDL at the following
> folder.
> [stratos]/service-stubs/org.apache.stratos.cloud.controller.service.stub
>
>
>
> On Tue, Dec 3, 2013 at 2:03 AM, chris snow <ch...@gmail.com> wrote:
>
>> Hi Imesh,
>>
>> Sorry, the question was:  "how can a developer/tester/architect examine
>> the external API that is exposed by the LB (and other Stratos
>> components)?".
>>
>>  A software tester would want to view the API so that they can determine
>> how they will test the component through that API.
>> An architect would want to view the API so that they can understand the
>> services exposed by the component without looking through the code base.
>>
>> The API for a stratos component is the list of messages that it supports.
>>  How can an architect or tester find a list of messages that each Stratos
>> component supports?
>>
>> Many thanks,
>>
>> Chris
>>
>>
>>
>>
>>
>> On Tue, Dec 3, 2013 at 1:52 AM, Imesh Gunaratne <im...@apache.org> wrote:
>>
>>> Hi Chris,
>>>
>>> There was no requirement to expose a SOAP/REST API in the load balancer.
>>> Therefore there is no WSDL/WADL added.
>>>
>>> BTW if your requirement is to examine the behaviour
>>> of TopologyEventProcessorChain it shouldn't be that difficult. Basically
>>> each processor corresponds to its event, if it didn't find the required
>>> event it will pass the call to the next processor. Once it finds the
>>> matching event it will build the Topology in Topology Manager and fire the
>>> matching event listener.
>>>
>>> Thanks
>>> Imesh
>>>
>>>
>>> On Tue, Dec 3, 2013 at 3:31 AM, chris snow <ch...@gmail.com> wrote:
>>>
>>>> In the case of the LB MessageProcessorChain, the following processors
>>>> have been added to the list:
>>>>
>>>> org.apache.stratos.messaging.message.processor.topology.ServiceCreatedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.ServiceRemovedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.ClusterCreatedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.ClusterRemovedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.InstanceSpawnedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.MemberStartedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.MemberActivatedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.MemberSuspendedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.MemberTerminatedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.CompleteTopologyEventIgnoreProcessor
>>>>
>>>> In a component that exposes a SOAP/REST API, I would look at the
>>>> WSDL/WADL to examine the API.  As a WSDL/WADL aren't available for the LB
>>>> component, how can I examine the API without having to run the code and
>>>> inspect the MessageProcessorChain?
>>>>
>>>> Many thanks,
>>>>
>>>> Chris
>>>>
>>>
>>>
>>
>>
>> --
>> Check out my professional profile and connect with me on LinkedIn.
>> http://lnkd.in/cw5k69
>>
>
>
>
> --
> Udara Liyanage
> Software Engineer
>  WSO2, Inc.: http://wso2.com
> lean. enterprise. middleware
>
> web: http://udaraliyanage.wordpress.com
> phone: +94 71 443 6897
>

Re: LB messages processor chain

[Imesh Gunaratne <im...@apache.org>]

Hi Chris,

I'm sorry for the confusion.
Actually the load balancer does not expose a service. It communicates with
the other components via the message broker.

The standard is to implement service stubs for each service in place them
in incubator-stratos/service-stubs/. There we could find the WSDL of each
service. However please note that at the moment we may have number of
un-used service stubs in this folder.

Thanks
Imesh




On Tue, Dec 3, 2013 at 2:57 PM, Udara Liyanage <ud...@wso2.com> wrote:

> Hi chris,
>
> If it is a web service there is a wsdl for the service. By looking at the
> WSDl you can view the exposed methods, the input needed and the output
> returned from them.
>
> For example Cloud Controller has exposed a API called
> CloudControllerService. You can find the related WSDL at the following
> folder.
> [stratos]/service-stubs/org.apache.stratos.cloud.controller.service.stub
>
>
>
> On Tue, Dec 3, 2013 at 2:03 AM, chris snow <ch...@gmail.com> wrote:
>
>> Hi Imesh,
>>
>> Sorry, the question was:  "how can a developer/tester/architect examine
>> the external API that is exposed by the LB (and other Stratos
>> components)?".
>>
>>  A software tester would want to view the API so that they can determine
>> how they will test the component through that API.
>> An architect would want to view the API so that they can understand the
>> services exposed by the component without looking through the code base.
>>
>> The API for a stratos component is the list of messages that it supports.
>>  How can an architect or tester find a list of messages that each Stratos
>> component supports?
>>
>> Many thanks,
>>
>> Chris
>>
>>
>>
>>
>>
>> On Tue, Dec 3, 2013 at 1:52 AM, Imesh Gunaratne <im...@apache.org> wrote:
>>
>>> Hi Chris,
>>>
>>> There was no requirement to expose a SOAP/REST API in the load balancer.
>>> Therefore there is no WSDL/WADL added.
>>>
>>> BTW if your requirement is to examine the behaviour
>>> of TopologyEventProcessorChain it shouldn't be that difficult. Basically
>>> each processor corresponds to its event, if it didn't find the required
>>> event it will pass the call to the next processor. Once it finds the
>>> matching event it will build the Topology in Topology Manager and fire the
>>> matching event listener.
>>>
>>> Thanks
>>> Imesh
>>>
>>>
>>> On Tue, Dec 3, 2013 at 3:31 AM, chris snow <ch...@gmail.com> wrote:
>>>
>>>> In the case of the LB MessageProcessorChain, the following processors
>>>> have been added to the list:
>>>>
>>>> org.apache.stratos.messaging.message.processor.topology.ServiceCreatedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.ServiceRemovedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.ClusterCreatedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.ClusterRemovedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.InstanceSpawnedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.MemberStartedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.MemberActivatedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.MemberSuspendedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.MemberTerminatedEventProcessor
>>>> org.apache.stratos.messaging.message.processor.topology.CompleteTopologyEventIgnoreProcessor
>>>>
>>>> In a component that exposes a SOAP/REST API, I would look at the
>>>> WSDL/WADL to examine the API.  As a WSDL/WADL aren't available for the LB
>>>> component, how can I examine the API without having to run the code and
>>>> inspect the MessageProcessorChain?
>>>>
>>>> Many thanks,
>>>>
>>>> Chris
>>>>
>>>
>>>
>>
>>
>> --
>> Check out my professional profile and connect with me on LinkedIn.
>> http://lnkd.in/cw5k69
>>
>
>
>
> --
> Udara Liyanage
> Software Engineer
> WSO2, Inc.: http://wso2.com
> lean. enterprise. middleware
>
> web: http://udaraliyanage.wordpress.com
> phone: +94 71 443 6897
>

Re: LB messages processor chain

[Udara Liyanage <ud...@wso2.com>]

Hi chris,

If it is a web service there is a wsdl for the service. By looking at the
WSDl you can view the exposed methods, the input needed and the output
returned from them.

For example Cloud Controller has exposed a API called
CloudControllerService. You can find the related WSDL at the following
folder.
[stratos]/service-stubs/org.apache.stratos.cloud.controller.service.stub



On Tue, Dec 3, 2013 at 2:03 AM, chris snow <ch...@gmail.com> wrote:

> Hi Imesh,
>
> Sorry, the question was:  "how can a developer/tester/architect examine
> the external API that is exposed by the LB (and other Stratos
> components)?".
>
> A software tester would want to view the API so that they can determine
> how they will test the component through that API.
> An architect would want to view the API so that they can understand the
> services exposed by the component without looking through the code base.
>
> The API for a stratos component is the list of messages that it supports.
>  How can an architect or tester find a list of messages that each Stratos
> component supports?
>
> Many thanks,
>
> Chris
>
>
>
>
>
> On Tue, Dec 3, 2013 at 1:52 AM, Imesh Gunaratne <im...@apache.org> wrote:
>
>> Hi Chris,
>>
>> There was no requirement to expose a SOAP/REST API in the load balancer.
>> Therefore there is no WSDL/WADL added.
>>
>> BTW if your requirement is to examine the behaviour
>> of TopologyEventProcessorChain it shouldn't be that difficult. Basically
>> each processor corresponds to its event, if it didn't find the required
>> event it will pass the call to the next processor. Once it finds the
>> matching event it will build the Topology in Topology Manager and fire the
>> matching event listener.
>>
>> Thanks
>> Imesh
>>
>>
>> On Tue, Dec 3, 2013 at 3:31 AM, chris snow <ch...@gmail.com> wrote:
>>
>>> In the case of the LB MessageProcessorChain, the following processors
>>> have been added to the list:
>>>
>>> org.apache.stratos.messaging.message.processor.topology.ServiceCreatedEventProcessor
>>> org.apache.stratos.messaging.message.processor.topology.ServiceRemovedEventProcessor
>>> org.apache.stratos.messaging.message.processor.topology.ClusterCreatedEventProcessor
>>> org.apache.stratos.messaging.message.processor.topology.ClusterRemovedEventProcessor
>>> org.apache.stratos.messaging.message.processor.topology.InstanceSpawnedEventProcessor
>>> org.apache.stratos.messaging.message.processor.topology.MemberStartedEventProcessor
>>> org.apache.stratos.messaging.message.processor.topology.MemberActivatedEventProcessor
>>> org.apache.stratos.messaging.message.processor.topology.MemberSuspendedEventProcessor
>>> org.apache.stratos.messaging.message.processor.topology.MemberTerminatedEventProcessor
>>> org.apache.stratos.messaging.message.processor.topology.CompleteTopologyEventIgnoreProcessor
>>>
>>> In a component that exposes a SOAP/REST API, I would look at the
>>> WSDL/WADL to examine the API.  As a WSDL/WADL aren't available for the LB
>>> component, how can I examine the API without having to run the code and
>>> inspect the MessageProcessorChain?
>>>
>>> Many thanks,
>>>
>>> Chris
>>>
>>
>>
>
>
> --
> Check out my professional profile and connect with me on LinkedIn.
> http://lnkd.in/cw5k69
>



-- 
Udara Liyanage
Software Engineer
WSO2, Inc.: http://wso2.com
lean. enterprise. middleware

web: http://udaraliyanage.wordpress.com
phone: +94 71 443 6897

Re: LB messages processor chain

[chris snow <ch...@gmail.com>]

Hi Imesh,

Sorry, the question was:  "how can a developer/tester/architect examine the
external API that is exposed by the LB (and other Stratos components)?".

A software tester would want to view the API so that they can determine how
they will test the component through that API.
An architect would want to view the API so that they can understand the
services exposed by the component without looking through the code base.

The API for a stratos component is the list of messages that it supports.
 How can an architect or tester find a list of messages that each Stratos
component supports?

Many thanks,

Chris





On Tue, Dec 3, 2013 at 1:52 AM, Imesh Gunaratne <im...@apache.org> wrote:

> Hi Chris,
>
> There was no requirement to expose a SOAP/REST API in the load balancer.
> Therefore there is no WSDL/WADL added.
>
> BTW if your requirement is to examine the behaviour
> of TopologyEventProcessorChain it shouldn't be that difficult. Basically
> each processor corresponds to its event, if it didn't find the required
> event it will pass the call to the next processor. Once it finds the
> matching event it will build the Topology in Topology Manager and fire the
> matching event listener.
>
> Thanks
> Imesh
>
>
> On Tue, Dec 3, 2013 at 3:31 AM, chris snow <ch...@gmail.com> wrote:
>
>> In the case of the LB MessageProcessorChain, the following processors
>> have been added to the list:
>>
>> org.apache.stratos.messaging.message.processor.topology.ServiceCreatedEventProcessor
>> org.apache.stratos.messaging.message.processor.topology.ServiceRemovedEventProcessor
>> org.apache.stratos.messaging.message.processor.topology.ClusterCreatedEventProcessor
>> org.apache.stratos.messaging.message.processor.topology.ClusterRemovedEventProcessor
>> org.apache.stratos.messaging.message.processor.topology.InstanceSpawnedEventProcessor
>> org.apache.stratos.messaging.message.processor.topology.MemberStartedEventProcessor
>> org.apache.stratos.messaging.message.processor.topology.MemberActivatedEventProcessor
>> org.apache.stratos.messaging.message.processor.topology.MemberSuspendedEventProcessor
>> org.apache.stratos.messaging.message.processor.topology.MemberTerminatedEventProcessor
>> org.apache.stratos.messaging.message.processor.topology.CompleteTopologyEventIgnoreProcessor
>>
>> In a component that exposes a SOAP/REST API, I would look at the
>> WSDL/WADL to examine the API.  As a WSDL/WADL aren't available for the LB
>> component, how can I examine the API without having to run the code and
>> inspect the MessageProcessorChain?
>>
>> Many thanks,
>>
>> Chris
>>
>
>


-- 
Check out my professional profile and connect with me on LinkedIn.
http://lnkd.in/cw5k69

Re: LB messages processor chain

[Imesh Gunaratne <im...@apache.org>]

Hi Chris,

There was no requirement to expose a SOAP/REST API in the load balancer.
Therefore there is no WSDL/WADL added.

BTW if your requirement is to examine the behaviour
of TopologyEventProcessorChain it shouldn't be that difficult. Basically
each processor corresponds to its event, if it didn't find the required
event it will pass the call to the next processor. Once it finds the
matching event it will build the Topology in Topology Manager and fire the
matching event listener.

Thanks
Imesh


On Tue, Dec 3, 2013 at 3:31 AM, chris snow <ch...@gmail.com> wrote:

> In the case of the LB MessageProcessorChain, the following processors have
> been added to the list:
>
> org.apache.stratos.messaging.message.processor.topology.ServiceCreatedEventProcessor
> org.apache.stratos.messaging.message.processor.topology.ServiceRemovedEventProcessor
> org.apache.stratos.messaging.message.processor.topology.ClusterCreatedEventProcessor
> org.apache.stratos.messaging.message.processor.topology.ClusterRemovedEventProcessor
> org.apache.stratos.messaging.message.processor.topology.InstanceSpawnedEventProcessor
> org.apache.stratos.messaging.message.processor.topology.MemberStartedEventProcessor
> org.apache.stratos.messaging.message.processor.topology.MemberActivatedEventProcessor
> org.apache.stratos.messaging.message.processor.topology.MemberSuspendedEventProcessor
> org.apache.stratos.messaging.message.processor.topology.MemberTerminatedEventProcessor
> org.apache.stratos.messaging.message.processor.topology.CompleteTopologyEventIgnoreProcessor
>
> In a component that exposes a SOAP/REST API, I would look at the WSDL/WADL
> to examine the API.  As a WSDL/WADL aren't available for the LB component,
> how can I examine the API without having to run the code and inspect the
> MessageProcessorChain?
>
> Many thanks,
>
> Chris
>