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
-----Original Message-----
From: Carsten Leue
[mailto:]
Sent: Tuesday, June 11, 2002 2:47
AM
To: Eilon Reshef
Cc: ;
; 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鐽lingen , 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: ,
|
|
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:]
Sent: Monday, June 10, 2002 1:21
PM
To:
;
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,
,
citrix.com>
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:]
Sent: 07 June 2002 20:38
To: ;
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>
