HI Lahiru, As I understood, SM sends the details to the CC via service call or event based, then CC update the topology and publish topology events.
On Mon, Jul 7, 2014 at 6:09 PM, Lahiru Sandaruwan <lahi...@wso2.com> wrote: > > > > On Sun, Jul 6, 2014 at 9:39 PM, Isuru Haththotuwa <isu...@apache.org> > wrote: > >> Hi Imesh, >> >> Yes, completely agree. Should have the proper documentation for this. >> Will do that once we have the basic version of this feature done. >> >> Hi Lahiru, >> >> On Sun, Jul 6, 2014 at 7:50 PM, Lahiru Sandaruwan <lahi...@wso2.com> >> wrote: >> >>> Hi Isuru, >>> >>> Any reason why we use MB for subscription event? We can use direct >>> service call to CC IMO. >>> >> That is one option. But its different from the invocation we do through >> the CC to spawn instances each individual service, since now there is a >> startup order and a kill order, etc. Therefore, we need to have a >> 'Composite Application Monitor' in Autoscaler, which will do the spinning >> up, termination of instances in the particular order. For this, its easier >> if we send an event from SM, so that the Autoscaler and any interested >> party can act upon it. >> >> Furthermore, if we use CC's API, there will be several object conversions >> as follows: >> >> JSON bean -> CC's API object -> Messaging Component Application object >> (for the event) >> >> However, if we directly send the event from the SM itself, there will be >> only one conversion: >> >> JSON bean -> Messaging Component Application object (for the event) >> >> Since Composite Application is a complex structure, with nested groups >> etc., it will be better if we can reduce the conversions between these >> objects. Considering all these, IMHO its better if SM sends the Composite >> Application Deployed event itself. >> > > Thanks for the clarification Isuru. > > But aren't we publishing all the topology related events from CC? Does > this event use a different topic? > >> >> >>> Thanks. >>> >>> >>> On Mon, Jun 2, 2014 at 10:52 AM, Isuru Haththotuwa <isu...@apache.org> >>> wrote: >>> >>>> Hi Devs, >>>> >>>> This is an addition to the discussion happened in the thread [1]. I >>>> have included a very basic sequence diagram to show the flow of how Service >>>> Grouping would happen for the initial implementation. >>>> >>>> >>>> composite_app_1.png >>>> <https://docs.google.com/a/wso2.com/file/d/0B4pCC9A49FwCRDhqQ0JDRl9tQjA/edit?usp=drive_web> >>>> >>>> Short description of the flow:. >>>> >>>> 1, 2 & 3. Deploy Components' Definitions that would be included in the >>>> top level Composite Application. Typically, a component would map to a >>>> single cartridge. For sample JSON definitions of a component, please refer >>>> [1]. >>>> >>>> 4. Deploy a Group Definition, which would logically group the relevant >>>> components. This would include information on the Startup Order of each >>>> component, and how to handle the termination/error situations as well (Kill >>>> Behavior). >>>> >>>> 5. Deploy a Nested Group Definition, which would contain one/more of >>>> Components and Groups. >>>> >>>> 6. Deploy the Composite Application Definition. This would map to the >>>> operation 'Subscription' which we have currently, when spinning up a single >>>> cartridge instance. As per the discussion that took place in the above >>>> mentioned thread, this was decided to be called the 'Composite >>>> Application Definition' deployment, rather than a Subscription. >>>> >>>> For the initial version, we can restrict this Composite Application >>>> Definition only to contain information for each group/component, such as >>>> aliases, git repositories and relevant info as required, etc., and not >>>> allow further grouping at this level. >>>> >>>> A typical basic Composite Application Definition, in JSON format, >>>> would be as follows: >>>> >>>> { >>>> "name": "group2", >>>> "alias": "<group2_alias>", >>>> "components": [ >>>> { >>>> "name": "component2", >>>> "alias": "<component2_alias>", >>>> "repoUrRL": "<repo_url>" >>>> } >>>> ], >>>> "groups": [ >>>> { >>>> "name": "group1", >>>> "alias": "group1_alias", >>>> "components": [ >>>> { >>>> "name": "component1", >>>> "alias": "<component1_alias>", >>>> "xxx": "<xxx>" >>>> }, >>>> { >>>> "name": "component3", >>>> "alias": "<component3_alias>", >>>> "yyy": "<yyy>" >>>> } >>>> ] >>>> } >>>> ] >>>> } >>>> >>>> More information is available in the above mentioned mail thread and in >>>> [2]. Please share your feedback on this. >>>> >>>> >>>> [1]. [Discuss] Grouping of services (cartridges) >>>> [2]. >>>> https://docs.google.com/a/wso2.com/document/d/1qnArxF8obhbjMLUbPAENQMn94fPSd3AVqO41mxhnJXE/edit# >>>> >>> >>> >>> >>> -- >>> -- >>> Lahiru Sandaruwan >>> Committer and PMC member, Apache Stratos, >>> Senior Software Engineer, >>> WSO2 Inc., http://wso2.com >>> lean.enterprise.middleware >>> >>> email: lahi...@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 >>> >>> -- >>> <http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146> >>> Thanks and Regards, >>> >>> Isuru H. >>> <http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146> >>> +94 716 358 048 >>> <http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146>* >>> <http://wso2.com/>* >>> >>> >>> * <http://wso2.com/>* >>> >>> >>> >>> > > > -- > -- > Lahiru Sandaruwan > Committer and PMC member, Apache Stratos, > Senior Software Engineer, > WSO2 Inc., http://wso2.com > lean.enterprise.middleware > > email: lahi...@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 > > -- Udara Liyanage Software Engineer WSO2, Inc.: http://wso2.com lean. enterprise. middleware web: http://udaraliyanage.wordpress.com phone: +94 71 443 6897
