[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsia][wsrp][wsrp-wsia joint interfaces] Merged interfaces document
Thanks for the kind words ... there have been a lot of discussions on the conceptual level between this version and the previous. Also, Carsten was instrumental in helping merge in the WSRP concepts. To ask your questions about sessions in a stronger way: - Can a Consumer FORCE a Producer to do sessions in a manner the Producer does not want? This would include either requiring sharing OR requiring session independence. I think the answer has to be no. The Consumer does get to indicate preference (it is where the knowledge of the aggregated page lives and this is often important in guiding these decisions), but in the end the Producer is the one who creates and manages sessions. For example, It would not be hard to enforce Producer policies of only 1 session per logged on user OR that each user/entity pairing have a unique session. If there are some natural ways to eliminate the need for arrays in the interface, I think it would be a cleaner interface. Arrays came in at this time due to the request to desing a highly efficient interface and we are starting to settle many of the pending issues on a conceptual level. SOAP does not directly support multiple operations in a network roundtrip, but most of the interesting cases do live on top of the http protocol. If reasonable support exists there, this may suffice for the efficiency concerns. Eilon Reshef <eilon.reshef@webc To: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org ollage.com> cc: Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged 06/10/2002 02:31 interfaces document PM Rich, Kudos on the last version of the spec, it reads great and much clearer and cleaner than previous versions. I would like to add my own two questions based on an initial reading of the document. The semantics of "session" Does a session span all the different portlets/templates/instances provided by a single service? If so, that means that extra care is needed in the case where Producers don't want to share sessions. The most natural example that comes to mind is a simple SOAP gateway that relays requests to multiple even-more-remote Producers. In this case, the gateway has to implement the semantics of session aggregation or do some other manipulation of the message body. Multiple parameters using arrays I concur with a previous comment that it seems unnatural to duplicate every parameter of every call just for the sake of a single network communication. Beyond being unnatural, this also requires the Consumer do to work, and apropos an earlier discussion, would practically preclude using SOAP exceptions (if the Consumer gets an exception, this essentially means that one of of the many services may have failed, and this isn't the regular semantics of exceptions). Unless I am missing something, this networking issue can be solved by the layer that created it (the transport layer) using for example HTTP 1.1. Although existing SOAP frameworks probably don't have built-in support for this, since we are talking about a single generic proxy for all WSRP services, I see no reason why this should be particularly challenging to accomplish. This would also allow multiplexing of different calls (to operations with different signature) without requiring to open a new connection. In general (regarding both of those comments), let's not forget that portal interoperability is an important objective of this committee - but it's just one. The other, which is as important, is to allow ISVs and end customers to create portlets that can work across portals. We have to ensure that the specification does not practically preclude this second objective by optimizing the interface for the first. Eilon -----Original Message----- From: Rich Thompson [mailto:richt2@us.ibm.com] Sent: Friday, June 07, 2002 3:38 PM To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org Subject: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces document Here is a draft of the merged interfaces document that Carsten and I have been working on this week. The largest conceptual change from the previous 0.44 Joint Spec Draft is the appearance of arrays in most of the operations. This allows Consumers on the scale of portals to efficiently interact with Producer services. (See attached file: WSIA - WSRP Interface Specification.doc)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC