[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 attached.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.
-- 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.
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:
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.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).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 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.
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
instance).
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
data]
[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
three:
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
well.
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
Mod:
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
question.
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
afterwards?
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
concrete.
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