[wsrp-wsia] Issues Resolved in 7-Jan-2003 call

[I#154] rename "entity" to "portlet" or "portlet type"
Issue: 154
Status: Resolved
Topic: general
Class: Technical
Raised by: Eilon Reshef
Title: rename "entity" to "portlet" or "portlet type"
Date Added: 7-Nov-2002
Document Section:
Description:
As the word "entity" is too general, and because we have finally given a name to the thing that we are "showing", why not rename entity to "portlet" or "portlet type"
Resolution: portlet & Producer configured-portlet/Consumer configured-portlet where the distinction is necessary

[I#170] Scope of Producer-Consumer HTTP session
Issue: 170
Status: Resolved
Topic: interface
Class: Minor_Technical
Raised by: Yossi Tamari
Title: Scope of Producer-Consumer HTTP session
Date Added: 4-Dec-2002
Document Section: v0.85/3.13
Description:
"In the Transport Issues section of the spec it says: ""Consumers that manage transport layer issues, such as cookies, MUST return them to the Producer only for subsequent invocations using the same userContext."".
, since the userContext may change because the user's role/profile has changed, but he is still in the same session, so the same cookie should still be sent. On the other hand, the user may have logged out of his portal (closed his browser) and logged in again, but normally his user context hasn't changed. In this case there should be no requirement to send the cookie (it is a new user session, and a new load-balanced instance may be used).
I think the scoping here should be to the consumer's concept of user-session rather than to the userContext."
Resolution: The maximum scope is the scope of the Consumer client's logical session (and being vague about what a session is)

[I#175] Roles should be per-Entity and not per-Producer
Issue: 175
Status: Resolved
Topic: interface
Class: Technical
Raised by: Eilon Reshef
Title: Roles should be per-Entity and not per-Producer
Date Added: 10-Dec-2002
Document Section: v0.85/4.1.7
Description:
RoleDescription[] - should it be per each Entity and not per Producer? The current model only supports roles per Producer which works when the Producer is a centralized portal environment, but makes it much harder to manage and deploy changes in less controlled environment. For example, this means that if a development environment allows portlet developers to define custom roles per portlet (e.g., if one Producer may span multiple web-apps in J2EE), then the Producer must continuously accumulate all roles from all its portlets to present a coherent role list. And, the Consumer needs to sample that list more often to ensure that there are no changes. Another example is how would an application-level-WSRP-proxy support multiple services with different roles?
Resolution: Leave it as it is

[I#179] 7-Jan-2003 requestParameter semantics unclear
Issue: 179
Status: Resolved
Topic: interface
Class: Minor_Editorial
Raised by: Eilon Reshef
Title: requestParameter semantics unclear
Date Added: 10-Dec-2002
Document Section: v0.85/5.1.6
Description:
"requestParameters: I am not sure what the intent of this variable is.
it can mean three different things:
1. Data items passed as part of the action URL - this seems redundant as the Producer can easily use navigationalState.
2. Data items passed as <form method=get> submit? Is this indeed the case?
3. Data items passed as <form method-post> submit? Is this indeed the case?
Note that (2) and (3) are accessed using the same API in J2EE but not in ASP, so if the intent is also for (2) and (3) then we may need to differentiate."
Resolution: Add an interaction parameter - wsrp-interactionState relevant to Interaction actions, which is to be passed only to perform*Interaction. Remove requestParameters.

[I#181] registration changes
Issue: 181
Status: Resolved
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:
[I#The ability to use multiple portal systems within an organization with the same personalization characteristics] The awkwardness doesn't buy us much, and each one of the following approaches solves the problem without much sacrifice:
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.
"
Resolution: registration is still in. It was decided not to rely on it to pass Consumer information that is essential to the portlet using this mechanism.

[I#183] markup charset different or the same as the XML response charset?
Issue: 183
Status: Resolved
Topic: interface
Class: Technical
Raised by: Gil Tayar
Title: markup charset different or the same as the XML response charset?
Date Added: 9-Jan-1900
Document Section:
Description:
It is not clear from the spec whether the charset of the markup can be different from the XML response charset. I think that in the F2F we decided that it should be the same, but opinions vary. If they are the same, then the spec should be altered somewhat. If they can be different, what does it mean? How can I return a UTF-16 character set markup inside a SHIFT_JIS response? Is there any meaning at all for this?
Resolution: They are the same, except when using attachments. The editors should state this in the spec.

[I#185] Remove concept of Roles from the spec
Issue: 185
Status: Resolved
Topic: interface
Class: Technical
Raised by: Rich Thompson
Title: Remove concept of Roles from the spec
Date Added: 15-Dec-2002
Document Section: v0.85/various
Description:
"Roles as they exist in the current draft are assertions by the Consumer of the access controls that should be applied for this invocation by both the Producer and entity. As such they potentially restrict access both to the functionality of the Producer and the content afforded by an entity. WSRP is not the right place for defining how a web service and its client jointly determine the security context for a particular invocation, but
specs such as WS-Security, SAML, XACML, JSR109, ... provide the relevant definitions. As a result, I think that roles do not belong being defined by WSRP."
Resolution: Rename "role" to "userCategory".

wsrp-wsia message