OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [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?

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC