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

Title: Message

This is also my preference, leaving it as an 
extension. My second preference would be #3: registration as a entity 
container and not as a persistent descriptor for a Consumer 
system.

  

  
-----Original Message-----
From: Rich Thompson 
  [mailto:] 
Sent: Tuesday, December 10, 2002 2:40 
  PM
To: 
Subject: Re: 
  [wsrp-wsia] [I#181] registration changes

  
My preference is 1' ... drop the registration API so that 
  registration is 
always out of band and do not pass any 
  additional data. Whatever the 
Producer actually needs 
  can be acquired/modified through its out-of-band 
system. 

  
I would note that all of these suggestion decouple 
  registration as scoping 
the lifecycle of Consumer 
  Configured Entities. The question that raises for 
me 
  is whether the response from cloneEntity() should include an expires 
  
field (perhaps with a unit of days) that says unused entities 
  will be 
discarded after some period of time. 
  

  
Rich Thompson 

  
                                                                                                                         
  

  
                      
  Gil 
  Tayar                                                                                          
  

  
                      
  <Gil.Tayar@webcol        
  To:       
                                    
  

  
                      
  lage.com>                
  cc:                                                                       
  

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

  
                      
  12/10/2002 
  03:18                                                                                   
  

  
                      
  AM                                                                                                 
  

  
                                                                                                                         
  

  
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. 

  
---------------------------------------------------------------- 
  
To subscribe or unsubscribe from this elist use the 
  subscription 
manager: <http://lists.oasis-open.org/ob/adm.pl>