OASIS Web Services for Remote Portals (WSRP) TC

WSRP/WSIA Telecon 10/17/02

Roll

Minutes last week accepted

Prospective members who've attended 3 meetings to be voting members.
Review Tentative Resolutions
31, 35, 23, 34, 57, 74 are still open
All other issues will be closed by tomorrow, pending any other objections.
#24 Previous window state and mode
Remove�propose vote?
Gil: Request from Consumer?
Rich: From Consumer to Producer, it's information. Vice versa, it's a request to change.
Carsten: F2F decision was that mode is managed by Consumer.
Motion: Remove constants and semantics related to previous window state and previous mode?
26 yes, 0 no, 3 abstain
#26/#94 isRefresh and getMarkup returning state
Alejandro: JSR does not model isRefresh. JSR does allow property change in getMarkup (render). Would like WSRP to consider having getMarkup do property changes.
Thomas: How important is this to JSR?
Alej: No clear reason to limit developer flexibility. We have some use cases
Thomas: Summarize use cases?
Alej: blocking/non-blocking action. If you're not changing state, yet still performing an action, it would be more efficient to do one roundtrip.
Rich: the question is putting a burden on the developer to ensure that state changes during getMarkup are "safe".
Mike F: It shouldn't be a MUST, more of a strong recommendation.
Charlie: There's not presently a mechanism in getMarkup to carry property changes.
Bruce: So this just means that some JSR portlets aren't WSRP compliant.
Thomas: WSRP and JSR do need to be consistent.
Gil: How does JSR intend Consumer to do copy-on-write semantics?
Alej: Is copy-on-write part of WSRP. Hard to model in JSR.
Thomas: Should this be re-discussed in the JSR?
Alej: I have problems with the copy-on-right programming model. Seems like odd semantics.
Thomas: We should set up a separate call to discuss this topic.
Mike F: Still need to hear the main objections to allowing state changes in getMarkup.
Thomas: getMarkup would need to have the stateChangeOK flag, and the copy-on-write scenario could occur either way. Also if an entity is shared, parallel getMarkup could cause collision.
Rich: (to Alej) you're withdrawing #26. Alej: Yes.
Rich: Does the copy-on-write semantics in the draft reflect the F2F? (consensus: Yes).
Alej: One objection would be if there is a txn covering the interaction�you'd need to rollback if there was a copy-on-write "fault"? That's complex.
Gil: But the Producer would know ahead of time that it MAY make changes to persistent state.
Thomas: Some backend changes wouldn't necessarily be reflected in properties..i.e., opaque state changes could trigger a copy-on-write.
Gil: Backend changes aren't the issue for this model. It's user-specified changes that are important, and that's what the flag is for.
Rich: Email discussion around this: Andre raised the issue that cloneEntity(refHandle) actually means cloning the runtime state. Also Mike F's observation that the flag could be tri-state, for better efficiency.
Carsten: This is an optimization?
Rich: That was my first response.
Gil: Drop stateChangeOK=False?
Charlie: This could be carried by access restriction instead.
Rich: Would prefer a larger-grained (than request level) restriction.
Alej: Email the main ideas.
Rich or Mike will email
Carsten: Recall from early F2F that we don't create entities "under the hood". This has changed?
#6 groupID required?
Rich: either remove it, or keep it but improve the semantics.
Carsten: If removing it, that means that there is one JSR Producer to an application.
Mike F: That's not a hard requirement. The Producer could distinguish which entities belong to which applications. The Producer could itself do the grouping opaque to the Consumer.
Carsten: Doesn't this break load balancing
Mike F: Yes, but that's J2EE semantics. If you put everything in one Producer, it's not going to be load balanced anyway.
Alejandro: Why is load balancing broken in this case?
Carsten: Current JSR requires same HTTP session. Without information from the Consumer, how can the Producer partition entity runtime state cross-cluster?
Mike F: Producer is load balanced, but the applications are not. If the Producer wants to do app-level load balancing, it will need to do special handling.
Andre: Still think it could be done by forwarding the request.
Mike F: But that's still not the servlet model. Andre: Agree
Andre: With groupID, you could accomplish more than one HTTP connection.
Mike F: That's specific to the SOAP stack. Some stacks could allow you to move cookies between connections. But that's regardless of the groupID question.
Mike F: Still look at this as a vendor extension. Haven't seen a convincing proposal for how the Producer would find this useful.
Carsten: JSR requires one session per application. GroupID is one such mechanism. Or could have mandatory metadata that assigns portlet groupings that the Consumer must honor.
Mike F: Why does the spec "fall apart" without groupID?
Carsten: Imposes great complexity on the Producer because the "special handling" required to do necessary grouping, i.e. JSR app-scope.
Mike F: Your definition of groupID is a set of entities?
Carsten: Yes
Andre: We're likely to not want to rely on transport-specifics like cookies. We still want grouping for Consumer-specified sharing.
Mike F: That's different from Producer partitioning, which is Carsten's main concern.
Thomas: Should have one well-defined sharing semantic�JSR?
Mike F: Yes. Worries about the slippery slope of considering other, ie. Consumer, specified sharing semantics.
Andre: Specializations could be built off the groupID, without breaking interoperability.
Mike F: Agree. But it's expressed as an extension. Still think we can carry the grouping information as metadata, remove groupID from the protocol.
Carsten: That makes us transport protocol-dependent. I could live with this as a bare minimum.
Rich: Two proposals: Producer metadata instructs Consumer about how it needs to call initEnvironment, or states initEnvironment isn't needed.
Carsten will write up metadata proposal, circulate it among Rich, Andre, et al.
#84 secureClientCommunications more than a Boolean?
Rich: How slippery a slope? Could become very involved
Sasha: Boolean doesn't express much.
Rich: This could be expanded on in the SOAP header in later versions.
Sasha: That's fine. I don't feel strongly about it, so it could be withdrawn.
Alej: JSR exposes if client connection is secure (Boolean), and also auth types.
Rich: How does this play if there are more than one hops between Consumer and Producer?
Alej: Shouldn't it be a String to carry auth type?
Mike F: It's a separate issue, so we should track it as a potention interop issue between JSR and WSRP.
Gil: This is useful info to carry, since WSS probably won't carry it.