[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wsrp][interfaces and protocols]: Portal using WSRP Service
Gil, Michael, please see comments below enclosed by <ts>...</ts> Best regards, Thomas Thomas Schaeck Architect, WebSphere Portal Server IBM Pervasive Computing Division Phone: +49-(0)7031-16-3479 Mobile: +49-(0)171-6928407 e-mail: schaeck@de.ibm.com Fax: +49-(0)7031-16-4888 Address: IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 220, 71032 Boeblingen, Germany Gil Tayar <Gil.Tayar@webcollage.com> on 04/09/2002 06:37:18 AM Please respond to Gil Tayar <Gil.Tayar@webcollage.com> To: "'wsrp@lists.oasis-open.org'" <wsrp@lists.oasis-open.org> cc: "'Michael Freedman'" <Michael.Freedman@oracle.com> Subject: RE: [wsrp][interfaces and protocols]: Portal using WSRP Service 1>How does your two terms "Serialized/Stored Instance" and "Active Instance" differ from the one's in my document; "Personalization Data" and "Portlet Instance"? They seem very similar to me. "Portlet Instance" in your document means - "a portlet on a page; or more generically a portlet in the portal layout structure". If this means a portlet instance is created only when viewed by the end user (i.e. runtime and not design time), then my apologies for failing to understand. I believe my failure to understand came from the list of operations you designated on portlet instances. For example "You can copy a portlet instance. By copy it is meant that a second portlet instance comes into being with its personalization data being a duplicate of the instance it was copied from". Why does WSRP need such an operation? Instead (In your terminology), the portal can just create a new instance with the personalization data used to create the old instance. Now, I understand why a portal would need to expose such functionality to the end user (copy/paste of a portal on the page), but why would WSRP? <ts>I think that a copy function is probably not required for WSRP in the first step. Nevertheless, there can be scenarios where such a function is interesting. Iamgine for example you have a portal system with a staging and a production server: You put together pages on the staging server some of which contain portlet instances that actually are pointing to WSRP instances somewhere in the Internet. The WSRP service be implemented so that it has persistent instance state which can be manipulated via the WSRP service's EDIT mode. Now assume you want to move these pages to the production server - you need identical customizations of the WSRP service, but you don't want to use the same instances, because otherwise changes done one the staging server later would affect the WSRP instance and therefore also the production server. Instead, in this case you would like to be able to have the WSRP service create a copy of the original WSRP instance to be referenced from the page copy on the production server. This said, this is pretty advanced stuff and should probably be tackled once we have the basic stuff in place</ts> 2>Also, why do you think its important/required that portal store/manage the portlets (producers) settings and personalization data? Isn't there value in allowing these portlets to store/maintain this data themselves? Good question (and very much related to the first!). This may be true, but remember that a remote portlet may work with multiple portals (each with a different user base) at the same time. If we require the portlet to store customization preferences, then this puts too much burden on portlet. In the "local" portlet world, the portlet had access to infrastructural code (of the portal) that can store the preferences for the portlet. This structural code was usually code supplied by the portal. In the remote portlet world, the portlet is "alone", and must supply "preference" storage themselves, i.e. a database. Moreover, this information must be synchronized with the data stored in the portal itself about the portal instance (for example, the location of the portal instance on the page). So the two must be synchronized. But this is difficult - what happens when the user deletes the portal instance from the page - should the portal send a "deleteData" message to the portlet? What if the portlet is "down" at that time? Now the portal needs to queue the request. Another (more conceptual/logical) problem is that (and I quote from your document) "There are an arbitrary set of personalization levels defined by the particular portal. The levels are hierarchical. The deepest personalization level that has any overriding values controls the user's view" - do we expect the portlet to understand this hierarchy and the rules governing the overriding and inheritance? If portlet's store the personalization data, then they must. And if they must, then WSRP must define the hierarchy and the rules. Do we expect WSRP to standardize these? Seems to me that this is the domain of the portals, and not of the interface. <ts>I think that who stores the instance data for a portlet service instance should be negotiated between the producer and the consumer. A simple way to do this would be that services requiring/preferring to have the portal store instance data indicate this in the metadata, consumers who are binding to portlets check whether they are willing to store data on behalf of the service and based on that use the service or not. This means some services just would return a handle to be stored by the consumer and others would return actual data to be stored by the consumer. In any case, a service might decid to store server side instance data keyed under the instance handle, this is orthogonal to whether or not the service has the consumer store data. Use Cases: - A news WSRP service allows users to select the news topics they are interested in. They have thousands of portals as customers and don't want to persist all portlet instance customizations of 10.000.000 users on their site -> They require the consumers to store the instance data ( selected newsfeeds) and return this data to be stored on the consumer and be sent with subsequent requests. - A frequent flyer WSRP service allows users to enter their frequent flyer IDs and PINs (via a popup window going to the service via SSL). They consider this information sensitive and don't want to have it stored at portal servers -> They implement the WSRP service to store instance data itself and just return the instance handle without additional data to be stored on the consumer and sent with subsequent requests. </ts> I think these two questions all boil down to the second one: who manages the personalization/customization data - the portal or the portlet? Gil -----Original Message----- From: Michael Freedman [mailto:Michael.Freedman@oracle.com] Sent: Tuesday, April 09, 2002 00:23 To: Gil Tayar Cc: 'wsrp@lists.oasis-open.org' Subject: Re: [wsrp][interfaces and protocols]: Portal using WSRP Service Gil, How does your two terms "Serialized/Stored Instance" and "Active Instance" differ from the one's in my document; "Personalization Data" and "Portlet Instance"? They seem very similar to me. Also, why do you think its important/required that portal store/manage the portlets (producers) settings and personalization data? Isn't there value in allowing these portlets to store/maintain this data themselves? -Mike- Gil Tayar wrote: Hi Thomas, <note> As I was not in the F2F, and have not yet posted to this mailing list, I would like to introduce myself. My name is Gil Tayar, I am the Chief Architect of WebCollage, and a colleague of Eilon Reshef. </note> I very much liked your life-cycle description, and I think it can provide a descent framework on which to base WSRP's life-cycle and interface/protocol discussions. It also complements Mike's more detailed document very well. To summarize the states of a portlet, you have the following: 1. Unbound: The portlet exists, but there is _no_ connection to the portal. 2. Bound: the portlet is bound, and registered in the portal. 3. Template: a portlet template is created by the portal, with a given set of parameters. 4. Instance: A template inside a given user page. As a member of WSIA, where states #1-#3 do not "exist" (yet!), I would like to dig deeper into the "Instance state". It seems to me that this state should be subdivided into two: 4a. Serialized/Stored Instance: the template and the customizations the user selected and put in the page, as it exists in the "persistence store/database" of the portal. 4b. Active Instance: the entity used to render the portlet and "do the actions". I believe the distinction between the two is an important one, as important as the distinction between a java object serialized to a stream, and the java object itself. One (the serialized object or portlet) is "just" data used to create the other. To make another point, the state names I gave are a bit confused. Some are "states" and some are "entity types". We can deconstruct this further: Entity Types - 1. Portlet. The remote service that responds to WSRP messages. 2. Bound Portlet. The location and registration information for the Portlet, as stored by the portal. 3. Portlet Template. The set of parameters to be used when creating a Stored Instance, as stored by the portal. 4. Stored Portlet Instance. The set of customization options to be used for a certain user page, as stored by the portal. 5. Active Instance. The viewed portlet, when viewed inside the portal. The above lists turns the "states" into more of a list of "operations" which create entities from other entities - Operations 1. Binding: a request of the administrator(?) to the portal to register the portlet and store location and registration information, to be used when creating a portlet template. 2. Creating a Template: Using the location and registration information, get the meta-data, query the administrator(?) for the parameters, and store them. 3. Inserting Template into Page: User selects a template, customizes it, and creates a Stored Portlet Instance from it. 4. Viewing the Portlet: User opens portal, and the portal creates an Active Instance from the Stored Instance.Hope it makes sense,Gil-----Original Message----- From: Thomas Schaeck [mailto:SCHAECK@de.ibm.com] Sent: Sunday, April 07, 2002 18:19 To: Michael Freedman; wsrp@lists.oasis-open.org Subject: Re: [wsrp][interfaces and protocols]: Portal using WSRP Service Hi Mike, here's the life-cycle writeup I promised: Binding to a WSRP Service ------------------------- Pre: - The Portal and the WSRP Portlet Service are not bound - 1. The administrator browses the directory for WSRP services using the portal admin UI --> - The Portal finds the WSRP Portlet Service in the directory 2. The administrator selects a WSRP service --> - The Portal makes a call or series of calls to the WSRP Portlet Service to establish a relation (bind) (may include establishing a trust relation, see my security note) - The Portal creates a portlet template referencing the WSRP portlet service. (Potentially, the template may need to be parameterized with template settings to become usable.) Post: - The portal is bound to the WSRP service through the portlet template, users may now see the template beeing offered in the portal's customizer - Creation of Instances --------------------- Pre: - The portal is bound to the WSRP service through the portlet template, users may now see the template beeing offered in the portal's customizer/toolbox 3. A portal user selects the portlet template to be put on a page --> - The portal server creates a portlet instance from the portlet template - The portal server links the instance to the user's page Post: - The portal is bound to the WSRP service through the portlet template, users may now see the template beeing offered in the portal's customizer/toolbox and a unique instance which may have persistent data now exists for the user Destruction of Instances ------------------------ Pre: - The portal is bound to the WSRP service through the portlet template, users may now see the template beeing offered in the portal's customizer/toolbox and a unique instance which may have persistent data now exists for the user 4. A portal user discards a portlet instance from a page --> - The portal discards the link from the page to the instance - The portal discards the instance Pre: - The portal is bound to the WSRP service through the portlet template, users may now see the template beeing offered in the portal's customizer/toolbox, the unique instance does no longer exist Unbinding a WSRP service ------------------------ Pre: - The portal is bound to a WSRP service through a portlet template, users may now see the template beeing offered in the portal's customizer - 5. The adminstrator browses the list of portlet tempplates and discards the portlet template --> - The portal makes a call to the WSRP Portlet Service referenced in the portlet template to undo the binding - The portal discards the portlet template Post: - The Portal and the WSRP Portlet Service are not bound - Best regards, Thomas ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC