[wsrp-wsia] [I#181] registration changes

[Gil Tayar <Gil.Tayar@webcollage.com>]

Issue: 181
Status: Active
Topic: registration
Class: Technical
Raised by: Eilon Reshef
Title: registration changes
Date Added: 10-Dec-2002
Document Section:   v0.85/6.*
Description:
Currently, registration serves two purposes:
. To register a particular system (technical characteristics such as Consumer version)
2. To register an entity collection (business characteristics: when de-registering, the entities die)
 
This duality is not only confusing, but also explicitly prohibits useful business scenarios such as:
1. The ability to use multiple portal systems within an organization with the same personalization characteristics
2. The ability to use portal systems of different versions (e.g., v3.2 and v3.5) for different environments (development versus production), while both using the same entities
Etc.
This will force WSRP to invent unnatural workarounds such as explicit APIs for moving and possibly synchronizing entities between registrations.
 
The awkwardness doesn't buy us much, and each one of the following approaches solves the problem without much sacrifice:
 
1. Eliminating registration API, Consumer technical characteristics move to other operations
 
With this approach (which had been discussed in the past), registration becomes out of band. That is, the Producer may supply a URL where Consumer administrators come in, enter any data, and eventually receive a registrationKey, which they plug into their systems. To unregister, they return to this URL and manually unregister.
 
To supply the Consumer technical characteristics, a new structure (e.g., ConsumerSystem) has to be passed in the other API calls whenever registrationKey is passed today.
 
2. Leaving registration API, using it for Consumer technical characteristics only
 
With this approach, registration API stays as-is. However, the spec would no longer specify that an Entity ""belongs"" to a certain registration or a registration scope. That is, the same entity can be reused across multiple registrations. This probably means that the registration should be called registerConsumerSystem.
 
This alleviates the need for modifyRegistration, since the Consumer can always register a new system on its behalf.
 
3. Leaving registration API, using it only for the business characteristics
 
With this approach, registration API remains, but the technical characteristics are being moved into a separate structure called ConsumerSystem, which is transferred on every API call, whenever registrationKey is passed today.
 
The Entities are still managed under the registration scope, but the Consumer may use multiple systems under this registration. There is still a need for modifyRegistration in case some business parameters (e.g., credit card) change.
 
4. Separating registration API into two APIs: one for business and one for technical
 
With this approach, two APIs are introduced:
 
registerConsumerSystem - registers the technical characteristics (Consumer version, etc.).
registerConsumer (or registerConsumerOrganization or registerEntityManagementScope) - registers the business characteristics (properties).
 
Both keys would be passed on every API call. This would still allow multiple physical systems under the same registration and vice versa.
 
IMHO, all the above options represent a better model of real-life situations compared to the existing model which seems to be flawed.