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
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