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: firstname.lastname@example.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.
Powered by eList eXpress LLC