On Fri, Dec 24, 2010 at 4:56 PM, Ivo Ladage-van Doorn <Ivo.Ladage-vanDoorn at gxsoftware.com> wrote: > Hi Bram, > > My primary question is how this relates to tenant management. I would expect > that remote services are only only registered in a local container when > certain conditions are met. These conditions depend on the tenants hosted on > the local container, the tenant of the remote service (in case its tenant > aware) but also on the 'contract' of the tenants. I think in the end the AMS > defines for each AMA what services are remotable and which remote services > are registered in the local service registry. > For example, AMA 1 hosts an isolated tenant 'A' and does not accept any > tenant aware remote services to be registered in its local container. AMA 2 > hosts tenant 'B' and accepts tenant aware services for tenant B to be > registered in its local container. AMA 3 hosts tenant 'C' and 'D' which > accept remote services for tenant C and D as well as non-tenant aware > services. > `How and where is this logic implemented? If this is not part of the Service > Fabric, some pluggable component should be available which can be implemented > by the tenant service to define what services may be remoted and which > services may be registered in the local registry.
Yes, Ik think we will need some way to do this. No there is no such mechanism yet. At this point the decision to import/export is made solely based on the service registration properties and distribution capabilities of the implementation, conforming to the Remote Services specification. Having said that. There are many way we could address this and I agree this will probably depends on the tenant configuration and deployment specifics. In general, how this will be modelled and at what level we manage this is not yet clear (to me). With regard to the fabric there would be roughly the following approaches. 1) Each tenant has its own cluster infrastructure. This provides isolation at the lowest level and effectively means that any service discovery is limited to it. A tenant will only "see" its own remote services. 2) Each tenant has its own message channel. This provides isolation at the messaging layer and effectively means that any service discovery is limited to it. A tenant will only "see" its own remote services. 3) Tenants share the message channel but discovery "decides" wha top remote where and when based on configuration. 4) Any combination of the above An example of the altter: Suppose you have a hosting environment with 100 AMAs serving 1000 tenants, managed by a central AMS. You could have a shared cluster in the fabric where all AMAs and AMS connect to that serves as the command and control / provisioning / management layer. Now suppose 10 of those AMAs host a distributed application that heavily uses remote services at the appliction level and therefore this communication is of no interest to anyone else. it may prove very inefficient to route all this traffic over the shared message layer and a dedicated (virtual private) cluster for this application's application level services may be a wiser choice. Resume, I think we need something to control remoting and the fabric provides several solution vectors. IMHO, the main challenge we have is the broader concern of getting clear how a tenant is configured, managed and provisionioned. > Regards, Ivo Muchos grz Bram
