WSRP v 3 Use Cases Use case list

WSRP v 3 Use Cases

Use case list 1. Theme: Portlets as UI services 2. Functional needs a. b. c. d. e. Content extension points Consumer resources (e. g. referencable buttons, browser framework, etc) Popup windows Generating URLs to other portlets Extendable render URLs 3. Infrastructure needs/alignment Leverage WSRF – Portlets as resources Improved property support – make properties more useful Expose composed applications rather than just portlets [multiple pagelets with navigation] – Richard d. Expose aggregates as a Portlet – v 1 supports non-portal like aggregates e. Leverage WSN – Async notifications (e. g. Metadata. Changed, Cache. Update) a. b. c. 4. Reuse Cache. Control relative to Templates, User. Contexts, etc. ? a. Unify concepts or have distinct Consumer-cached and Producer-cached models?

Portlets as a UI service § Most modern applications use component technologies for view generation Ø Web domain => linked set of JSPs, ASPs, perl scripts, etc – Each invocation produces a “page”, though reuse of control/fragment generation is encouraged. § Portal concept added a “portlet” granularity; below “page” level, but above “control” level. § WSRP added the ability to produce/consume distributed portlet components.

WSRP -> distributed Portlets § v 1: handle generation and interactions with markup in a manner agnostic to: Ø Ø Ø Platform Transport (though http is explicitly considered) Mime type (though html is explicitly considered) Stateful/stateless choices etc § Note: v 1 included other features as well

WSRP -> distributed Portlets § v 2: Maintain agnostic characteristics of v 1 while adding coordination: Portlet source of coordination signal/info (events) Ø Consumer managed extension of the Portlet’s nav. State (public parameters) Ø § Note: v 2 included other features as well

v 3 Question § What is needed to fill out the distributed UI model? Ø Ø Ø Exposure of Consumer functionality to portlets Fuller integration into “page” Programmatic access to configuring / customizing portlets Larger set of UI techniques available to portlet developers Connections to asynchronous models …

Portlets as a UI service Functional needs 1. Content extension points 2. Consumer resources • Referencable buttons, browser framework, etc • Available services (e. g. content management system) 3. Popup windows 4. Generating URLs to other portlets 5. Appending query args to render URLs • Extension of method=get issues/solution?

Content extension points § Many apps (e. g. Media Player, Fire. Fox) provide facilities for extensions that can: Add content in multiple places – Toolbars – Menu items – “Body” Ø Add functionality by leveraging – Notifications – Plug points in the processing model Ø § WSRP v 1 & v 2 only provide for adding content to the “body”

Content extension points – example Context-sensitive menus in OLE Select spreadsheet object

Content extension points – Portlet defined as well? § Consider a portlet offering maps. google type markup Ø Useful to define extension points for other components to overlay onto the map. Ø Example: http: //www. mackers. com/projects/dartmaps/

Content extension points – example Portlet defined as well?

Consumer resources § Previously raised use cases: Ø Ø Form control layout Reusable buttons, etc Access to Consumer managed controls (menus, tabs, etc) Help system § General issues: Ø Providing remote portlet with access to local resources & services. Examples include: – After portlet markup incorporates a document list, etc, allow Portlet controlled URLs to fetch, edit and post new/updated documents to a Consumer managed document repository. – Portlets share a common (Consumer-managed) document repository, but a portlet wishes to validate a document prior to storing it within the repository.

Pop-ups § User Interfaces often want to pop-up additional information Help/print views on themselves Ø View a document from a list Ø Views on other portlets which provide a means to impact the source portlet – Example: Mail portlet pops-up an Address. Book portlet Ø

Help/Print pop-up

Pop-up document from List

Pop-up another portlet

Pop-up Portlet impacting source

URLs to other portlets § The mail/address book scenario needs a portlet url to direct interaction with a different portlet Ø Need to be careful the solution doesn’t expand the scope of WSRP to include communication within the browser! § Dividing a standard email application into three portlets (folders, summary and detail) also needs one portlet to direct interactions with another portlet. § For example; customers have requested the ability to replace the content from an email portlet on a page with the content from a calendaring portlet based either on URL parameters or the response from action processing. § Note: recent redirect. URL discussion have also raised the use case of a portlet redirecting to a different Consumer “page”.

Extendable Render URLs § Consider a document manager portlet: Ø § Top level generates a list of documents as URLs for accessing the document: 1. Each URL can directly reference (i. e. using a render url) an individual document (doable today) • Performance suffers as large numbers of URLs are generated. 2. Each URL can reference a script function passing the document. ID. • Single URL embedded within the script. Script appends “document. ID=“+document. ID • Doable if an action url is used, but this doubles the network latency impact! Very similar to the issues discussed surrounding forms with method=get Ø [Can this be solved via Navigational. Parameters or Transient Properties (with scope=wsrp: consumer. Request)? ]

Portlets as a UI service Infrastructure needs/alignment 1. Leverage WSRF – Portlets as resources 2. Improved Property support – make properties more useful 3. Composite applications – rather than just portlets 4. Expose aggregates as a portlet – some use cases supported now 5. Leverage WSN – Async notifications (Metadata. Changed), etc

Leverage WSRF § As WSRF emerges as the standard for managing interactions with web service based resources, it is time to revisit casting portlets as such resources. § WSRF expected timeframe is late 2005 with marketplace support expected in 2006.

Improved Property Support § v 1 included customization properties Ø Insufficiently developed to make fully functional (This is a comment relative to portals trying to auto-generate a UI from a Property. Description. Is this the relevant use case? Should there be a means to fetch a fragment for inputting property values (If so, are the values transparent to the Consumer? )? ) (What is missing from JSR 168 properties? From other property systems? ) § v 2 may add nav. State and scoped transient properties § If not added in v 2, these should be modeled in v 3 Ø Would provide a cleaner solution than simply leveraging extensions (i. e. ba. com solution using WSRP)!

Composite Applications § Coherent (vertical) applications are managed as a single entity Develop and distribute a complex composite application, which comprises individual Portlets § Deploy the entire application on the target system as a single entity in one step §

Composite Applications § Can consist of Ø Ø Ø Portlets, even from different “domains” Layout description Pages? Even hierarchies? Event wiring? Common Application Context – may fit well with transient properties and be just a scope? § Consumers can integrate such applications as a whole Ø Expand from portlet as single disconnected applications to easy to consume composite applications

Expose Aggregates as a Portlet § Consider the std email app:

Expose Aggregates as a Portlet § Consider the std email app: Set of related functions, composed for usability – Composition often includes things like coordination Ø Portlets often developed together: – Could argue this is a portlet with a set of JSP-like components for generating each type of view, but it could just as easily be three portlets. – Often uses some internal communications to coordinate Ø Such a composition could be exposed as a WSRP v 1 portlet as there is a single set of customization parameters, etc Ø

Expose Aggregates as a Portlet § Other cases: Ø Ø Purchasing dept composes POBuilder: 1. Order summary (note: reused in other compositions) • What items are currently on a PO (purchase order) 2. Composite catalog • Searchable list of approved items (multiple vendors) 3. Catalog item view • Item view/description provided by the vendor for a selected item (Note: this could be surfacing of one of a set of portlets running on the vendors’ systems) Employees allowed add POBuilder to any intranet page (leveraging WSRP). – Each portlet has different customizations/help screens => Aggregate needs to be able to place nested-title-bars in similar style to the containing page.

Leverage WSN § WSN leverages WSRF to add an asynchronous notification model. This could be useful to WSRP for: Metadata. Changed notifications Ø Cache update/invalidation Ø … Ø § Standard expected in late 2005 to early 2006.

Use case->Feature list 1. Theme: Portlets as UI services 2. Functional needs a. b. c. d. e. Content extension points Consumer resources (e. g. referencable buttons, browser framework, etc) Popup windows Generating URLs to other portlets Extendable render URLs 3. Infrastructure needs/alignment a. b. c. d. e. Leverage WSRF – Portlets as resources Improved property support – make properties more useful Composite applications – expand to consumable composites Expose aggregates as a Portlet – v 1 supports non-portal like aggregates Leverage WSN – Async notifications (e. g. Metadata. Changed, Cache. Update)

Embedding content § Leverage Consumer resources for defining where portlets can insert markup Ø Define a well-known resource for this definition? § Leverage Events for Consumer notifications? Add well-known Consumer generated events? Ø Add event metadata to registration? Ø

Consumer Resource Features § Multiple Consumer Resource needs Reuse of Consumer provided markup (e. g. form controls, script methods? ) Ø Programmatic access to Consumer services Ø URL access to Consumer services (e. g. store a document in a repository) Ø

Consumer provided resources/markup § Metadata needs Ø Ø Ø Valid for what markup types? Descriptive text Parameters -> leverage Property. Description? § Runtime needs Item’s name Maintain single parse characteristic Parameter – Prefix with wsrp_rewrite# – Close with /wsrp_rewrite, same as for URLs name Parameter Ø Specifying parameters value to – Leverage XML, name=resource/parameter name, value=value apply Ø § Example: wsrp_rewrite#<form. Control><OKonclick>js event handler</OKonclick><Cancel. URL>render. URL</Cancel. URL> </form. Control>/wsrp_rewrite

Access to Consumer services § Leverage WSDL to describe the available services § Also need a localized description? § Will portlets need to indicate they have a dependency on the Consumer providing certain services?

URL access to Consumer services § Use template processing concepts for parameterization § Need localized description of service § Example: Ø <Consumer. URL> <Localized. String xml: lang=“en” resource. Name=“store. Doc” value=“URL for storing a document. Use ‘parm 1’ to specify the document’s name and ‘parm 2’ to specify the desired folder. Note that if a folder by that name does not exist, one will be created. ”/> <Resource. List /> <Template> http: //www. consumer. url? action=store&name={parm 1}&folder={parm 2} </Template> </Consumer. URL>

Popups § Using a window. State introduces protocol scope issues if the “parent” and “popup” portlets want to do browser based communication (common requirement). § Defining a CC/PP profile for a Consumer supplied script method that opens a window in a manner which allows communication to flow back through the Consumer, inheriting contextual information, could provide a solution. A TC defined profile would provide a reliable way for portlets to determine if such functionality is available Ø Other interesting profiles as well? Ø § If a popup is a view onto the same portlet, the two views share session state, etc (not nav. State)

URLs to other portlets § New url parameter; portlet. Handle: References the portlet whose view should be shown Can’t be CCP for this end-user => POP handle – Consumer to map to the correct CCP handle Ø If URL parameter is missing => use Portlet that generated the URL Ø The referenced portlet replaces the portlet on the page. [If not popping up a new window] Ø § Are there also use cases for referencing portlets from other Producers? Ø How would the Portlet discover (and/or reference) such portlets from a Consumer perspective? § What about referencing other Consumer pages?

Extendable Render URLs § URLs often have several components: Consumer oriented: – Base url to route processing to the right component – State related to the End-User’s use of the “page” Ø Portlet oriented: – Identify the target portlet – Parameters for the portlet’s processing of the url activation Ø § Allow logic running in the user agent to extend the render url with additional parameters: Ø Ø Leverage setting of navigational parameters on URLs? Allow means for arbitrary extensions that only get supplied to the target portlet? (equivalent of form parameters on pbia)

Leverage WSRF § Expose portlets directly as WS-Resources rather than indirectly through Producer Recast many items as WSRF properties – Customization properties – Metadata – Navigational parameters? – Transient Properties Ø Use WSRF lifetime definitions for portlet leasing – Could also be used with other resources if they are also cast as WS-Resources Ø

Improve Property support § What is needed? Assist portals in generating UIs for entering property values? Ø Additional lifetimes? (i. e. are all the interesting ones covered by navigational parameters and transient properties) Ø

Leverage WSN § Provides well-defined means for subscribing to and receiving notifications: Metadata changes Ø Cache update (just invalidation? ) Ø