wsia-comment message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [wsia-comment] [wsia][wsrp][wsrp-wsia joint interfaces][DraftSpec]createEntity/createTemplate/createPortlet
- From: Rex Brooks <rexb@starbourne.com>
- To: wsia-comment@lists.oasis-open.org, wsrp-comment@lists.oasis-open.org
- Date: Thu, 23 May 2002 05:40:53 -0700
<snip ever expanding prolieration of
terms and arguments>
After last Friday's telecon I came up with this idea and held back hoping
for something resembling it to come out of the then-impending
discussions. After all the expansions of the fairly simple concepts in
the Joint Spec v.03, I still think it is the easiest, simplest, least
cumbersome way to proceed.
The main problem with that first straw man was the disconnect between
wsrp and wsia over what an Instance is and what a Session is and how do
we get the full set of properties (portType) with one call instead of
several. After the telecon last Friday, it still seemed, despite the
proliferation of terminology that the simple way to give wsrp all the
room it needs for deciding how it wants to deal with portlet-specific
Registration/Instance/Session we can still keep the original proposal and
just include a slightly more verbose naming convention, thus:
For WSRP Portlet-Specific Use:
instancePortletHandle = createPortletInstance(propertyValues,
templateKey);
For WSIA General Purpose (Embedded) Use:
instanceHandle = createInstance(propertyValues, templateKey);
That way we always get propertyValues and templateKey and how we deal
with a SessionID can be portlet-specific or not, and can include portlets
within a WSIA general web service collection as well, as long as the
SessionID starts with an identification of an end user and a date/time
stamp.
This way an Instance always identifies the Producer-Consumer relationship
only and how it diverges from there can get as complicated as we want to
make it. I suggest that it is up to the Consumer to decide how it wants
to handle coping with multiple producers as long as each relationship
pair has a unique instanceHandle.
Or not.
Right now we have something that looks awfully complicated at the getgo
and I know I'm going to run into difficulties explaining it to
clients.
Ciao,
Rex
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC