While starting to develop Remoting 3 services in earnest, it occurs to me that the term "group name" is a bit confusing. It identifies a unique instance of a service within an endpoint more than anything. So I'd like to put the idea of changing this method name on the table, before we lock in to a final release in AS.
The reason "group name" was chosen was that it was intended that same-named instances of services located on different endpoints could act as a "group" of which the service is a member. However in most actual use cases I think this is going to be a secondary application; generally the name will be used to distinguish between more than one instance of the same service type on a single endpoint.
The change is mainly a documentation-only change, however a few public members are affected. The get/setGroupName methods in the service builder and service listener APIs would be renamed, and the ServiceURI.getGroupName() and validateGroupName() methods would be renamed. Finally, the remoting-3.1 XML schema would have the group-name attributes renamed.
Unless anyone has any screaming objections to this, I'll plan on it for Beta3.
So, service type and group (instance) name are analogous to interface and implementation, I guess, so the name could be derived from that analogy, as well. But "instanceName" seems OK, too.