On Mon, Jul 7, 2014 at 8:05 AM, Udara Liyanage <ud...@wso2.com> wrote:

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

If so, Autoscaler does not need to get any information from the event
published by SM. Then service call is better IMO.

Thanks.

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



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

Reply via email to