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

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


<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