[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfacesdocument
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, wsia@lists.oasis-open.org, citrix.com> wsrp@lists.oasis-open.org 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:richt2@us.ibm.com] Sent: 07 June 2002 20:38 To: wsia@lists.oasis-open.org; wsrp@lists.oasis-open.org 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)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC