There are several things to keep in mind when considering support for WSRP Registration. The overall idea is that Consumers can register themselves with a Producer, if the Producer requires so.
Consumers identify themselves via a name and an agent version. According the spec:

consumerName: A name (preferably unique) that identifies the Consumer [R355]. An example of such a name would be the Consumer's URL.

Interestingly enough, requirement R355 (http://www.oasis-open.org/committees/wsia/documents/Requirements2002-09-17.html#R355) mandates that the name must be unique. So there's one contradiction right there. However, in doubt, we'll trust the spec which only says that it'd be preferable that the name be unique, meaning we cannot expect Consumers to provide us with globally unique names.

However, we still need to identify uniquely a Consumer and be able to do so based on its name and given registration properties. Once the Consumer is registered, we can rely on the Registration handle to uniquely identify which Consumer we're dealing with. To do so, we distinguish between a Consumer name (provided via WSRP) and its internal identity, which MUST be unique. Note, however, that there is no necessary connection between a Consumer's identity and its database primary key. Both could be the same or different.

Our implementation of Registration is handled by a set of class which are façaded by RegistrationManager. This is the entry point to the whole Registration sub-system and through which all interactions should go. The decision was made to proceed this way and use externally non-modifiable Registration objects to prevent invalid modification of a Registration distributed state.

In addition to the concepts of Consumer and Registration, we also provide a ConsumerGroup concept which allows people to group related Consumers for easier batch processing.

We identified several aspects that could be configured as far as how Registrations should be processed and provide an entry point to extend/modify the default behavior in the form of the RegistrationPolicy which provides means for deployers to customize how to handle specific cases. In particular, which registration data to accept, how registration handles should be created, whether to use ConsumerGroups or not and how a Consumer identity is generated/accepted based on the provided registration data.

We provide a default implementation of RegistrationPolicy which, in particular trusts the Consumer to provide a unique identifying name.

Another point that's not quite clear in the spec is, despite the fact that a Consumer can register several times, how to discriminate between the different registrations and what they mean (which is, granted, somewhat outside of the scope of the spec). RegistrationPolicy provides for ways to accept/reject registration data. The default implementation only accepts multiple registrations if they are done using different settings.

We would like to hear from WSRP users about their needs with respect to Registration. As usual though, while suggestions are welcome, no promises are made as far as their actual implementation! :)