MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfacesdocument
Eilon - my comments are embedded in [CL] tags
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B�blingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+----------------------------->
| | Eilon Reshef |
| | <eilon.reshef@webc|
| | ollage.com> |
| | |
| | 06/10/2002 08:31 |
| | PM |
| | Please respond to |
| | Eilon Reshef |
| | |
|---------+----------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org |
| cc: |
| Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces document |
| |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
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.
[CL] In the spec we tried to avoid this by allowing the consumer to
explicitly create sessions that can then be shared only amongst the
portlets that need session sharing. You are right that in the case that
there was only one session per producer that producer would have to do some
namespacing to shield the portlets from each other.
But I am afraid that there is no common agreement on this topic in the WSRP
group at the moment, we will discuss it in today's call.
[CL]
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.
[CL] I think that introducing arrays as arguments to the various methods
provides a simple means for saving roundtrips without much complexity. The
consumer is not requested to do so, in the SOAP message the difference
between a single parameter an a parameter list with only one parameter
would not even be visible. If we could have batch processing only when
"tweaking" the transport I suppose that this will practicall never be
exploited. In addition how could a generic prodcuer detect this fact and
use e.g. parallel rendering to minimize response time.
[CL]
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.
[CL] I totally agree with both of your comments but do not see why this
conflicts with the interface proposition.
[CL]
Eilon