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