Re: [wsrp-interfaces] Groups - Portlet Transport.htm uploaded

[Michael Freedman <Michael.Freedman@oracle.com>]

Other/more specific use cases:

Consumer Use case 1:
Application is a corporate portal.  The tool for constructing the portal 
is the same tool end-users use to interact/use the portal.  For example 
the Portal is an html based application providing both design time 
function for page designers to build portal pages and the runtime 
environment for users to interact with these pages.  The specific 
corporate portal is designed in a controlled, isolated environment. 
 Once developed sufficiently, the development team stages the portal to 
a test environment. Functional and usability tests are run from this 
stage server.  Once the portal has been tested  it is published to the 
"production" server making it available to all users.  Note: this is an 
interative, not a static, process.  Though a snapshot has been staged 
and or pushed to the production server, development/refinement 
continues. Once a significant consistent point is reached the publishing 
cycle occurs again.

In this environment, the developers are constructing portal pages with 
portlets implemented using WSRP.  The portlets are added to the page and 
then configured with default customizations intended to express the base 
customization for all users of this page.  As the developers publish the 
snapshot of the portal to the stage and ultimately the production 
environment, its expected that these base customizations are likewise 
"published" or otherwise transferred into these environments so that in 
the end the stage and/or production environment isn't merely a 
reflection of the structuer of the designed pages but also contains the 
level of customizations intended by the developer.  I.e. you don't have 
to manually recustomize the stage/production environments to reflect the 
customizations made in the development system.  Note: in this scenario 
its only the "base" customizations that are transferred.  End-User level 
customizations are expected to remain with the portal on which they were 
set.

For example, in the above portal the "home" page has a wsrp based stock 
[portfolio] portlet in it.  In the development portal the developer 
configures this portlet with a preset portfolio of well known technology 
stocks [this "configure" of "default" semantics is a consumer/portal 
defined semantic that translates into a WSRP Edit mode on the initial 
cloned entity that was generated when the portlet was added to the 
page].   When this development portal is published to the stage portal 
the developer expects the stocks "default" customization to be 
"published" as well.  I.e. an end user who has not customized the 
portlet for themselves in the published environment would see output 
from the stock portlet based on these original customizations. There is 
a similar expectation when the portal is published from stage to 
production.  In the case, however, where the published site has existing 
end-user customizations; for example if some end-users on the production 
site have customized the base stock portlet with their own portfolio, it 
is expected that these end-user customizations remain in place and are 
unaffected by subsequent updates to the base configuration.  I.e. when 
the developer decides at some time in the future to add a new technology 
stock to the default portfolio and republishes this portal from stage to 
production, customized end-user customizations [portfolios] aren't 
affected; only those users that still rely on the base are.

Question: What does the developer/admin expect if the portal allows the 
base customization to be changed in each configuration?  Do they expect 
that republishing overwrites these changes?  Aren't republished?  Or 
that the situation is determinable [and hence they might be asked what 
they want to do]?


ConsumerUse case 2:

Consumer is a "shrink wrap" expense reporting application.  This 
application is capable of including/utilizing portlets.  For example it 
includes a currency converter portlet on the page that allows you to 
enter your receipts.  The developer builds the application in Java using 
a Java IDE.  The developer unit tests the application by running the 
application in place within the IDE.  Integration testing is done by 
building the application in the IDE, packaging it into a .ear file and 
deploying to an integration server.  Once the application is 
sufficiently tested the .ear file is posted on the corporate e-store 
where customers can purchase it, download it, install, and run it on 
their own server/environment.  The developer expects that most of its 
customers are U.S. currency based and hence customizes the converter to 
default to Euros to Dollars conversion.  The developer expects that this 
customization will be carried along with the application as it is 
deployed/installed in the various environments discussed above. 
 Furthermore the developer expects that redeployments/upgraded 
installations will be able to pick up changes to these base 
customizations without affecting existing end-user customizations much 
like in the scenario above.  


Producer use cases:
In supporting the above use cases a producer may have the following 
capabilities/behavior:

Use case 1:  It doesn't support the consumer use case.  I.e. because 
WSRP 1.0 doesn't support these use cases consumers already have to deal 
with cases where the producer can't participate to deliver the intended 
semantics [though they probably want to be able to detect this in 
getServiceDescription()].  That being said its an open question whether 
a WSRP 2.0 portlet must implement this capability.  The benefit of it 
being mandatory is compliance and hence as portlets upgrade to newer 
WSRP versions over time the greater likely hood of meeting/supporting 
the consumers use case.

Use case 2: The producer can support the consumers use cases even if 
they are required to expose the customization data in a human readable 
format.

Use case 3: The producer can support the consumers use cases but only if 
they aren't required to expose the customization data in a human 
readable format.

Use case 4: The producer can support the consumers use case but only if 
they can encrypt/secure any information they are required to transfer 
outside their control.

.
Use case 5: The producer can support the consumers use case if the 
mechanism doesn't require any actual customization data be transferred 
from the control of the producer.  

      -Mike-



Alan.Kropp@vignette.com wrote:

>The document Portlet Transport.htm has been submitted by Alan Kropp (Alan.Kropp@vignette.com) to the WSRP Interfaces SC document repository.
>
>Document Description:
>Initial problem description, Transportability of Portlets
>
>Download Document:  
>http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/download.php/5279/Portlet%20Transport.htm
>
>View Document Details:
>http://www.oasis-open.org/apps/org/workgroup/wsrp-interfaces/document.php?document_id=5279
>
>
>PLEASE NOTE:  If the above links do not work for you, your email application
>may be breaking the link into two pieces.  You may be able to copy and paste
>the entire link address into the address field of your web browser.
>
>
>  
>