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.
Regards, Ivo -----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Bram de Kruijff Sent: donderdag 23 december 2010 15:55 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] Service Fabric testdrive Hi Marcel, On Thu, Dec 23, 2010 at 2:18 PM, Marcel Offermans <marcel.offermans at luminis.nl> wrote: > Hi Bram, > > On Dec 22, 2010, at 16:36 , Bram de Kruijff wrote: > >> as promised I have updated the mechanism description of the Service >> Fabric at http://www.amdatu.org/confluence/display/Amdatu/Service+Fabric. > > Some feedback about that page: > > ClusterMemberService API: > I would prefer a whiteboard style approach for ClusterMessageListeners and > remove the subscribe/unsubscribe. In fact, I would model this more after > EventAdmin / EventHandler and add service properties to a listener can > express what he is interested in. Alternatively, why don't we use EventAdmin > for this? Agreed, should be whiteboard. I'll look into eventadmin. > Let's remove getClusterId() and getMemberId() since those are also available > as service properties (I assume). In general I am in favor of keeping a > service API as small as possible, so there should be only one way of doing > something. Convenience methods don't belong in an API, but should move to a > utility class that a service consumer can use if appropriate. Not sure. Many collaboratots depend on the service using dependeccymanager. This provides easy access as they typically get the serviceObject injected and would require boilerplate to get to the service properties. Same argument can be made for junit testability. I need to think about it some more :) > What does getProperties() do exactly? Do they need to be exposed this way, or > should we just publish them as service properties as well? I have set this up to be groupware implementation independent (using Apache Tribes at this point). This is just a generic way of passing along implementation specific properties. Guess it is not very elegant. > ClusterMessageService API: > If we expose this API, why even have similar methods in ClusterMemberService. > I would say, going by the name of the service, they belong here and not in > the ClusterMemberService. The ClusterMemberService broadcast/send methods are very low level. ClusterMessageService publish puts topic based pub/sub and some routing support on top but uses the ClusterMemberService broadcast/send underneath so it needs that interface. Could split if of of ClusterMemberService into ClusterBroadcastService or something. > In general, some of these methods might throw exceptions, we should define > those. True, I'll restart our service API design discussion ones this stabilizes :) > Also, each target (OSGi framework) will also have some unique ID that is used > by the management agent to identify itself. I suspect the "member ID" is also > some unique way to identify a framework. We should consider using the same > for both to prevent having to keep a mapping. I'd like one Amdatu node identifier for sure and I would like to use that. I think there should be an AMA service that publishes it and we can depend on. Having said so clusterId as I use it now is not suitable as there can be multiple per AMA. >> The current implementation in the sandbox is alpha but fuly >> functional. Constraint right now is that the discovery requires mcast >> over 8080 so a firewall may prevent you from doing this in a LAN. > > 0) Build Amdatu itself, as this project depends on it. Correct :) >> Getting started: >> 1) Checkout http://subversion.amdatu.org/svn/amdatu/sandbox/bdekruijff/fabric >> 2) mvn package >> Some things on the TODO list: >> 1) Make the whole thing manageable (FabricManager) > > Definitely, and I can see this component interacting with ACE whenever it > decides to change the topology of the cluster (ie add new "members", > distribute the software in a different way, etc..). Another interaction could > be with an "audit log" that collects usage data of individual nodes (a node > being a virtual machine that can run multiple JVMs that in turn can run > multiple OSGi frameworks). Definitely! I was also thinking along those lines as it would provide one generic infrastructure for Amdatu internal cluster communication making things a lot more manageable. We could indeed even consider adding file transfer support at some time. >> 2) Support multiple logical clusters on one node (testing) > > I can see other uses for this as well, such as separating "core" services > from those the application developer sees (in distributed environments). Yup, the way I am setting this up right now is support for multiple clusters per node with multiple remote services layers on top without a one-to-one or fixed mapping. This would support nodes participating in multiple clusters with possibly different topologies (For example a 'Amdatu Management Cluster' and as a 'Tenant Node Cluster' which would be a subset. It would also support tenant specific remote services either on a tenant specific cluster or on a shared one for isolation/qos purposes. I think we will have a hard time figuring out which topology style to use :) >> 3) Extend management options and commands (testing/moitoring) >> 4) Support for ip-list based discovery (mcast optional) > > Agreed, as I don't think multicast will work too well in a cloud. > >> 5) Finetune Apache Tribes configuration (performance / security / trust) >> 6) Test! > > Yup, we should also make sure we somehow benchmark it and try to compare it > to other solutions, or to some theoretically calculated speed (for example > based on the fact that we assume that the protocol should be I/O bound). Agreed. Right now setting up some arbitrary benchmarks for comparing performance between inplementation choices in the 'fabrictest' project in my sandbox. In the future I would really like to see alternative implementations (Apache Mina / Terracotta) and/or supporting alternatives to Serialization (Externalizable / Hessian). Given infinite time... :) >> Let me know what you think. > > I think it's a great start. I would love to see something we can very easily > deploy into any framework to get this going as I think having a good remote > services implementation is key to our system. Yes, I think it is very generic and am thinking using it in some other projects as well. Only external dependecy at present is dependecymanager as Apache Tribes is embedded. Regards, bram _______________________________________________ Amdatu-developers mailing list Amdatu-developers at amdatu.org http://lists.amdatu.org/mailman/listinfo/amdatu-developers
