wsrp-wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [wsrp-wsia] [I#181] registration changes
- From: Gil Tayar <Gil.Tayar@webcollage.com>
- To: wsrp-wsia@lists.oasis-open.org
- Date: Tue, 10 Dec 2002 10:18:57 +0200
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC