Hi Kishanthan, Via a AMQP transport header which has the event class name.
On Thu, Dec 5, 2013 at 8:22 AM, Kishanthan Thangarajah < [email protected]> wrote: > On Thu, Dec 5, 2013 at 8:00 AM, Imesh Gunaratne <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > >>>> 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 <[email protected]> > 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/
