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

Reply via email to