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

[Eilon Reshef <eilon.reshef@webcollage.com>]

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:richt2@us.ibm.com]
Sent: Tuesday, December 10, 2002 2:40 PM
To: wsrp-wsia@lists.oasis-open.org
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:       wsrp-wsia@lists.oasis-open.org                                 

                      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>