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][interfaces and protocols]: 4/4/02 meeting notes

Summary and some excellent notes passed along by Susan Levine are
The following is a summary of the Interfaces and Protocols conference call held on April 4th.  This summary is followed by Susan Levine's excellent meeting notes.

Original Agenda:

a) Find someone to take minutes/notes. [5 min]
b) Discuss scope/focus of group [10 min]
-- I propose this group focus on defining and specifying: 
a) the things a portal needs to ask a portlet to do.
b) the things a portlet needs to ask a portal to do (if anything).
-- I suggest that the details of such items such as URL rewriting and namespace encoding be handled by the Markup subgroup, with consideration/influence brought by us where necessary.

c) Brainstorm (and capture) all the things we think a portal needs to ask a portlet to do. [40 min]

-- first, define terms for the logical representative entities the portal operates on
-- second, brainstorm on what operations are performed on these entities.

d) Meeting summary/next steps. [5 min]

-- depending how the brainstorm goes my best guess is we will have general terminology/model issues to focus on and/or we can move on to the step I originally proposed for this week; namely begin to identify the questions we need to answer for each of the discrete operations portals request of portlets.

Call Summary:

a) No one volunteered to take minutes/notes. Therefore, I indicated I would provide meeting summaries.

b) Folks agreed that this subcommittees focus is on identifying the things a portal needs to ask a portlet to do.  The approach we will take is to:

c) Discussing terms & brainstorming:  We spent most of the session discussing terms with a little time at the end on brainstorming. We defined the following:
portlet service: the web service component that implements WSRP.  From the portal's perspective this is the registration entity.  I.e. the entity it binds to in order to expose a specific portlet capability.

portlet template: the design entity representing a (potentially customized) portlet service used to create portlet instances.  From the portal's perspective, once its bound to a portlet service, it will expose a representation of this service, often in a portlet toolbox, which allows users to create specific instances (on a page).

portlet instance: a portlet on a page; or more generically a portlet in the portal layout structure.  From a portal's perspective, the portlet instance is the realization of the portlet in the runtime layout structure.  A portlet instance is derived from a portlet template.  e.g. when adding a portlet to a page, the user chooses a portlet template (from the toolbox).  The template is used to "type" the instance being created.

personalization data: a set of customized data settings for a portlet instance. There is an 1 to N relationship between personalization data and portlet instances.  1 set of personalizations may be shared between multiple instances.

portlet template settings: a set of customized data settings for a portlet template.

We left for further discussion whether the concept of portlet template needs to be broken into 2 (or more) entities.  We need to explore whether there is an entity that is the result of activating a portlet service that is used to create a portlet template (as defined above).

We didn't make much progress on brainstorming as time ran out.

d) Action Items:

1) Mike F. to post a summary of todays call
2) Mike F. to annotate his original operational list with potential questions to answer.
3) Sasha? (All) -- continue discussing terms above.  In particular clarify and resolve "portlet template"
4) All -- review and comment on annotated list with the goal that in next Thursday's call we can set priorities and begin the discussion/answer phase.

Susan Levine's Meeting Notes:

Focus of this subcommittee Proposal: identify things portal needs to ask
the portal to do, drill into details of how it does that, what info it
needs to pass the portlet to do it.  Maybe also what portlet needs to ask
portal to do, how, etc.

URL rewriting & namespace encoding also showed up on Markup Subgoup's
topics.   This should be discussed in the Markup Subgroup.

Another member wants to discuss whether url rewriting should be done on the
client side or the server side, in this group.  Moderator agreed.

Moderator:  wants spend a few minutes talking about terminology in outline.

4 distinct terms used - is this complete and sufficient?
Not meant to be physical, meant to identify logical components from the
portal's perspective that it interacts with.  Some of these may end up
mapping to the same physical things. (i.e., template may be really an
1) Portlet Service:  PS service that implemnts wsrp
2) Portlet Template: PT design entity used by users in a portal to create
portlets on a page
3) Portlet Instance: PI portlet on a page
4) Personalization Instance:  PersInst personalized data that customizes
one or more portlet instance.  [modification: call this personalization

[possible new term: template settings  might have to add data to customize
a template.  ]

Another member disagrees that we didn't use these terms:  portlet object,
portlet instance, portlet window.  All stuff about templates discussed was
that reflects ???? model.  Enforcing the model.  We wouldn't have these
layers in spec, up to implementation to determine all the layers.

Moderator:  one of diff's I'm trying to do to get us started, trying to
define terms to be used from the portal's perspective, not from the portlet
or implementation perspective.  If I were a portal vendor what are the diff
conceptual things from a portal I'm dealing with.  2nd, these terms are
meant to be logical, not physical.  Porlet Template allowed to talk about
kind of operations portal can do to a design entitiy instead of entity
displayed to the end user at runtime.  Not necessarily any predispostion
that that maps to a distinct representation in the API.  Personalization
Instance was because we may wnat to be able to discuss having a single pers
instance that maps to multiple portlet instance - portlets that share the
same customization.

Sasha:  more than one design time.  Admin design time and user design time.

Moderator: let's talk about diff classes of users, there are at least
1) admin - administer portal, create users, etc.
2) portal designer - user that preconstructs the portal structure, initial
set of pages, initial set of content
3) end user - users who can personalize content, depending on what rights
they've been given - ie., change structure, add, delete content from view,
ability to customize content data

Sasha:  there's a design tiem of portal designer, and design time of end
user.  Same portlet may be designed in a couple diff ways, look to end user
like diff portlets on a page!  Portal designer says, ie., SAP portlet give
it params, go to which server, etc., then design time of end user, here's 3
SAP gadgets, I want this one, not that one.

Mod: is this like portal designer gives high level design properties, then
end users... ????
Mod: one thing I'd throw in , in a lot of cases, there's a set of
opersations that a portal designer does to a portlet/portlet template to
preconfigure it as a design entity not as a physical entity on a page.  The
exapmle you give is there may be the general purpose SAP portlet, designer
will provide a couple of default definitions to, that will ultimately be
exposed as a design entity for being placed n a page .  They're gonig ot be
able to identify the kinds of operations that are needed to create and
manipulate the deisng entity, overlapped iwth ops portal will need to
ocmmunicaiton with portlet, when it's being placed on a page.

Point of the term portlet template is to allow us to talk about the design
entity operations.  We'll get into a discussion of whether pt's are really
just logical entities, that ultimately they'll just help us clarify
additional operations that we have to make sure are available on a portlet.

Other: what is it once it's been designed but before anybody puts it on a
page?  There's a design entity you may register in the portal, provide as
an entity that users may put ont he page.

Other: one poss scenario will be: find & bind portlet service, establish
trust, whatever, then you can use it.  In order to use it, some service may
require parameterizaton, this would be done by creating portlet templates
in scope of portal, on server side.  These parameterizaitons correspond to
things end users see as available portlets.   Instance is created when user
adds portlet to page.  That's when portlet instance is created.

Other:  if a personalization instance is a shared entity that it should be
viewed as union of all personalizations sharing it?
Mod:  or other way around, think of cloning.  portlet that clones itself,
diff between clone & copy is that personalization instance is shared.   Not
a union, just a shared reference.  But we can get into the disc if union
turns out to be better functionality that may be a better way to go as

Other: found this confusing, sounds like Pers Inst, makes more sense to
talk about a set of personalizatons bound to one particular instance.
Thing you bind to is like pers data, has a one to many relationship.
Mod:  I agree, we're just looking for a term, not trying to get
heirarchical form.

Other: maybe personalization data is a better term to use there.

Mod: user terms to talk about division of logical operations on portal.
From an instance perspective might be: find,bind,activate,deactivate:
portlet teapmlte perspective: register design entity, personalize design
entity, copy design entity, clone, etc.
Not to talk about how to model what real entities are really responsible.

Other: Need summary of personalization data:  some data that cut across all
inst of user or independent of user?
Mod: Broader than user- set of data representing personalization of a
portlet.  I don tknow a better term - idea in one to one case, simple, pers
data for PI.  In One to N case, I'm not sure what exact term is.
Other: Do you think it could alos be an N-to-N releationship?  Across user?
Like for example zip code or postal address is a user trait, but particular
password into a system might be a trait bound to that particular portlet.
Mod: might be 5th term, more data related like Profile Data - data assoc
with user independent with any particular portlet.  Profile is as good a
term as any.
Other: one type of data that can be pers data, as Sasha's saying data might
be portal specific, vendor specific, user specific.
Mod: personalization data term was trying to get at customizable element as
exposed by the portlet.
Sasha: once shared across portlets, should it be viewed as union of
personalization data.
Mod: not sure I understand usage model
Other: security issues there too.
Mod: can come up with usage models where it is the same portlet type (clone
or shared instances on the same cust data)
Sasha: like mail portlet and calendar portet from same vendor.  Might share
password customization, but have different other pers data, like calendar
displays one week or two weeks.
Mod: consumer acutally provides some of that model
Other: haven't talked about hwere this comes from. if some comes fro the
user, concrete example from Sasha is useful.

Okay, so do we have a good summary yet?  Thomas will put together an email
on flow.
Moderator will send out short description for glossary.

Mod:  Okay, let's spend 10-15 minutes talking about what a portal asks the
portlet to do.    Point is to try to capture different kinds of operations
we see we're going to have to model to breka them into discrete discussion
areas, find questions we have to answer in the areas, trying to answer the
questions, et., so we can formalize answers as requirements.

What a portal asks portlet to do
Thomas - let's go thru list
Portlet Service level:
Activate/become registered:  somehow portal locates service, activates it,
registeres it, and from that, there was an assumption that hte portlet
would need to describe its capabilities and how it expects to be managed by
the portal, during the registration process.
Thomas: do you see this as active process, or thru UDDI or directry?
Mod:  these tried to capture operations, w/o assumptions about how the
operations occur.  That'st he kind of question that we can talk about once
we have list of operations that we have to capture.  That's a valid
Thomas: this is step in which relation is established in the first place.
Portal finds service and establishes relation. After that portal can use
the service.
Mod: correct - obviously there needs to be soem xfer of info to the portal
to describe capabilities of portlet.  Thre are otehr things we can put in
here, under big umbrella of how they can be managed - level of security,
encryption, etc.
Thomas: had interesting disc in securiyt call in protocol in activate/bind
process that also credentials might be exchanged, portal gets credentials
that have to be used when it contacts the service, data like that might be
exchanged in this phase.
Mod: exactly
Mod: I have here, so once we're registered & active, portal will want to
exposed ot portal designer an entity that can be used to actually create,
design a page.  So there's a proc in portal inwhich template instance is
created.  And then we get into question of what kind of operaitons do we
think portals want to allow portal designers to do on tempalte instances:
Obvious list:
   customize template instance
   making it a true template
   clone &/or copy (clone: customization data assoc with instance is shared
   cope: customization is duplicated, not shared)

"customization data"  might have to add data to customize a template.
Mod: you dont' have to have this, portlet template may have default
settings defined by portlet itself.
Other: understood - this is kind of another logical entity that we haven't
called out explicitly yet.
Other: logically this is a separate thing, happens at separate time
Thomas:  could call it configuration , settings or whatever, create a
template instance, TI might need configuration that you might provide, when
it's configured it becomes usable you can create instances
Sasha:  you want to call it "template settings"?  good term, not confused
question: is template thing before you register, template instance is
Mod: no, portlet template and portlet template instance are the same thing
question: what is it after to you reg but before you create isntance?
Mod: design entity is portlet template instance, whether it has any
specific template settings, it's still a template isntance
Sasha: let me say in diff way. we have activate, create TI as separate
thing - why are they separate?
Mod: I think we'll find last operation of activation is to create the
template.  Portal will represent thing activated as a design entity,
manufacture this logical thing, portlet template instance.  Once it's
created, then there are the operations that the designer... we can now talk
about what teh designers do on this thing.
Thomas: q is whether this activation.. in binding to a service this would
be something that happens once between a portal and a service, in the scope
of this relation, this activation or creation of template might happen
multiple times, portal might create many TI's to same service.
Mod: 2 ways that this happens = 1)initial template, operations on template
to create new ones 2) create a whole new bindnig to teh service itself,
reregister as a distince service.
Sasha: disagree - I see after you activate and before you create TI as  a
diff logical entity.  Also a notion you talk about before, like a toolbox.
when you activate it ecomes part of toolbox, portal designer can use to
customize if they want, make available to end users.  thing that resides in
toolbox, that's the template instance, or after it's available to user is
template instance, seems like 2 diff things, diff logical entities.
Thomas: may have template instance that are activiated, ???
Mod: what I wanted with terminology is to get to this kind of point where
we could discuss additional terms to discuss additional concepts.  what
I'll suggest is I'll send out a summary of the meeting , identify open
question about are there multiple terms that we need to do because there
are distinct operations that are happening at two stages of the template.
What I'll suggest is I'll repost the list that I sent out yesterday, we can
for the areas where we think that the terms hold solid, I'd be interested
in having people question whether these operations exist or not, and to
suggest potentially new operations at the given levels.  i'll attempt to do
what I tried to do in 1st agenda, which is attach questions to each topic
area.  Next week we'll do what we'd planned for this week, see if those are
the right questions, right organization of topics, talk about how thru
concall system what are the highest priorities for that.

other: one other comment:  it seemed liek we were dropping from logical
interactions to how they were realized in a particular api before we talked
about logical interactions.
Mod:  it's a fine line when you're on phone to move from abstract to
Good sometimes to do that for illustrations, but we need to catch ourselved
from being sidetracked when basis in abstract hasn't been set yet.

Mod: please try to keep goal in mind. to articulate abstract operations
that portal needs to ineract with logical entities, you can use specific
illustrations to explain, but use as illustrations, it'll be farther on in
discussion that we'll get into details of the actual model.

Okay, then why don't I turn meeting over to Thomas and Lothar and we'll go
into that meeting.

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

Powered by eList eXpress LLC