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