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? 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. What does getProperties() do exactly? Do they need to be exposed this way, or should we just publish them as service properties as well? 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. In general, some of these methods might throw exceptions, we should define those. 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. > 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. > 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). > 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). > 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). > 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. Greetings, Marcel
