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] Minutes from the April 18th concall.

Here are my minutes from the April 18th concall.  Sorry they are just in
text; I didn't have office installed on the laptop i was using.



Angel - IBM
Alejandro - Sun
Mark - Netegrity
Carsten - IBM
Mike F - Oracle
Greg - HP
Dave C - Sybase
Adam & Jon - Lexis Nexis
Nigel - Factiva
Takao - Fujitsu
Charlie - IBM
Sasha - Plumtree
Pete Quintas - Divine
Gil T. - WebCollage 
Eilon - WebCollage
Rich - IBM
Taer - Lotus
Madako - Fujitsu
Adrian Fletcher - BEA

Agenda (Carsten)
	First thing - summarize sub-groups
		Joint Interfaces - Alan
		Interface & Protocols
		Security etc

Common Interfaces (Alan)
	Have identified common areas worth discussing
	Discussion was largely around the WSIA Embedded Use case
		Likely to be some commonality with Customized use case
	We will have a more firm group of requirements on Tuesday to go over

Interfaces & Protocols (MikeF)
	Been putting together a portal usage scenario
		How does it work and operate on portlets
		Will drive our requirements for the first version of the spec
	Taking the operations we're talking about, prioritizing, and trying to frame discussion around them
	Carsten: do you want to talk a little more about the open questions?
		I'm hoping to get that list together today, there are some ongoing discussion threads (personalization data location, what are actions vs. events (are the valuable), terminology)
	Jeff: Where are the definitions for the things we talked about?
		Sasha: look at the minutes from our F2F

PFBM (Mike)
	We've not had telecons, just doing preliminary discussions
	Trying to identify scope of what to look at first
	Major work will be in bind and metadata definitions
	Publish/Find is secondary issue
	Haven't made progress on requirements for bind or metadata
	Waiting for interfaces & protocols to be created to try and decide what metadata is important; also waiting to see what groups like JSR168 are doing

Markup Rules (Carsten)
	Are trying to define set of valid tags for the markups
	First step: try to concentrate on (X)HTML
	Discussion around whether we should create "positive" or "negative" lists
		"Positive" list might restrict functionality
	Angel: have you talked about combination of attributes?
		Carsten: no, just elements
	We've also talked about maybe having different sets of tags allowed depending on whether it's embedded in an IFRAME or a TABLE
	Has WSIA defined tags?  
		Charlie/Rich: not really
	Angel: There is a spec (that didn't make it to spec) to specify XML fragments, but it's a hard problem
	Sasha: have we talked about whether the list of tags would be dynamically negotiated?
		Carsten: It's been proposed, but I think there are problems with it.  It's still on the table, though.

Security, Identity, SSO (Mark)
	Decided to focus on three areas
		Portal's identity to the portlet/trust identities
		End-user identity/credentials
		Securing transmission of data
	A few use cases, need to extract requirements
	There are going to be security implications on metadata
	Also have looked at what standards efforts intersect/fit with WSRP; found 3 important ones
		XML Signature @ W3C
		XML Encryption @ W3C
		SAML @ OASIS (recently been frozen)
	Next step is to create a working requirements documents
	Carsten: what are the commonalities of this & WSRP?
		Alan: things are at a high level right now.  It's unclear to me if these things are shared or not.
	Carsten: we have talked about a binding context for security that 
	Sasha: have you looked at WS-Security?
		Mark: we're putting it on our next con call.
	Mike asked if this group should also look at things like caching; I think it shouldn't.  What do others think?
	Sasha: I agree; also, are you explicitly not doing things like data integrity?
		Mark: That falls into secure transmission

Business Scenarios (Carsten)
	Posted two scenarios: Content for Portals & Portals sharing Portlets
	Portals sharing Portlets
		One of the most important scenarios
		A large company has within its intranet multiple portals (maybe one for US, one for European branch)
		Parts need to be shared among/between portals (like a message of the day)
		One of the Portals could "assemble the content and publish it"
		The portal could put this info in a UDDI registry and make it available
		Easy to maintain: mods on the origin portal will propagate easily
		Alan: are you considering extranet case?
			Carsten: this use case is just intranet; you could have an extranet case among vendors as well.
		Actors are server portal admin, business reason is to manage portlet centrally & be able to make it easier to manage.
		Must be easy for other portal admins to access the content; should not have programming effort.
		Must have some sort of caching applied; central portal server should be able to cache the information
		Mark: Is the way the central and slave portals interact an important part of the use case?  May not want to have centrally managed in distributed case.
			Carsten: central is only important for this use case; not required for everyone.  Distributed
		Sasha: Have you looked at how we translate user info across portals & where we store personalization info?	
			Carsten: this is an intranet case where presumably you have a central user info store, so it doesn't deal with translation of user info.
		Also, slave portal passes along markup desired, locale, & language so that the master knows what to serve up
			Directory to locate common portal
	`		Standard interface to be used by client portal and central server portal so client portals are plug-and-play
			Definition on user data/preferences/locale/markup type/natural language
			Local Portals would allow users to personalize portlets, would need to be remoted so that users would need to be able to remote preferences
		Sasha: I don't understand that last requirement.  why would portlet personalization need to be remoted?
			Carsten: they don't for this use case, but it would be nice to have the preferences stored centrally.
			Sasha: from the slave portal perspective, it's not centralized
			Carsten: yes.
		Jeff: I'm nervous about this master/slave terminology vs. Producer/Consumer.  Can we rescope this 
			Carsten: the intent was not to do this; it was just to give a special case.
		So the client portal would only act as aggregator
		Business requirement is decreasing maintenance effort; code doesn't have to be deployed on client portal
		Must be easy to integrate with just a few clicks
		Client portal would have to suppy caching to take load off of server portal
		For client, it's important to be able to get markup and propogate user info back to the server portal
		Adam: Is the fact that there is an intermediary transparent to the end user?
			Carsten: this is out of the scope; all these portlets belong to the same company.
			Adam: we have relationships with companies where we have many contracts.  Just because it's behind the firewall doesn't mean that it can be used
			Carsten: i understand this, but it's not in this scope.
		Mark: Is this any different than the basic case of Portal/Portlet?
			Sasha: no, except for user translation
			Carsten: there is a difference because there is an intermediary.
			Sasha: that's an implementation detail, portal/portlet communication is the same
			Rich & Eilon: the interface won't change, the client portal doesn't really know about the implementation
			Sasha: it won't affect our interface over and above the portal/portlet default scenario, although user scenario would add a lot
			Carsten: I agree that this would not affect interfaces very much.

Wrapup (Carsten)
	Ok, we're running out of time; let's move discussion of biz scenarios to next call.

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

Powered by eList eXpress LLC