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 <[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 >> > >
