I think Kurt can comment more on this subject when he's able, but here's my take. At the moment nothing calls unRegisterService within the ESB because it's a potentially insecure and unsafe thing to do just out of hand, i.e., there needs to be more infrastructure behind this to ensure that one party doesn't take down a service that others are relying on.
The reason for why there is no registerService is probably related to the difference between the notion of a service and the EPRs that actually provide that service. Within JBossESB, a given "logical" service may actually be provided by many different physical services, all of which are identified by EPRs (a single service execution may itself be represented by several different EPRs concurrently). So in effect there is a 1..* mapping between service name/category and EPRs. The way the Registry interface is currently provided, the first EPR that is added for a given name/category will create the service entry in the registry and add that EPR. You can remove EPRs from a service at any point (we make the assumption that this is ok, but again we need to review this later and add in security, e.g., ACLs).
Hopefully you can now see why calling unRegisterService within the ESB is such a big deal: you will remove all of the EPRs from the registry. Since we don't have the necessary hooks (ACLs) in place yet, the best thing to do is punt this to the application at present.
OK. But what about situation when I have some service (let's call it service A) with ERPs A1 and A2. I want to replace this service by new version with different EPRs (A3 and A4). Of course it will work during "normal" server work. But what will happen in case when:
1. Start server
2. Deploy 1st version of service A (EPRs: A1 and A2)
3. Server crash
4. Replace service by 2nd version (EPRs: A3 and A4)
5. Start server
Server will register EPRs A3 and A4, but what about old (incorrect) EPRs A1 and A2)? Registry doesn't know that registering A3 and A4 means registering service A again. If we have registerService method in Registry interface (for example with List of EPRs as parameter, or with only first EPR as parameter) we could delete incorrect EPRs in such case.
There's the unregisterEPR option.
I understand that while undeploying services, the unregisterEPR method is running. But after server crash EPRs are still in registry, and later after server start new EPRs will be registered. Registry doesn't now that registering new EPRs means registering service again in this case. So registry just adds new EPRs but doesn't delete old ones. And because there are no longer any service which use A1 and A2 EPRs, that EPRs will not be unregistered (by the way using unregisterService method could solve this problem I think)
Yes, this is a known issue. I'm sure we had a JIRA for this, but can't find it so I created another.