← Prev in month ← Prev in thread

[wsrp] Divide-and-Conquer Interfaces-and-Protocols

From
Eilon Reshef <>
Date
2002-04-05T05:17:07+00:00
ID
000001c1dc61$14b26aa0$0c00a8c0@eilon
Thread
[wsrp] Divide-and-Conquer Interfaces-and-Protocols
Title: Message

One random thought on a way 
to divide-and-conquer the work around interfaces and protocols around the 
timing of the protocol/interface invocation, i.e., 
one of two:

Some things happen in 
run-time, assuming the portal page is already well defined and 
configured (in our terminology, there's a portlet template that's already 
completely configured), and an end user comes to the page. Under this category 
fall all the issues with regards to the portlet instance: 
rendering of the portlet page, action/events/getContent, URL rewriting, user 
identification, and so on. 

Some things happen in 
design-time, assuming that a portal designer or an 
administrator is working to configure the portlet and/or the portal page. These 
issues deals mainly with the portlet template: find/bind, 
interface discovery, copy/clone, portal identity, and the workflow around 
administrating the template data. 

This is not to say that from a workflow 
perspective, there couldn't be interleaving steps of run-time and design-time. 
For example, an administrator could set up a portlet and use its "admin" mode 
(which itself employs a portlet instance) to configure some template settings 
(although at this stage the template is not "end-user-ready" yet), then a portal 
designer sets more template settings, and so on, until eventually the template 
is exposed to the end user. 

A couple of reasons why this 
categorization may be relevant is because the design-time considerations seem to 
be pretty specific to portals whereas the run-time considerations seem to 
overlap more with WSIA and may require more collaboration with 
WSIA.

In addition, it seems that design-time 
considerations may lend themselves more to extensibility (vendor-specific 
workflows), whereas the run-time aspects seem to demand tight 
interoperability.

And finally, there may be some different 
technical requirements, for example - performance seems to be a key 
consideration for run-time but not necessarily for design-time. 

Thoughts, comments, 
ideas?
← Prev in month ← Prev in thread