stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kishanthan Thangarajah <kshanth2...@gmail.com>
Subject Re: LB messages processor chain
Date Thu, 05 Dec 2013 02:52:27 GMT
On Thu, Dec 5, 2013 at 8:00 AM, Imesh Gunaratne <imesh@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 <chsnow123@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 <udara@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 <chsnow123@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 <imesh@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 <chsnow123@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
>>
>>
>

Mime
View raw message