Title: Message
Carsten,
I don't have an extremely strong feeling as to the question of whether to
leverage infrastructure (HTTP/1.1) for multiplexing or put it as part of the
protocol (it will work both ways). It's clearly an engineering tradeoff (has
advantages/disadvantages, but I feel that the cost/benefit is of putting it
explicitly in the protocol is marginal.
The advantage to it is providing out-of-the-box support for request
multiplexing.
The main disadvantages I see are:
1. Simplicity - naturally a protocol based on arrays is harder to
explain/use (at both ends).
2. Exception handling - with arrays, you would have to re-invent some of
the built-in SOAP exception mechanism. You wouldn't necessarily want the entire
call to fail even if just one portlet fails, and you'd need to return multiple
result types, so you'd also have to create a custom data structure to use
instead of SOAP exceptions.
3. Compatibility with SOAP network infrastructure - this is a concern I
have even in having a single service serving multiple portlets, but is becoming
even more so with multiplexing as part of the protocol. In general, we should
expect software programs such as SOAP gateways, SOAP proxies, SOAP firewalls,
etc. to gradually evolve. With multiple calls multiplexed onto a single call,
such devices would not be able to add value. So, one may argue that a behavior
like the one you described (distributing calls to different places) should be
supplied e.g. by a SOAP gateway based on configuration rules so that if a call
comes in with a specific parameter, it would be directed one way, versus
another. Declaring everything as a single SOAP call essentially prevents us from
pushing functionality down the technology stack.
As for performance perspective HTTP/1.1 does support multiplexing of
requests, namely the ability to send one request while the first one is being
processes, so this should still result in the same number of roundtrips.
Obviously, there's the addition of the HTTP header in the payload, but this is
negligible. For example, by using a non-SOAP protocol we will save much more in
terms of overhead. (We don't get many benefits from the SOAP envelope anyway,
especially if our granularity is such that a single service supports multiple
portlets and even more so if we can't use exceptions). The reason why we use
SOAP is to be "good citizens", which also applies to using more granular calls
that can be managed using services in the lower part of the technology
stack.
Such an approach would allow the Producer to handle multiple requests
concurrently, with the only limitation being that the Producer would not have
full visibility into all the request so it would have to use an online algorithm
for distributing the requests. However, that last issue is, I believe, balanced
by another consideration that was brought up earlier. If you use a single
request with an array of arguments, if the Consumer uses one of the common
frameworks, it would have to wait for the full result before dumping it to the
output stream. If the Consumer can issue multiple calls, it can manage this in
more flexible ways.
As for the overhead in marshaling and de-marshaling requests, this is
indeed a consideration. However, I believe people can optimize this overhead
out, either with pooling or by creating services on top of thinner libraries. My
approach, in that respect, is that it would inappropriate for us to optimize -
at the application level - issues that result from the temporary immaturity of
specific SOAP frameworks, which especially in our case can be overcome since we
only have a single interface (Proxy code). (Unlike issues inherent to the
protocol, which we should optimize the hell out of).
Please also note that an approach that's based on multiplexing at the
network layer also lends itself well to optimization of heterogeneous calls,
such as performAction and getFragment or even setProperties and not just a
collection of related calls.
Despite my long e-mail (my apologies ;-), I view this as a possible
tactical optimization, only that I feel that the tradeoff here works better for
simplicity. Part of it may also be the balance between optimizing for Producers
which are sophisticated multi-service portals versus simpler home-grown
Producers.
Cheers,
Eilon
-----Original Message-----
From: Carsten Leue
[mailto:]
Sent: Wednesday, June 12, 2002 6:56
AM
To: Eilon Reshef
Cc: 'Thomas Klein6';
;
Subject: RE:
[wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces
document
Eilon-
thanx for providing more details on your approach. However I
still prefer
the explicit option for performance
optimization for the following reasons:
- what I understood from your comment is that you want to make
use of the
HTTP/1.1 feature to leave an established
connection open during multiple
request. This would
reduce the overhead of opening/closing a connection.
However it would not reduce the number of total roundtrips as you
would
still call the method (e.g. getFragments)
multiple times. Furthermore you
would still have the
overhad of instantiating all the intermediate objects
your SOAP implementation used to marshal/unmarshal the SOAP request.
By
passing arrays as parameters both disadvantages
disappear.
- from my point of view one of the major
advantages of using arrays is that
the producer can
exploit parallelity when satisfying the requests. In your
approach this would not be possible as all requests come in
sequentially.
- I don't agree that a consumer would be
more difficult to implement. If
its does not support
arrays, its just sends out one element. The producer
however would have to be able to deal with arrays. But this is trivial
as
in the simplest case it would just iterate over the
elements of the array
in a single loop.
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B鐽lingen , Germany
Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
|---------+----------------------------->
|
| "Eilon
Reshef" |
|
|
<eilon.reshef@webc|
|
|
ollage.com> |
|
|
|
|
| 06/11/2002
07:37 |
|
|
PM
|
|
| Please respond
to |
|
| "Eilon
Reshef" |
|
|
|
|---------+----------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
|
To: Carsten
Leue/Germany/IBM@IBMDE
|
|
cc: <>,
<>, Thomas
Klein6/Germany/IBM@IBMDE
|
| Subject:
RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces
document
|
|
|
|
|
>---------------------------------------------------------------------------------------------------------------------------------------------|
Carsten,
I apologize for the confusion.
What I meant to say is that SOAP relies on an underlying stack
of
protocols.
In our case, we can safely assume as much as optimization is
concerned that
the underlying protocol is HTTP (unless
anybody has in mind SMTP portlets).
In this case, one can use HTTP/1.1 as a transport mechanism
for the SOAP
requests. This does not require new
opening new connections for every
request.
However, as you noted, this is not part of the common
frameworks for SOAP.
However, let's not forget that we
must support the standard stack
(SOAP/HTTP) but
leveraging the existing frameworks is extremely important,
but if there is a certain optimization that people can do outside
those
frameworks this is not something that should
discouraged.
More specifically, on the client (Consumer) side, I don't see
this as a
concern since we only need to have one proxy
and we can manually construct
it if necessary for the
extra performance (it wouldn't be the first time
that
performance requires extra work, and I prefer that to a solution that
the interface inherently implies extra work).
On the server (Producer) side, I am more concerned: I am
completely unaware
of what the coupling between the
Web server and the underlying frameworks
is. If
someone has an idea whether HTTP/1.1 can be forced to be used there,
that would be beneficial.
I disagree with you that is "tweaking" the transport: this may
be tweaking
the existing SOAP frameworks, but hey:
they are just piece of auxiliary
code, and I would
rather look at is as moving beyond the infancy of the
those frameworks.
Eilon
-----Original Message-----
From: Carsten Leue [mailto:]
Sent: Tuesday, June 11, 2002 2:47
AM
To: Eilon
Reshef
Cc:
; ; Thomas
Klein6
Subject: RE: [wsia] [wsrp] [wsrp-wsia
joint interfaces] Merged
interfaces document
Eilon - i was not aware of this
SOAP functionality. Can you detail a
bit on
this topic? How would I setup a batch
call programatically? Is this
batch
processing part of the standard stacks
(SOAP4J, AXIS, .NET)?
Best regards
Carsten Leue
-------
Dr. Carsten Leue
Dept.8288, IBM Laboratory B鐽lingen ,
Germany
Tel.:
+49-7031-16-4603, Fax: +49-7031-16-4401
|---------+----------------------------->
|
| Eilon
Reshef |
|
|
<eilon.reshef@webc|
|
|
ollage.com> |
|
|
|
|
| 06/10/2002
08:33 |
|
|
PM
|
|
| Please respond
to |
|
| Eilon
Reshef |
|
|
|
|---------+----------------------------->
>
---------------------------------------------------------------------------------------------------------------------------------------------|
|
|
| To:
,
|
| cc:
|
| Subject: RE: [wsia] [wsrp]
[wsrp-wsia joint interfaces]
Merged interfaces document
|
|
|
|
|
>
---------------------------------------------------------------------------------------------------------------------------------------------|
Rich, isn't call batching
available today at part of the relevant
SOAP
stack via HTTP/1.1, unless you use a
code library that doesn't
support it?
-----Original Message-----
From: Rich Thompson [mailto:]
Sent: Monday, June 10, 2002 1:21 PM
To:
;
Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged
interfaces document
We
have to work through the array idea as it as big performance
implications and I don't see any indications that call batching
at
the
SOAP
stack level will be available in a relatively short timeframe.
My
understanding from the WSRP interfaces discussions is that a
template is
a
portal concept. It is effectively a configured portlet that
is used
from
a
toolbox to design pages. The concept of an instance is a
configured
portlet that is linked to the layout of a portal page. This
configuration
MAY
have come from cloning a template. From the perspective of
what
the
Producer needs to support, both of these are particular
configurations of
an
entity the service exposes with the Consumer choosing to use
them
in
different ways. I have been searching for reasons why there
would be
a
difference for the entity, but haven't found one yet.
If I
understand your question about transient entities
correctly, you
see
why
sessions should be separated from entities so that they can
be
shared
but
question whether services will ever expose entities that
aren't
persistent. I can certainly imagine entities with no
persistence (the
service that hosts them likely has some persistence of who may
use
them
along with some use log for audit & billing purposes). A simple
entity that
puts
a UI on a stock ticker feed may be a good example. It
chooses to
delegate all the billing issues to the service where it is
deployed
and
all
the
configuration persistence to its Consumers. In this case,
createPersistentEntities() would always fail as only transient
entities are
supported.
Andre Kramer
<andre.kramer@eu.
To: Rich
Thompson/Watson/IBM@IBMUS, ,
citrix.com>
cc:
06/10/2002 10:37
Subject: RE:
[wsia]
[wsrp] [wsrp-wsia joint interfaces] Merged
AM
interfaces
document
Supporting a batch operation mode through arrays does not seem
very
clean.
In
the "getFragment"
case
(getFragments?), the portal will most likely then have to
wait
until
the
whole array is
returned (i.e. all remote portlets have rendered) before it can
display the
resulting mark-up.
How
many consumer to producer parallel calls do we expect
typically?
I
would
rather leave
call
batching up to the (future) SOAP stack.
Always using "Entity" as the thing to create remotely seem to
loose
the
"class" versus "object"
semantics that the WSRP "template" and "instance" operation
names
used
to
imply. Do we now see no
no
difference between remote data storage - 'templates'
(possibly
with
inheritance) and
computational entities - 'instances', that WSRP seems to
naturally
call
for?
Or
are these the
persistent v.s. transient entities of the document (for me,
portlet
instances persist too)?
In
trying to follow the discussion, I'm confused as to why we
need
both
sessions and transient
entities, both being under the control of the consumer. I do
see a
need
for
common sessions
(same user/group or consumer portal) but do not see the need
for
other
transient entities,
expecting a consumer to have to pay for all entities, in some
way, in
the
real
world. I know
the
next call will discuss these but could someone give a brief
rational
before then?
Thanks,
Andre
Andre Kramer, Citrix Systems, Inc.
-----Original Message-----
From: Rich Thompson [mailto:]
Sent: 07 June 2002 20:38
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)
----------------------------------------------------------------
To
subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
