stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Udara Liyanage <ud...@wso2.com>
Subject Re: Service Grouping and Composite Application Deployment
Date Mon, 07 Jul 2014 15:05:50 GMT
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 <lahirus@wso2.com> wrote:

>
>
>
> On Sun, Jul 6, 2014 at 9:39 PM, Isuru Haththotuwa <isuruh@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 <lahirus@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 <isuruh@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: lahirus@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: lahirus@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

Mime
View raw message