Title: Message
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>
