But the diagram need to depict all those (if cannot be done using one, using multiple)
The problem with the current one is that, it is hard to connect the dots, as it has only partial info. On Fri, Jul 19, 2013 at 6:47 AM, Ajanthan Balachandran <[email protected]>wrote: > > > > On Fri, Jul 19, 2013 at 6:28 AM, Samisa Abeysinghe <[email protected]>wrote: > >> So, if this design is proposing the MT AF deployment, should we not look >> at the whole architecture, not just the registry separation? >> > When we started to look at this aspect we found that governance > registry,userstore ,billing and throttling are shared aspects in one > stratos deployment. > Hence each cloud in environment(as cloud) is considered as service by > stratos the billing and metering,it can be done per environment basis. > >> >> Registry is an important aspect. But IMHO, there is more into it. User >> store is a good one. >> What about caching, dep-sync and concerns similar to those? >> > Other aspects are connected with clustering.So any way those are > seperated.(as dev cluster caching and as test cluster caching are isolated > because of different clustering domain) > >> >> >> >> On Fri, Jul 19, 2013 at 6:22 AM, Ajanthan Balachandran <[email protected] >> > wrote: >> >>> Yes,If you compare previous AF deployment pattern and proposed pattern >>> only difference is separate governance registry per environment,We already >>> have MT in runtime(Stratos) so that will not >>> change with MT AF.Only Change is previously we provided one isolated >>> runtime per application.But now in MT AF all the apps in one tenant will >>> share one runtime. >>> Ideally we have to provide userstore per environment.That should be >>> supported out of the box.But this proposes maximum shared deployment that >>> can one achieve in MT AF . >>> >>> >>> On Thu, Jul 18, 2013 at 6:35 PM, Samisa Abeysinghe <[email protected]>wrote: >>> >>>> So what is this thread proposing? A new MT architecture or a slight >>>> improvement to existing preview >>>> >>> >>>> >>>> On Thu, Jul 18, 2013 at 1:16 PM, Dimuthu Leelarathne <[email protected] >>>> > wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> >>>>> On Thu, Jul 18, 2013 at 6:46 AM, Samisa Abeysinghe <[email protected]>wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> I am not sure if this will be right. What does this user store >>>>>> contain? Does it only allow auth to AF aspects only or does it also auth >>>>>> apps too. >>>>>> >>>>>> If I map this to the internal WSO2 stuff, AF development users >>>>>> internal LDAP, and apps to are authorized against the same LDAP. But >>>>>> those >>>>>> apps, before being hit into production are not using the the production >>>>>> LDAP rather a replica. Becuase, those developing the apps are not >>>>>> supposed >>>>>> to mess with the production user store. >>>>>> May be the solution is to have the AF user store to be separate form >>>>>> the Apps user store to be an IS instance plugged into AF. >>>>>> >>>>>> Still, for the common use case, you cannot rule out the use of a >>>>>> different "user store" for production AS in the production cloud. So I am >>>>>> not sure if this shared user store concept will work. >>>>>> >>>>> >>>>> Current afpreview implementation does not support the above deployment >>>>> scenario but the new code will support both deployments and many >>>>> deployment >>>>> options. It is a matter of writing the BPEL right. So in the case of >>>>> production AS having a different user store we will have to change the >>>>> BPEL. >>>>> >>>>> >>>>> thanks, >>>>> dimuthu >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> Here we have problem because of different governance registry used >>>>>>> for services in environment and Stratos controller(SC).whenever tenant >>>>>>> is >>>>>>> created in stratos controller >>>>>>> in addition to userstore changes SC is adding some additional stuffs >>>>>>> to governance registry(service activation details etc..).To solve this >>>>>>> problem we can have additional service >>>>>>> which will be do the post tenant creation activities on tenant >>>>>>> creation . >>>>>>> This services will be hosted in a dummy SC in each environment.This >>>>>>> manager will evaluate throttling rules and update governance registry >>>>>>> per >>>>>>> environment.By doing so we can have different throtling rules per >>>>>>> environment. >>>>>>> >>>>>>> Any suggestions or improvements are welcome. >>>>>>> >>>>>>> -- >>>>>>> ajanthan >>>>>>> -- >>>>>>> Ajanthan Balachandiran >>>>>>> Senior Software Engineer; >>>>>>> Solutions Technologies Team ;WSO2, Inc.; http://wso2.com/ >>>>>>> >>>>>>> email: ajanthan <http://goog_595075977>@wso2.com; cell: +94775581497 >>>>>>> blog: http://bkayts.blogspot.com/ >>>>>>> >>>>>>> Lean . Enterprise . Middleware >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Thanks, >>>>>> Samisa... >>>>>> >>>>>> Samisa Abeysinghe >>>>>> VP Engineering >>>>>> WSO2 Inc. >>>>>> http://wso2.com >>>>>> http://wso2.org >>>>>> >>>>>> _______________________________________________ >>>>>> Architecture mailing list >>>>>> [email protected] >>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Dimuthu Leelarathne >>>>> Architect & Product Lead of App Factory >>>>> >>>>> WSO2, Inc. (http://wso2.com) >>>>> email: [email protected] >>>>> Mobile : 0773661935 >>>>> >>>>> Lean . Enterprise . Middleware >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Thanks, >>>> Samisa... >>>> >>>> Samisa Abeysinghe >>>> VP Engineering >>>> WSO2 Inc. >>>> http://wso2.com >>>> http://wso2.org >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> ajanthan >>> -- >>> Ajanthan Balachandiran >>> Senior Software Engineer; >>> Solutions Technologies Team ;WSO2, Inc.; http://wso2.com/ >>> >>> email: ajanthan <http://goog_595075977>@wso2.com; cell: +94775581497 >>> blog: http://bkayts.blogspot.com/ >>> >>> Lean . Enterprise . Middleware >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> >> Thanks, >> Samisa... >> >> Samisa Abeysinghe >> VP Engineering >> WSO2 Inc. >> http://wso2.com >> http://wso2.org >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > ajanthan > -- > Ajanthan Balachandiran > Senior Software Engineer; > Solutions Technologies Team ;WSO2, Inc.; http://wso2.com/ > > email: ajanthan <http://goog_595075977>@wso2.com; cell: +94775581497 > blog: http://bkayts.blogspot.com/ > > Lean . Enterprise . Middleware > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
