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/13/2002 12:33 |
| | AM |
| | Please respond to |
| | "Eilon Reshef" |
| | |
|---------+----------------------------->
>---------------------------------------------------------------------------------------------------------------------------------------------|
| |
| To: Carsten Leue/Germany/IBM@IBMDE |
| cc: Thomas Klein6/Germany/IBM@IBMDE, <wsia@lists.oasis-open.org>, <wsrp@lists.oasis-open.org> |
| Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces document |
| |
| |
>---------------------------------------------------------------------------------------------------------------------------------------------|
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.
[CL] I disagree. Keep in mind that HTTP is only one possible transport
layer. You would have to reproduce the whole procedure for each transport.
In the explicit case this would not be necessary. [CL]
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).
[CL] This is certainly true. We will have to decide between simplicity and
efficiency. Both is important. [CL]
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.
[CL] I agree to this as well. The producer would have to return a null
output to indicate an error. [CL]
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.
[CL] Can you elaborate a bit on the use of SOAP gateways? I was not aware
of this.
Furthermore: will it really be efficient to route requests for markups that
potentially share the same session to different servers via such a gateway?
Wouln't it be very inefficient to marshal the session state accross these
servers?
[CL]
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.
[CL] See my comment above on the transport issue. We might deal with
multiple transport layer that do not support such multiplexing. In
addition, client and server will have to negotiate how to exactly perform
the multiplexing. Is this standardized? Is it included in today's SOAP
stacks. If you don't mind I would love to get some education on this on the
F2F.
In addition it seems as if your scenario implies async method calls (send
one request while the first on is being processed). Do I get this right? I
had the impression that SOAP calls were synchroneous. [CL]
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.
[CL] The consumer could still choose to send single requests. Using arrays
is just an option, so this approach would not prevent your scenario from
happening but would leverage different kinds of optimization. [CL]
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).
[CL] I clearly see your point. My answer is that I prefer a design
optimization rather than an optimization of the implementation. At leat
design optimizations remain effective accross different implementations.
[CL]
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.
[CL] that's true, but especially on getFragments and performAction I do not
see how such an optimization might make sense. The consumer would have to
wait anyway until a performAction request has been satisfied before
launching the next getFragments request (because performAction might
invalidate state). [CL]
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.
[CL] My feeling is that the array approach is especially helpful for
home-growners, iterating an array is not that complicated [CL]
Cheers,
Eilon
-----Original Message-----
From: Carsten Leue [mailto:cleue@de.ibm.com]
Sent: Wednesday, June 12, 2002 6:56 AM
To: Eilon Reshef
Cc: 'Thomas Klein6'; wsia@lists.oasis-open.org;
wsrp@lists.oasis-open.org
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�blingen , 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: <wsia@lists.oasis-open.org>,
<wsrp@lists.oasis-open.org>, 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:CLEUE@de.ibm.com]
Sent: Tuesday, June 11, 2002 2:47 AM
To: Eilon Reshef
Cc: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org;
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�blingen , 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: wsia@lists.oasis-open.org,
wsrp@lists.oasis-open.org
|
| 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:richt2@us.ibm.com]
Sent: Monday, June 10, 2002 1:21 PM
To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org
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, wsia@lists.oasis-open.org,
citrix.com>
wsrp@lists.oasis-open.org
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:richt2@us.ibm.com]
Sent: 07 June 2002 20:38
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)
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the
subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC