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

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.