[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. Cheers, Sasha. <<4-18-2002.txt>>
Attendance: 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 Alan - ePICENTRIC 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 PFBM Security etc Common Interfaces (Alan) Have identified common areas worth discussing Security Markup/Rewriting Properties/Preferences Lifecycle 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 Requirements 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