This may or may not be a requirement on the higher level services that sit on top of JBoss/Remoting, but wanted thoughts on this use-case.
Picture a cluster of remoted services sitting out on the network. Services come up and down during the normal life of the network, and each service is utilizing the MulticastDetector to auto-discover things as they come and go.
How does one of those individual services know what KIND of service it discovers?
The NetworkRegistry has a JMX notification mechanism - so each individual service is getting notifications that include info like the locator URL of the newly discovered service, the domain name, etc. etc. But, that information is the SAME no matter what KIND of service has been discovered.
Is there a way to customize that notification information?
To be more specific, here's my actual use-case. Each machine on the cluster has an "agent" running on it. Each "agent" wants to connect to a main "server". There is only one "server" service running on the network - the "mothership"; think hub-and-spoke where the mothership server is the hub and all agents are the spokes. All "agents" want to communicate with the mothership server. As the agents come up, they use the NetworkRegistry to auto-discover all the services on the network - looking specifically for the mothership server. When it finds the mothership server, it sends some information to it.
Question - when an individual agent gets auto-discover notifications, how can it know if the newly discovered remote service is the "mothership" or just another agent? Agents don't care about other agents, only cares to find the mothership.
Ignore other solutions like "just tell the agent through a configuration file the locator URL of the mothership". I want this auto-discovery to allow the agent to automatically find the mothership - allowing the mothership to move around to other machines on the network should it have to. I also might like to have the ability to have more than one mothership.
I suppose the agent can send a message to the remote service and ask it "are you a mothership" but if you picture 1,000s of agents, you don't want to flood the network with these query messages everytime a new agent or mothership comes online.
This has been something I have been thinking about for a while, but have not had a use case to push it yet (until now). Currently, the best solution would be to add custom parameters to your locator url. For exaple, can add via configuration something like 'mothership=true' as a parameter to your mother ship server locator urls. Then client can get all the registered servers from the NetworkRegistry and get their locator url parameters as a Map to see which ones are mothership.
In the future, I would like some way to expose information about the handlers for the servers as well. This would certainly include the subsystem they were added as and possibly some kind of other metadata (i.e class name, user defined, etc.). This could be added to the detection message and thus the NetworkNotification that gets fired upon new servers being discovered.
Feel free to pitch ideas.
Pitching another idea: ServerInvokerHandler can have a method like "getType" or whatever. It returns either an Object (that can be serialized of course) or a type that JBoss/Remoting provides (let's call it HandlerType for sake of discussion). When I write my Handler subclass, I not only overload invoke() but I have the option (don't have to) overload getType() in which I return my own class with my own type information that identifies the KIND of service I am.
HandlerType provides identification info about the server. I can use it or extend it to have it hold my custom data. Maybe its just a Map of name/value pairs, maybe its something for sophisticated.
The point is, this HandlerType info gets sent to the NetworkRegistry and multicast to other nodes. NetworkRegistry passes this HandlerType as part of the Notification message.
I don't know how this works in the design of JBoss/Remoting - can an InvocationLocator URL have mutiple handers (and thus multiple HandlerTypes associated with a discovered service). I believe you can have multiple handlers, each in a different subsystem. But I'm sure we can work with that (perhaps you get an array of HandlerTypes from the Notification message the NetworkREgistry emits).
The reason why I bring up this is that it introduces an Object Oriented way of identifying the remote servers, as opposed to the flatter way of name/value pairs the URL parameters introduce. Having name/value pairs to identify the remote server isn't really the right way to go since it really does not help in identifying the LOCATION of the remote server. IMO, that's what the InvokerLocator URL should do and only do. IT should not contain superfluous information that doesn't help in determining the endpoint location of the server.
Think you are right about locator url being just for the location of the remote server. Will add the extra handler info to the detection messages.
Have created jira issue JBREM-87 for this.