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