Title: Message
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:]
Sent: Friday, June 07, 2002 3:38
PM
To: ;
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)
