OASIS Web Services for Remote Portals (WSRP) TC

Web Services for Remote Portals Technical Committee
Second Face to Face Meeting June, 24th 2002
Oracle Headquarters, Redwood City, CA

Day 1

Welcome

Thomas Schaeck, Chairman of the OASIS WSRP TC welcomes everybody and opens the meeting.

Objectives

• Achieve enough agreement so spec editors can create first draft of spec in July
  • Reach agreement on WSRP concepts
  • Reach agreement on WSRP operations and WSRP/WSIA joint operations
  • Reach agreement on markup fragment definitions and URL rewriting
  • Consolidate list of metadata for WSRP
  • Reach agreement on how to apply existing security standards (SSL/TLS, client certificates) to WSRP, and talk about other emerging standards
• Continue alignment with WSIA
• Tentative date and host for next F2F meeting

Agenda

• Day 1
  • Welcome
  • Intro of new members; roll call
  • Presentation by Navy
  • WSRP Interfaces & Protocols concepts
  • WSRP Strawman
  • Markup Fragments
  • Publish,Find, Bind & Metadata
  • Breakouts

• Day 2
  • Security, Identity & SSO
  • Milestones
  • Implementaion
  • Breakout sessions
  • Summary of breakout sessions
  • Dinner
    • 2 choices: sit down dinner @ Chinese restaurant ($20/ person, need to prepay) or nice taqueria around the corner
    • Decision: Chinese

• Day 3 - Joint meeting with WSIA
  • Admin stuff
  • Go through WSIA use cases: embedded, customized, coordinated, orchestrated, & discussion of relationship to WSRP
  • Review of joint interfaces draft spec
  • Continue review of joint interfaces
  • Review of customization sub-scenarios, etc.

• Structure of subgroup slots
  • Status overview
    • List of agreed upon items
    • List of open items
  • Presentation or part of the spec
  • Breakouts

Roll Call for WSRP Face to Face Meeting

Alan Kropp, Epicentric
Gil Tayar, WebCollage
Jon Klein, Reed-Elsivier
Ugo Corda, SeeBeyond
Madoka Mitsuoka, Fujitsu
Geary Sutterfield, Dept. of Navy
Joe Rudnicki, Dept. of Navy
Adrian Fletcher, BEA
Alejandro Abdelnur, Sun
Mark Cassidy, Netegrity
Yossi Tamari, SAP
Sasha Aickin, Plumtree
Mike Young, Plumtree
Mike Freedman, Oracle
Jeff Broberg, SilverStream
Chris Braun, SilverStream
Charlie Wiecha, IBM
Rich Thompson, IBM
Carsten Leue, IBM
Thomas Shaeck, IBM
Eric van Lydegraf, Kinzan
Rajesh Tiwari, Peoplesoft
Mike Hillerman, Peoplesoft
Khuram Mahmood, Peoplesoft
Monica Martin, Drake Certivo
Ravi Konru, IBM
Rex Brooks, Individual

Navy presentation (Geary Sutterfield)

• Called task force web
• Goal is to "web-enable the Navy" by fiscal 2004
• Operational Concept
  • Trying to use the portal on shipboard
  • Have done a pilot program both ashore and on ships
• Architecture Goals & Strategy
  • Reduce dependency on any single vender
  • Allow replacement of components
  • Commercial off the shelf
  • Loosely coupled, substitutable components
  • Interfaces based on standards

• Current architecture
  • Using a product called CleverPath
  • Description of architecture

• Special XML Data in Request
  • Request includes an XML block with special Navy-unique fields (in the SOAP request or simple HTTP request)
    • Logon id, user role, client type, limited bandwidth flag, URL rewriting prefix, session id

• Config options
  • There are several configuration options to be specified by the portlet provider
    • Flag for sending Navy-unique XML
    • Template (color scheme)
    • Flag for using CSS style sheet
    • Flag telling portlet to rewrite URLs or not

• Current Portal Vendor Communication
  • Create loosely coupled, substitutable components based on open interfaces
• Vision of the Future
  • Be able to have COTS software that is WSRP compliant

• Questions?
  • What about security?
    • Obviously a big part, a "beast looking over our shoulder"; we want a single sign on solution, but that brings problems of its own
    • SAML is definitely something that the Navy is concerned about
  • Are the security issues largely on the transport or about access control?
    • They're both important, but transport comes first
  • What security measures are being used? SSL with certificates?
    • We're going to use certificates stored on cards issued to employees
  • You mentioned 2004 as a guideline; what if the specs are a moving target at that point?
    • Standards are not the main goal; the main goal is to get it working
    • So if the standards aren't there, our portal won't support standards
  • What tools do use to create portlets?
    • Generally Java or .NET
    • We don't really care what language they use
  • How do people create user-facing components with SOAP?
    • They have to follow our rules
  • Why do you need standards? You don't want to interoperate, right?
    • We want to be able to replace a portal vendor's product with another portal vendor's product
    • Want to take advantage of portlets that have already been written
  • Do you have a goal of sharing portlets across branches? With the Army, for example?
    • It is a DoD goal; creating common strategy is important
  • You talked about reusing work. How much is done over straight HTML and how much XML/SOAP?
    • Most is HTML although we prefer SOAP/XML with XSLT.
  • Does the portal clean up the HTML at all? Do you use frames?
    • CleverPath does use frames
    • We have rules about the HTML
  • Is the HTML in an IFRAME? If so, does it go through the portal or direct to portlet
    • Yes, we use IFRAMEs, but everything goes through the portal
  • Does the portal connector do the URL rewriting, or does the portlet, or both?
    • Essentially both are possible
  • What was the decision making process there?
    • Essentially, some portlet developers wanted to

Interfaces Discussion (MikeF)

• Status
  • Working on requirements doc
  • Draft API under development; not waiting for requirements
  • Issues around the model & strawman api are being discussed
• Goals
  • Brief you on where we stand
  • Listen to your feedback
  • Resolve some/many issues during breakouts; dive into details
• Decision Criteria
  • Functionality
  • Generality
  • Performance
  • Security
  • Usability
  • Flexibility
  • Vendor Extensibility - the ability to describe behaviors specific to a vendor.
  • Protocol Extensibility - essentially forward compatibility
  • Modularity - Is it subsettable?
• Today's Focus
  • The big picture model
  • What abstractions result?
• Let's start with terms
  • Define elements in the system
  • Define request scopes

• Terms/process
  • Client - with end user browser talking to portal
  • Portal - application that aggregates and maintains structure
  • Portlet Instance/Reference - specific instance of the a portlet within a portal
    • Discussion around whether it is per-user or not
  • Portlet Implementation - implementation (i.e. code) that generates content meant to be aggregated by a portal
  • Portlet Entity - abstraction that corresponds to a portlet instance (run time on the producer side)
    • Is there a one-to-one correspondence between instances and entities?
      • On an abstract level, yes.
  • Portlet Producer - The WSRP (web) service with which a portal communicates; may contain 1 or more portlet entity types
    • Portlet entity types - kind of portlet entity (stock portlet, weather portlet)
    • Is there a one-to-one relationship?
      • Not really; code can be parameterized with presets
  • Questions
    • Discussion around the use of having multiple entity types in a producer
  • Request Scopes
    • Want to define the scope & lifecycle of both persistent & transient state
      • Going to present the 4 scopes that have been discussed
    • Consumer Scope
      • Many clients all get the same scope
      • Is keyed off of the consumer and portlet producer
      • Producer can use for globally shared resources like DB connections
      • Lifecycle starts on first request from portal; destroyed when portal application "closed" or timeout (by either consumer or producer)
      • Questions
        • A lot of questions about this scope and why it's important versus registration/de-registration (Sasha, Carsten)
        • There's a lot of work in the web services world already going on here (BillC)
        • Discussion about whether or not the close call is required (Ugo)
    • Session Scope
      • Single client to a portlet producer
      • All entities in a producer for a client share scope
      • Lifecycle is on first request from portal by a user; destroyed when portal user session ends or timeout
      • Questions/Comments
        • This is really scoped at client session, not end user or end machine (BillC)
        • A user could have different scopes with different devices, like a browser and a phone (ThomasS)
        • Also, passing the scope from the portal to going directly against the app (MikeH)
          • This is obviously problematic, especially with cookie management
        • What is this used for? This is a poor implementation of an action handling. (Yossi)
          • Discussion about use cases; difficulty of calling them in parallel; changing state safely
          • Carsten will deal with this; he says that portlets should have 2 phase protocol, and portlet should change state in the first protocol
    • Entity Scope
      • All requests from a portal to a portlet producer concerning a portlet entity
      • For private resources
      • Not per user necessarily, could be across clients
      • Questions/Comments
        • Discussion of scoping at entity type vs. entity
        • Discussion of the use of this scooping
        • Discussion of whether or not this means
    • Entity Session Scope
      • All requests from a Portal to a Portlet Producer, concernng a particular portlet entity stemming from requests from a single client
      • Like a "private session"
      • Lifecycle is first request from portal; destoy on logout, portal app closes, and timeout
      • Questions/Comment
        • "Private" is a confusing word here; confused with its Java scope (CharlieW)
        • Scopes are keyed off of:
          • Consumer: consumer, producer
          • Session: consumer, producer, client
          • Entity: consumer, producer, entity
          • EntitySession: consumer, producer, entity, client
        • There are many other possible scopes, we should keep thinking and be open about them; this is not an exclusive list (RichT)
        • Is this everything we'll ever need, or should innovation be permitted (BillC)
          • Discussion about whether this is something to close us down on
          • Our goal is to be permissive on innovation level (MikeF)

WSRP/WSIA joint Interfaces Strawman API (Carsten)

• First an Overview with concepts, etc., then spec details with scenario to interface mapping and walkthrough the API
• The entity
  • Represents an "object" on the producer
  • Is represented as a reference on the consumer
  • Can be persistent (usually) or transient
    • Both have data and logic associated with them, persistent state will remain after user logs out
  • Object methods are accessible via a central access point
  • In principle, the entity on the consumer side is just a reference being held, not with state on consumer side
  • Questions/Comments
    • Discussion about where state will be stored

• States related to Entities
  • Runtime data is "transient Entity data"
  • "Persistent Entity data" stored in persistent store like DB
  • All conceptually stored on Producer
  • Associated data (db connections, cache, etc.)
    • Transient, persistent types
    • Seems like it should be transient
  • Questions/Comments
    • What is the difference between entity/associated data?
    • Discussion about what the use of these distinctions is

• Sessions
  • State
    • Transient (data would be lost)
    • Producer managed (data on producer)
    • Orthogonal to entities
    • May be shared across entities
    • 1 : n relationship of session to entities
  • LifeCycle
    • Initiated by either consumer and producer
      • Producer initiated is "created on the fly"
      • Consumer initiated is when the consumer decides they want to start one
    • May time-out or be terminated explicitly by the consumer
  • Questions/Comments
    • Discussion of saving state on the Consumer side vs. Producer side
    • The notion of having a session conversation without an idea
    • Debate and discussion over the notion that data is opaque to consumer

• Data Storage
  • At the provider
  • At the consumer, passed with each request
• Lunch break
• Scopes of state
  • Entity data (persistent & transient) begins when entity is created and ends when entity is destroyed or timed-out
  • Associated data begins when entity is accessed & ends when time-out or indicated by consumer
  • Session state begins when session is explicitly or implicitly created and ends when session is destroyed or time-out
  • These times are the latest times that they could be created

• Scope - Interfaces
  • General
    • Each scope transition could be expressed via an explicit method
    • Each entity type could be expressed via a separate handle/ID
    • Each handle/ID can be managed by client or server side
  • Draft spec goals
    • Keep it simple
    • If entities imply other entities, they should not appear in the interface
    • Allow both client and server initiated handle life cycles
      • Idea that the producer should create and make the form/syntax of the handle
      • MikeF's proposal has it the other way around

• Handle Management - who decides what handles look like?
  • Client Side (Consumer assigns handles)
  • Server Side (Producer assigns handles)

• Handle Management Pros/Cons
  • Client side
    • Consumer sends along handles and producer notices that it needs new scope for that entity
  • Client side Pros
    • Simple for consumer; potentially no storage required on consumer; handles are always valid even after timeout (producer needs to create or recreate session based on ID)
  • Client side Cons
    • Complexity to map handle to instance moved to producer; producer must be stateful; difficult time-out detection by the consumer; no seperation-of-concerns
      • Question about mapping (MikeF)
        • People agree that it means that producer needs an extra mapping
  • Server side Pros
    • Simple for producer; consumer can easily detect time-out situations; producer might be stateless; handle can contain static state
  • Server side Cons
    • Consumer must persist handles ; in time-out situations handles must be explicitly recreated

• State transitions/Scope transitions
  • Mapping of transitions to methods in the API spec (sometimes they map to an implied process)
  • All state (on the producer side) transitions are implied; creation and deletion of state does not need to show up in the interface
  • Creation & deletion of entities is explicit
    • Registration, PersistentEntity, TransientEntity, Session
  • One single call to release a handle (releaseHandle), no matter what type
    • CreateRegistration/deleteRegistration -> registerConsumer/releaseHandle
  • Only transient entity ends with time out as well
  • Questions/Comments
    • Lots of discussion about transient vs. persistent entities
    • Some consensus that this is confusing
    • Confusion about how to proceed

• Scenarios - Lifecycle states
  • State0 Unknown
  • State1 Known but Inactive
  • State2 Known and Active
  • From State0 to State1 is just discovery (like UDDI, out of band, etc.)
  • From State1 to State2 is registration and deregistration

• Registration
  • Consumer wants to become known to producer
    • Make the portal known to the provider; identify the portal; establish a trust relationship
  • Result is a consumerID or null
    • If null, then the producer is
• Client Registration
  • First, locate the service and get the producer's access point
  • Then make a bind request, which registers the consumer with the producer
  • Persist the returned consumer id
  • Next, the portal gets service description
  • After use, the consumer releases the handle
• Create a portlet
  • Consumer gets ID from DB
  • Then, Consumer sends a createPersEntity call to producer
  • Producer creates and stores handle on its side
  • Consumer stores handle
  • Consumer gets service description for entity
    • Discussion about why this is important to be WSDL
  • Consumer sets properties; producer saves properties &/or returns modified properties to the consumer

• Get Markup
  • Client makes a get request to the consumer
  • Consumer looks up entity ID and returns it
  • Consumer calls getFragments to the Producer
  • Producer might create a session on the fly, returns fragment and session id
  • Consumer returns aggregated page
  • On subsequent calls, everything is the same except for creation of session
  • When the client logs out, the consumer releases the session, and the producer destroys session data
• InvokeAction
  • Client makes request to consumer which calls getFragments
  • Markup fragments are returned to consumer with encoded actions
  • Consumer returns aggregated page
  • Client makes a form post to consumer, which makes consumer call invokeAction on the producer
  • The Producer then calls getFragments which return fragments
  • Consumer returns an aggregated page to Client
  • Question/Comments
    • Issues with modifying state over multiple producers & shared sessions being used as eventing mechanism (Yossi)
    • Perhaps blocking/non-blocking actions will help

Break

Open Issues (ThomasS)

• Do we need transient entities?
• Should we separate persistent & transient notion from entities? (MikeF)
• Do we need separation of state from logic? (RichT & MikeF)
• Do we need WSRP session sharing?
• How are scopes created/ended? (Alejandro, MikeF, & CharlieW)
• How are WSRP sessions created (implicit/explicit)?
• What scopes are required? (Alejandro, MikeF, & CharlieW)
• How are properties related to scope? (CharlieW)
• What is persistent entity, how does it persist over time, across what boundaries? (GearyS)
• How is consumer side storage of state managed? (SashaA)
  • Lots of discussion about agenda and how to continue
• Rearrangement of agenda: do markup committee now; discussion to end the day; discussions continue tomorrow morning

Markup (ChrisB)

• Charter
  • Define standard mechanism to allow common look and feel across aggregated portlets
  • Specify markup rules for different types of markup
  • Define standard mechanisms for URL rewriting and namespace encoding
• Visual Themes
  • Mechanism for common look n feel.
  • Main tool to use is CSS
  • Predefined well known classes prefixed with "wsia"
  • Only use CSS for HTML & XHTML
• WSIA CSS Classes
  • Fonts, messages, sections, forms, menus, portlet, colors
  • Merged from lists provided by different vendors
  • Examples: .wsia-font, wsia-msg-error, .wsia-section-header, .wsia-form-button
• CSS outstanding issues
  • Some proposed classes with no home.
  • Should background and text styles be separate classes
• Questions
  • Netscape 4's support for CSS is like "an elephant in a china shop". Was this discussed? (GilT)
    • We have to depend on modern technology
    • Lots of folks are phasing out those browsers
  • Why "wsia" vs. "wsrp"? (Sasha)
    • Good question, we thought it was more general than WSRP; open for debate
  • What about the connection of styles to JSR 168? (MikeY)
    • We haven't really talked about it; probably won't include this in JSR 168 (Alejandro)
    • It's probably best for our customers if we agree on this (MikeF)

• Markup Fragment Rules
  • Concentrated on (X)HTML
  • Some tags disallowed (e.g. <title>)
  • Some tags may be supported by browsers but are denied by the HTML spec, such as <link>. These would be discouraged.
  • We will not require that the container validate portlet markup
  • Enforcing is quite an issue, so can't guarantee that container will enforce
  • What does disallowed mean then?
    • If you produce disallowed markup, then you are non-compliant, and it is the portlet's fault if they don't work (RichT)
  • What does discouraged mean then?
    • If you produced discouraged markup, then you are compliant with WSRP but not with XHTML
  • Issue with XFORMs: XFORMs always puts the model in the head
    • RichT checked with XFORMs folks, who said this was a requirement forced on them by XHTML folks
  • Questions
    • What about WML? (Alejandro)
      • We haven't talked about it yet
      • Might not have to since WML is phasing out (Yossi)
    • Are you looking forward to a conformance suite? (Rex)
      • No answer; good question!

• Markup Fragment Decomposition
  • We will not specify a mechanism for which portlets can modify the containing page's <head> tag because we don't want to wait for all portlets to come back before sending the portal page to client
  • Considering extensibility mechanism for vendors to modify other sections of the page
  • Questions
    • What about onLoad type functions? (Khurram)
      • Long discussion about how portlet/portals do page eventing
    • Isn't getFragments designed to retrieve fragments for different parts of the page? (CarstenL)
      • We put it off because of the problems of the problems affiliated with deferring the streaming of the aggregated page

• URL Rewriting
  • Need a way to:
    • Intercept portlet actions, and
    • Proxy resource requests
  • Often don't want the end user to have to talk to portlet through portal

• Rewriting Scenarios
  • Four Scenarios
  • Using prefix sent by consumer
    • Producer takes prefix, puts it in before URLs, consumer parses it out and rewrites
  • Use a constant prefix
    • Consumer parses out the constant prefix and rewrites URLs
  • Consumer does it all by heuristics
    • Magic!
  • Consumer sends an actual URL prefix to use for the remote portlet

• URL types
  • Fully qualified (no rewriting)
  • Relative references
  • Portlet Action
  • Proxy
  • Action to Other Portlet
• Action URLs (Scenario 4)
  • Consumer sets an entity property that is parameterized
  • Producer writes out rewritten URL, which is sent along to client
  • Client clicks on it, which creates an action to the producer
• Scenario 2
  • Static token
  • Consumer parses and creates rewritten URLs
• Comparison
  • Static pages are easier in 2 (pro for 2)
  • Easier for the consumer; cleaner in 4 (pro for 4)

• Discussion about static content
  • Does proxy allow for HTTP gets?
  • Does this mean that the aggregated piece of the portlet could be outside of SOAP? (SashaA)
    • Err... let's defer
  • Discussion about how 2 doesn't allow for static pages.
  • In WSIA, we've talked about having a discussion about having both sides be able to do this, but we think there's a downside to using both at the same time (RichT)
  • Scenario 4 puts too much burden on the producer; it's difficult to implement (Carsten)
    • Complexity is everywhere, and portlet writer would not implement this level of portlet infrastructure (Alejandro)
  • Probably will have to do both?
  • Bring on the sumo suits and let's wrestle!
  • Discussion of what it means to support both?
    • Is it too difficult for portal? Is it important to have negotiation?
    • Maybe this is a different thing for WSIA/RP; let's say that portals MUST support scenarios 2 & 4 in WSRP (RichT)
      • General assent
  • Outstanding Issues
    • Scenarios 2 vs. 4
    • Well-defined semantics
    • Local vs. WSRP Rewriting
    • Actions across portlets
  • Name spacing
    • Aggregation of multiple portlet markup from different portlet entities can potentially result in naming conflict
      • Ids in HTML tags
      • JavaScript functions and variables
    • This problem is similar to URL Rewriting; should consider using similar mechanisms to solve both situations
  • Questions
    • If we're using a portlet proxy, does this have issues with using SOAP modules like WS-Security for security? (MikeY)
      • Valid point; haven't thought about it; might mean we have unsecure documents (ChrisB)
      • Perhaps we use SAML bindings to HTTP (RichT)

  Break

  Open Questions

  • Should we look at each question and think about it overnight?
  • We should re-evaluate the basic approach; it's too complex and tries to be too complex (GilT)
  • BTP had problems like this as well, but if people who have worked on it for a while can't explain over several hours, then we have a problem. We must be able to sell it to our friends, neighbors, etc. We must make it saleable (BillC)
  • Debate about if people understand the concepts presented
    • People don't understand and don't agree (SashaA)
  • Things are too complex; we need to start from the very simplest thing and build on top of it (GilT)
  • Clarity of exposition should come from clarity of the model; what I've heard today is that the model is not clear; let's ask what the critical part is, what the central parts are, how they can be expressed (BillC)
  • Let's start with what are the objects, what is the design pattern of how to do their lifecycle, let's refactor what we have (CharlieW)
    • General assent; everyone think about it tonight and bring in ideas tomorrow morning
  • Perhaps this isn't a good standard to create right now; we will not be able to be pluggable and will not give the customers what they want (JeffB)
  • We need to step back and see what our base concepts and desires are (ThomasS)

Day 2

Business Matters

• Who wants to be secretary?
  • Errrr.... Ummmm.....
• We will decide before lunch

Open Questions from first Day (Thomas)

• Two questions seemed to crop up
  • Are we dealing with a portlet container or an interface?
  • What is core to WSRP and what is an extension?
• Are we dealing with a portlet container?
  • Thomas gives an architecture diagram indicating WSRP as a protocol in between Consumer and Producer Container
  • This doesn't account for republishing (JeffB)
  • Portlet makers get screwed because they are dependent on a producer container (JeffB)
  • Debate about whether there should be equivalent APIs in different languages
    • This is a huge broadening of scope (CharlieW)
  • We don't really have use cases set yet; I've been assuming that major vendors are the ones implementing so complexity isn't as problematic (AdrianF)
  • We shouldn't tie the protocol to the producer container; it's like developing HTTP in tandem with Servlets (Sasha)
  • But if we don't do this, developers will be tied to a particular toolset (JeffB)
  • This is what our developers want; they're hand coding it right now (Joe)
  • The aggregation layer of the web is HTML, XML, SOAP; we should not be talking about containers. The containers are implementation details (GilT)
  • Maybe we should really focus on creating a "protocol" instead of an "API"; then we will focus on what's on the wire (Ugo)
  • There are two possibilities here; why shouldn't we define a protocol at the level of JSR 168 (MikeF)
  • JSR 168 is for things running in the portal engine; it is not remote. WSRP shouldn't be that hard to implement; there are just two calls or so (Yossi)
  • Sharing between portlets & sessions seem to require a service API at least (RaviK)
    • I disagree, there will always be programming models that map to web service interfaces (Charlie W)
    • As long as it is in a platform independent manner, we can implement portlets in multiple programming models
    • Understood. Mapping to programming models needs to be independent, sure. But if we want to provide sharing at a programming model/vendor-independent model, we need API at WSDL level for portlets to talk to each other (RaviK)
    • Are we saying that sharing is only in one producer, or do we want to have vendor-independent communication and sharing? (RaviK)
      • Defer the question because we're dealing with more fundamental questions (RichT & MikeF)
  • Is there an agreement that we care less about making it easy for portlet writers? (MikeF)
  • First, do we agree that we're doing just the web services protocols? (Thomas)
  • When is JSR 168 coming out? (JeffB)
    • Draft to the community in August; completed in February (Alejandro)
  • Debate about tools (GilT, EricvL, JeffB, MikeF)
  • Everyone's ok that we do the web service protocol? (Thomas)
    • General assent
  • Is everyone ok that we don't define producer container? (Thomas)
    • Assent, with MikeF saying that he's not sure he wants to "put the stake through the heart forever"
    • Everyone agrees we don't work on a container for 1.0
  • We must then make sure that it is as absolutely clear as possible what goes across the wire (Khurram)
• What is the core of WSRP?
  • Let's first talk about the tools available in WSDL to make things simpler (MikeF)
  • One possibility is to make methods that have null returns (Thomas)
  • Other possibility is to do notion of interfaces, but subsetting is not well done in WSDL (CharlieW)
  • Various scenarios of WSRP (Thomas)
    • Single entity in a producer
    • Multiple entities in a producer that have differing prefs
  • Let's distinguish between state and customization info (GilT)
    • State is runtime state; customization info is comprised of prefs that the consumer can "set" with the consumer. More basic question is runtime state (GilT)
    • Are they really so different? Aren't the stocks in a stock list mutable at runtime? (CharlieW)
  • Debate about whether the basic portlet is a portlet with just runtime state and no customization info or is a portlet with just customization info and no runtime state or is a portlet with no runtime state and no customization info
  • Back to scenarios of WSRP
    • Multiple pages which need a session
      • Several folks (GilT, MikeF) point out that navigation from page to page does not require a session
      • Much debate about whether the stateful/stateless distinction is important for the model; folks agree that distinction is important
    • Customizable service with multi-page navigation
      • Customized state stored at either consumer or producer
      • Multi page navigation
    • Portlets that share state (shopping basket and checkout)
      • Shared conversational state and shared customization state
      • We could use namespacing in a single session to break down the session at the producer (Alejandro)
        • This would be difficult on the producer (Carsten)
        • Much debate about whether there is a "first class handle" to entities in the portlet (GilT, MikeF, CharlieW, Alejandro, Sasha)
        • May need these for WSIA, but not WSRP (Alejandro)
        • No. (CharlieW, RichT, MikeF)
    • Portlets which have registration, separate sessions, separate entities
      • Registration needed for payment issues; allows producer to keep track of requests, etc.
      • Registration is a grouping mechanism; producer could have multiple different sets; not really coupled to persistence (CharlieW)
• Let's break and think about what parts are core, what parts aren't core, and what's been left out

• What's important, what's not?
  • List of possible features
    • Getting Markup
    • Performing Actions
    • WSRP Session
      • Stored in Consumer
      • Stored in Producer
    • Entity
      • Stored in Consumer
      • Stored in Producer
    • Registration
    • Externalized Properties
  • Let's say single page/multipage instead of getting markup/performing actions (GilT)
    • There are multi page portlets that don't involve actions (RichT)
    • This isn't important in HTTP, why is it important here for the spec? (MikeF)
      • It's like linking in HTML which refers to HTTP
  • We should have customization as a feature as well (MikeY)
    • Debate about where it belongs, what it is orthogonal to, etc. (MikeF, GilT, MikeF)
  • The list is now
    • Getting Markup (needed 1.0, MUST)
    • User Interaction (needed 1.0, MAY)
    • WSRP Session (needed 1.0, MAY)
      • Stored in Producer (needed 1.0, MAY)
      • Shared Sessions (needed 1.0, SHOULD NOT)
        • Debate around this point; RichT arguing it causes us too many problems, GilT & MikeF arguing that it's useful and maps to HTTP sessions and JSR 168 sessions
        • Debate about the use of it as a way of doing intra-portlet communications; most agree this is a bad idea (MikeF, CharlieW, GilT)
        • This is needed as a legacy issue to work with existing portlets (GilT)
        • We don't necessarily have to have the consumer create an explicit key; the producer might be able to key off of things like entity, client, user ids (Sasha)
        • We shouldn't have it on this list if it's an open question about whether it will be in the spec (Carsten)
      • Shared sessions across producers (NOT needed 1.0)
    • Entities (needed 1.0, MAY)
      • Lots of debate around runtime vs. persistent state; customization vs. runtime; keying sessions; keying entities.
      • Runtime state
        • Stored in Consumer (not needed in 1.0) Stored in Producer (not needed in 1.0)
      • Customization State (needed in 1.0, may)
        • Stored in Producer (needed in 1.0, may)
          • Persistent (needed in 1.0, may)
          • Transient (not needed)
        • Stored in Consumer (needed in 1.0, may)
    • Consumer Registration
      • In band (needed, may)
      • Out of band (not in scope of WSRP protocol and out of band)
        • Anything that is persistent, including customization, may be out of band (GilT)
        • Discussion about whether this notion complicates the spec (GilT, SashaA)
        • The spec should just be quiet about this (MikeF)
          • General Assent
        • What about registering entities and other scopes? (MikeY)
        • Consumer registration can be done at many levels the consumer wishes (per user potentially) (RichT)
          • This is problematic because it affects the semantics of the portlet (SashaA)
          • Let's put that aside; it will probably be necessary and will certainly be possible (RichT, MikeF, Thomas)
    • Consumer Registration Scope (not needed for 1.0)
      • The idea of a conversation with a consumer having its own scope
        • Point of contention; is this repetitive? Is it needed?
        • Let's put it off for now - not needed
    • Externalized Properties (needed by WSIA, may)
      • To allow programmatic access for changing properties, perhaps without the producer's edit page
        • Is this just customization state, or other scopes too? (MikeF)
          • I think it's other scopes as well (CharlieW)
        • Is it the same as customization stored at consumer above? (MikeF)
          • No, that's a blob sent back to consumer (CharlieW)
      • Perhaps this is just needed for WSIA?
      • Discussion around if this blows up the protocol because of extra parameters, etc.
      • Entity Scope (needed)
      • Session Scope (needed by WSIA)

• New secretary?
  • MikeH & KhurramM
    • Woo hoo!

• Now time to get into interfaces
  • Getting Markup
    • Simplest case - getMarkup() returns Markup
    • Does entity type belong here?
      • We need to add entity type as a concept (GilT)
  • Entity Types
    • Up the ladder - getMarkup (EntityType);
      • Services the ability to have entities without state
  • User Interaction
    • There is a notion of actions that IWS and WSXL have (GilT)
    • There is an action name and params. This came about because of analysis of the clickstream of dealing with actions, need the 2 phase commit - action then markup (RichT)
      • This requires state; actions should be doable without state. In a stateless world, we must have the action parameters on getMarkup (GilT)
      • In that stateless world, you must say that things cannot have a ripple effect so we don't have a 2 phase commit (MikeF)
    • Lots of discussion of stateless/stateful services
    • What about forms (instead of links)? (MikeH)
      • This requires another type of action handling (GilT)
      • This is an implementation detail of the consumer? (MikeH & MikeF)
      • In web apps, you often do a form submission and redirect to another page. Consumer sends a set of interaction parameters, producer returns a new set of interaction parameters and pseudo-redirect (GilT)
    • At this point there's still only one call - getMarkup (EntityType, InteractionParams) returns InteractionParams and Markup
      • Does it make sense at this point to have a performAction(Interaction Params)? (ThomasS)
      • Only if we have to deal with the ripple effect; we're not there yet (MikeF)
  • User Interaction "with Ripple"
    • Thomas describes his view of actions and the ripple effect; used for Interaction with Side Effects
    • We're getting closer to eventing model, which we decided not to do; doesn't address ripple effect because portals pull information from their cache (YossiT)
    • If a portlet induces an interaction, it will be the first that is called; afterwards, the rest of the portlets will be called (GilT)
      • This is still 2 phased (CarstenL)
    • Portlets can provide metadata about how they should be cached (ThomasS)
      • This is not subtle enough; all portlets would have to be updated whenever a portlet has an action (Yossi)
    • The eventing mechanism is not necessary at this level yet (GilT)
    • It is not a good idea to have the portlet return information on how to be cached because it would need to know what else is in the portal (KhurramM)
    • Let's deal with 2 phase in the protocol for now(YossiT)
    • So, do we need a performAction or getMarkup?
      • Debate about whether it should be a separate call or not
      • Basic assent that we should have performAction & getMarkup; always be two phase; only be blocking if it is indicated to be so
      • General impulse to stay away from optimizations (i.e. collapsing calls into one) until we find the "natural" interface (MikeF, GilT, YossiT, ThomasS)
    • So now we have
      • PerformAction(InteractionParams) returns InteractionParams
      • GetMarkup(InteractionParams) return InteractionParams & Markup
    • The "InteractionParameters" should be different from "RequestParameters"
    • Maybe we should use "InteractionParameters" and "MarkupParameters"
    • So now we have
      • PerformInteraction(InteractionParams) returns MarkupParams & Markup
      • GetMarkup(MarkupParams) returns MarkupParams & Markup
    • State diagram drawn by Thomas
    • Discussion of whether GetMarkup should return MarkupParams
      • Doubt about its use (SashaA)
      • Example of returning a last accessed time (YossiT)

Security Presentation (MarkC)

• Considerations
  • Authentication, including SSO
  • Integrity
  • Confidentiality
  • Replay & Denial of Service attacks
  • Access Control
• Priorities
  • Leverage existing standards
  • Plug n Play
• Relevant Standards
  • Transport Level: SSL/TLS, Certificates, HTTP-Basic Auth
  • Document Level: WS-Security (not opened by open standards committee, but important), XML-Signature, XML-Encryption, SAML
• WSRP using Secure Transport
  • SSL/TLS over HTTP
    • Client certificate for Consumer auth by Producer
  • Benefits
    • No impact on WSRP protocol
    • Widely used infrastructure
    • Addresses key integrity, confidentiality, & auth
  • Limitations
    • Only secures point to point connections; will not go from Client to Producer
    • We limit ourselves to just one transport, and it has some performance issues (YossiT)
• Secure Transport Scenario
  • Secure transport between client and consumer and between consumer and producer are independent
  • No metadata strictly required for SSL
  • We think it's a good idea to have producer metadata where it says if it requires secure transport to client
    • Not enforceable, but nice to have
  • Consumers should have page be https if any portlet is https
• Challenges with doc level security
  • Typically, several mechanisms used together to achieve overall goals
  • Many different deployment scenarios possible
  • No standards for
    • Describing encryption and sig capabilities
    • Describing policy for signing and encryption
  • What are the reasons for this? (EilonR)
    • Performance, gateways (MarkC, YossiT)
• Subgroup status: document level security
  • It is important to have some form of support for sigs and encryption in v1.0
  • WS-Security provides support for use of sigs and encryption in SOAP messages (via security header blocks); it dovetails very well with what we're doing
  • WSRP policy for use of sig & enc
    • Should be tightly constrained to maximize plug & play
    • There will be policy description in the future; we should merge with it in subsequent versions
  • SAML situations with multiple parties should be deferred for now
    • I.e. getting a token from a third party, etc.
• Impacts on WSRP Metadata
  • We need a policy for digital signatures
    • When specified, all consumer requests must be signed
      • Will not have a rich enough policy to talk about signing part of requests
    • Scope of the signature is the entire message
    • We will defer requiring client signatures (from client to consumer to producer)
  • Producer capabilities for signature algorithms
    • When the consumer registers, it will know how to sign docs so that the producer will understand
  • Producer policy for property data encryption (whether it is or is not encrypted)
    • We will only encrypt element data, not elements themselves
  • Producer capabilities for encryption algorithms
• Impacts on WSRP Protocol
  • Consumer must specify its signature and encryption algorithm capabilities in the registration operation
  • Data objects carried in WSRP messages may be encrypted
• Process -- Business Relationship
  • Step 1: Business Relationship is established and token given to consumer folks
  • Step 2: Consumer registration
  • Step 3: Get service description
    • Returns algorithms etc.
  • Step 4: Signatures
    • Policy says consumer will sign all signatures IF signatures are being used
    • Signatures are self-describing
  • Step 5: Encrypted Data
    • Properties and markup fragments might be encrypted
    • Encrypted elements are self describing
  • Encryption and Digest Keys
    • KeyInfo carried in the XML per WS-Security
• Discussion Points
  • WSRP-specific policy descriptions for enc & sig are necessary and will be replaced
  • Support for sig & enc in SOAP stack not very available
    • WSRP folks will need to roll their own in the meantime
  • WS-Security not yet an open standard
    • Done by Microsoft, IBM, & Verisign
• Perhaps since SSL is much better supported, we should only use SSL for now and use WS-Security etc. later (GilT)
  • What do we get out of using WS-Security, partial encryption, etc.? (Alejandro)
  • Performance (although debatable (Eilon))
  • Debate about whether SSL allows you to use certificate, encryption separately
  • We will be out of date as soon as the other standards get ratified (ThomasS)
  • These standards are at least 2 years away, can we wait that long? (YossiT)
  • Is it ok to tie ourselves to HTTP? (Ugo)
    • General belief that this is ok
  • What would be the use case of sig or enc on top of SSL? (Alejandro)
    • On one hop, none (YossiT)
  • Is multi-hop important- between Consumer and Producer? (Alejandro)
    • Yes, republishing is important (YossiT)
    • Debate about republishing, url rewriting, adding info to the markup
  • Often privacy are tied to laws; for example Germany has strict laws about how information about a person is distributed (ThomasS)
    • Initial opinion of the subgroup is that adhering to these constraints is a responsibility of the Consumer; possible impact to protocol is limited to consumer informing the producer of client's privacy profile
  • DECISION: We will not address document level security in v.1.0 of the protocol. We will only address transport level security.
    (CharlieW)
    • SECOND: SashaA
    • Carried by general assent - woo hoo, we made a vote!
• Now, on to Privacy concerns
  • Are we required to take these concerns up legally? (RichT)
    • We need to figure out if consumers can be legally implemented without us having the privacy concerns in the protocol
  • Discussion about whether privacy settings affect the protocol
• User Profile
  • We've talked about having a user profile passed from consumer to producer; could draw from existing directory or other standards
  • Issue: not yet defined how this data object would be used by a producer, or how its data elements relate to entity properties
  • Big debate about whether user profile can be plug and play if parts of the user profile may not appear due to privacy concerns
    • YossiT argues this kills PnP
    • EilonR argues that PnP is about not having coding, but may require administration
  • Is there a possibility that we would have to propagate privacy information on to producers so that they would know what to do? (SashaA)
    • Thomas dings me about not being a multi-country company J
    • There is no standard way to encode that info (EilonR)
• Access Control & Roles
  • Consumer may implement access control to WSRP operations in a declarative fashion without impact on protocol
  • Producer may implement programmatic access control via role definitions
  • Issue: are standard roles required?
    • No agreed semantics
    • Proposal to have no semantics
      • Strawman had 3 roles: admin, designer, and end user
      • JSR168 has no roles
  • Question: can we support the portlet itself specifying if it can be added to a user's page? (MikeH)
    • Roles don't have to be the same, they have to mappable (MikeF)
      • Mappable roles is kind of a difficult issue; probably want to do it with a different thing like a directory server (MikeH)
    • Debate about whether this mean it is not Plug and Play or not

Milestones (Thomas)

• July 2002 First draft of WSRP spec
  • End of July
  • Depends on what we get done tomorrow
  • Not accounting for a lot of stuff (profile, etc.) (YossiT)
  • We're 4-8 weeks behind schedule (MikeF)
• New proposal
  • July 2002: First draft of core spec for WSRP
  • August 2002: First version of Impl proving that spec works
  • September 2002: First draft of spec for WSRP
  • November 2002: Final draft of WSRP spec
  • December 2002: Update of Impl to reflect final draft - Submit as Standard
  • January 2003: WSRP Spec 1.0, Update of Impl to reflect 1.0 spec, Compliance Test Kit
• When are F2Fs?
  • September 9th-11th, 2002
    • IBM offers to host in Boeblingen, Germany
    • Debate about whether it makes sense to do this
  • November 11th-13th, 2002
    • Where and by whom unclear - perhaps NY with IBM?
  • Agreement that one of those meetings should be held in Europe, one in the US.
  • Proposal that the meeting requiring widest participation to be held in the US.
  • November Meeting needed to approve 1.0 specifictaion � needs widest participation and thus should be in the US, therefore the Sept. meeting to take place in Europe.
  • Only offer to host in Europe from IBM, the meeting will take place in the IBM Development Lab in Boeblingen, Germany.

Day 3

This was a joint meeting day with WSIA

Roll Call

Charlie Wiecha, IBM (Chair WSIA)
Thomas Schaeck, IBM (Chair WSRP)
Darren Kline, Peregrine
Rex Brooks, Individual
Alejandro Abdelnur, Sun
Yossi Tamari, SAP
Royston Sellman, HP
Rich Thompson, IBM
Chris Braun, Silverstream/Novell
Carsten Leue, IBM
FT
Peoplesoft
Eilon Reshef, WebCollage
Gil Tayar, WebCollage
Mike Young, Plumtree
Sasha Aickin, Plumtree
Joe Rudnicki, Dept. of Navy
Mike Freedman, Oracle
Mark Cassidy, Netegrity
Martin Chapman, Oracle
Srinivas Davanum, Commerce One
Eric van Lydegraf, Kinzan
Tim Jones, Crossweave
Shankar Ramaswamy, IBM

Welcome (CharlieW)

• Agenda & setup for WSIA folks

Introduction and Update on Day 1 and 2 (ThomasS)

• This presentation will give a background to WSIA folks to get them up to speed on what WSRP has been doing
• First, we agreed that we are just talking about the protocol across the wire
• Next, we go over the scenarios (see day 2's notes for more detail)
  • Simple, stateless portlet
  • One entity with multiple sessions
  • Multiple entities with multiple sessions
  • Multiple entities sharing a session
  • Registration of multiple entities
• Next, we went over a list of necessary functionality that was agreed upon
  • See list from day 2's notes
• Discussion about why we have entities
  • Different customizations of the same service (ThomasS)
• Question: did we decide that Entity Types are a must in the protocol? (AlanK)
  • People believe that it is needed, but a MAY
• Question: we may need to be able to have a third party that holds information (ShankarR)
  • This is different than sending information that the producer needs to actually make the content (ThomasS)
  • But a producer could personalize based on directory-type information; perhaps this means we have to decouple the personalization information into a separate interface (Shankar)
• Question: registration seems to be used for both grouping and consumer authentication sorts of things. Which is it for? (EilonR)
  • The credential part is sort of out of band (ThomasS)
  • Which ones are needed? Credentials or Grouping? (EilonR)
  • Both are needed

Discussion of WSRP/WSIA interfaces

• GetMarkup call may not need to return MarkupParameters for various reasons (MikeF)
  • We will defer that discussion, but it's a good question
• First, Thomas goes over the model of getMarkup from yesterday (see day 2's notes for details)
  • Description of the markup parameters (GilT)
    • Essentially replicating web application lifecycle (EilonR)
  • Essentially, the performAction call gives back MarkupParameters that have to be passed to getMarkup
  • Have to send back the MarkupParameters to each getMarkup call
  • MarkupParameters are like a cookie, they can have all the state or correspond to state stored on producer
• Are we grouping/categorizing/putting into interfaces?
  • Answer: not yet. We're trying to concentrate on stateless producers and move from there. We're going to start with the basics and categorize later
• Once again, the issue of getMarkup returning MarkupParameters is raised; we will address at some point but move on for now (MikeF)
• Would it make sense to have the base URL of the Consumer in the MarkupParameters? (Royston)
  • This is URL Rewriting; let's deal with that later (GilT)
• On to entities
  • We need to have customization state, stored both at consumer and producer side.
  • Would it help to have a different word to talk about entities since they are now units of customization state? (MikeF)
    • Discussion about ideas of "components", "entity types", schemas, what each of them means
  • Thomas draws a hierachical diagram, which is eventually changed to have the following four levels
    • Code - the logic of the portlet
    • Entity Type - Producer offered customizations
    • Entity - Consumer defined specializations
    • Instances?? - Runtime user/device specific conversation
  • So the decision is:
    • There is a notion of producer-offered entities and consumer-customized entities
    • Entities are distinct from their runtime, at runtime there is not a differentiation between producer-offered entities and consumer-customized entities - they are both first-class entities
  • What do we need in terms of lifecycle methods?
    • Describe - metadata
    • Create
    • Destroy
    • Modify
  • Will modify will fail on top-level entity? (CarstenL)
    • Might return an entity reference (ShankarR)
      • Yeah, but that's an implementation of the spec detail (Various Folks)
    • Destroy is a cleaner example of this; can't destroy a producer-offered entity (RichT)
  • There is a case for having different types of handles so we can do early type checking (CarstenL)
  • Let's break for lunch!

• Lunch
• Dinner organization
• Back to interfaces discussion
  • Entity state stored on Consumer
    • If it's stored on Consumer, then the Producer needs to send it to Consumer and Consumers need to send it back
    • Let's leave this to the mailing list
  • The getMarkup needs to take in an EntityRef, not an EntityType (GilT)
    • Yep
  • There may be another thing in our hierarchy, "siblings" of consumer-defined specialization (RichT)
    • Clone vs. create
    • This raises the notion of configuration trees, do we really want to address this? (EilonR)
    • There are three levels of this: no configuration branching, configuration branching, and then configuration branching with persistent relationships. (SashaA)
    • We can have branching without relationships over time (clone), but we shouldn't support persistent relationships over time (GilT)
    • Any time you say a hierarchy tree like this has n levels, someone comes along and says, "I'd like n+1 levels" (Alan)
    • Persistent configuration trees are really not particularly useful and super confusing for users (EilonR)
    • We want nested configuration scopes; we support many levels of configurability (site, user groups, etc.). All inherit from base entity (AlanK)
      • If you start looking at the way that inheritance is used will probably be different between vendors; inheritance is implemented differently. Epicentric can still do inheritance by maintaining its inheritance itself (GilT)
      • If the state is stored Producer side and is opaque to the Consumer, then inheritance is not implementable by a vendor. (SashaA)
      • Agreed, but we don't seem to need it from a functionality standpoint (GilT & AlanK)
      • Cascading deletes are a little problematic, but I can live with it (MikeF)
      • DECISION: there are no persistent relationships between entities expressed in the protocol
    • Debate about whether there are separate create and clone operations
    • Let's change the names to createEntityRef(), cloneEntityRef(), etc. (RichT)
      • No, createEntity(), cloneEntity(), etc. (GilT)
      • Cool. (Folks)
  • We said that entities don't have relationships, what about if an entity wants to get to a different entity?
    • This is not expressed in the protocol (ThomasS)
• Talking about Sessions
  • Two kinds of sessions have been identified
    • Shared and single entity
  • We've implemented this in the MarkupParameters essentially; MarkupParams are opaque and can hold on to session handle (Yossi)
  • Right, this is non-shared session created by producer; how do we do shared session? (ThomasS)
    • Lots of back and forth about whether the Producer should manage these sessions
    • Emerging consensus for a "group id"
    • Lots of discussion around sending consumer, user, & group id and getting session ids created by the producer
  • Significant debate about whether session id should be sent back or the producer should key off the parameters every time
    • Scalability of consumer is very difficult if it has to keep millions of session ids (MikeF)
    • Lots of arguments about whether it's a good idea to make a relatively stateless consumer, if it's an important use case, if it puts too much burden on the Producer
  • How do we reach conclusion? (ThomasS)
    • First option: Producer makes session ids and sends them back with subsequent requests
    • Second option: Consumer creates ids and sends it out to Producer
  • Maybe we don't need to decide A or B, but provide metadata to tell what models are used
    • Metadata to say "I don't change my session", for example (MikeF)
    • It's kind of a deployment issue (EilonR)
    • This is like the persistent data being kept on Consumer or Producer; doing it two ways is more complicated (ThomasS)
    • We come to Third option: Metadata that says whether producer uses option one or option two. Then option one is the default, option two is an optimization for both the producer and the consumer (MikeF)
      • If this is just a performance issue, let's move it to v2 (Carsten)
      • We won't be successful without it (MikeF)
    • Is this the same as the shared session/entity instance issue? (CharlieW)
      • Yeah, it's essentially the same question; I would argue it the same way (MikeF)
  • More debate about importance of stateless Consumers
    • Stateless Consumers are not real; all portals do lots of caching, etc. (YossiT)
  • So what do we want to do?
    • Let's not worry about it for now (YossiT)
    • Let's do option one in v1 and potentially option three later (SashaA)
  • DECISION: We should do option one for v1 and save other options for subsequent versions (SashaA)
    • SECOND: (RexB)
    • For: "About 21 or so"
    • Opposed: 1
• Break
• Back to sessions
  • Can two instances corresponding to the same entity have both shared and private sessions?
    • Here's how (GilT):
      • Step1: to w1: getMarkup("groupID", "weatherentityID", "") returns session1
      • Step2: to w2: getMarkup("groupID", "weatherentityID", "") returns session2
      • Step3: to w1: getMarkup("groupID", "weatherentityID", "session1")
      • Step4: to w2: getMarkup("groupID", "weatherentityID", "session2")
      • Sessions have private & shared sessions encoded in them
        • Assent generally
    • This is somewhat contradictory to the objections brought up to returning session ids (MikeF)
  • So now we have:
    • Parameters
      • IN: Consumer Context
        • Consumer ID, User ID, Session-Group ID, Entity Ref
      • IN: Client Context
        • User Agent Info, Device Info, Locale
      • IN/OUT: Session ID
        • We will take this to e-mail
• Now, let's go back to the getMarkup & performAction calls
  • ConsumerContext
    • ConsumerRef, UserIdentity, EntityRef, SessionGroupID
  • RequestContext
    • Let's look at performInteraction
      • We're taking out newSessionCreated as a return value since it's only needed if you are doing options 2 or 3
      • (markupParams, sessionID, newSessionCreated) = performInteraction(consumerContext, requestContext, sessionID, interactionParams)
    • Now getMarkup
      • (markup, markupParams?, sessionID) = getMarkup(consumerContext, requestContext, sessionID, markupParams)
      • Why are markupParams and sessionID both returned? They are used for the same thing; there's no difference. (SashaA)
        • MarkupParams is for stateless portlets, sessionID is for stateful portlets (MikeF & GilT)
        • I disagree (SashaA)
        • We'll defer that debate
    • Lifecycle Methods
      • (metadata) = describe (entityRef)
      • (entityRef) = createEntity(consumerRef, entityRef, customizationData)
      • destroyEntity(consumerRef, entityRef)
      • modifyEntity(consumerRef, entityRef, customizationData)
      • Do create and modify need an in/out of a sessionID? (RichT)
      • How do we create one temporarily so that the user can cancel it out? (CarstenL)
      • How does someone get a consumerRef? (Shankar)
        • Registration, probably
      • How does someone create a new entity? What entity ref do they use? (Shankar)
        • Producer offered; we'll specify how a producer offers
    • We need to move on to Externalized Properties
      • Methods
        • (requestedProperty[]) = getEntityProperties(consumerContext, (entityRef,) names[])
        • (propertyChanged[]) = setEntityProperties(consumerContext, (entityRef,) names[])
        • (requestedProperty[], markupParams, sessionID) = getRuntimeEntityProperties(consumerContext, (entityRef,), sessionID, markupParams, name[])
        • (propertyChanged[], markupParams, sessionID) = setRuntimeEntityProperties(consumerContext, (entityRef,), sessionID, markupParams, name[])
        • (schema) = getPropertySchema(consumerContext, (entityRef, ))
      • Question: shouldn't we not use sessions? Aren't we modifying entities? (SashaA)
        • No, we're doing runtime too (MikeF)
        • These should be different calls (EilonR)
      • Debate about propertyChanged returned by setProperties()
        • Used to notify the consumer that properties have changed as a side effect of setProperties
        • MikeF and SashaA skeptical
        • Needed mostly for WSIA
      • Do get and setEntityProperties make sense on producer-offered entities? (EilonR)
        • No on set, yes on get
      • Discussion about if schema is dependent on configuration
      • Let's get rid of this whole thing; this is a WSIA issue that has made an eventing mechanism creep into our spec (YossiT)
      • We can factor the design if we need to and merge things like performAction (ThomasS)
      • We cannot insert things just because WSIA needs them; we have to be true to the goals of WSRP (YossiT)
        • Lots of debate about what belongs in WSIA and what belongs in WSRP, and how to handle conflicts, extensibility, and what will be in the WSDL
      • Question at hand: should get/setProperties be joint interface with WSIA or a separate interface just in WSIA? (ThomasS)
        • Obviously raises issues of interop
        • We come close to completely breaking down our relationship
      • Is there use that WSRP gets out of these property methods?
        • Getting schema, gettingEntityProperties seem obviously good for WSRP (admin, etc.)
        • PerformInteraction returning properties changed seems useful as well
          • But these are runtime props, so we might as well have get/set runtime props
        • If we have two performActions, there is no interop (CharlieW & EilonR)
      • Much debate about whether it makes sense to have interop
        • YossiT tends to not care about the importance of interop; CharlieW tends to be on the other side
        • We need to be like HTTP (allow for minimal implementations of a complicated spec). Let's allow for nulls to be passed, (GilT)
        • We're allowing for things like eventing, but poorly. We threw out eventing earlier, now we're letting WSIA put it back in. And do you REALLY want to pass null all the time? (YossiT)
        • How are we going to have cross interop (WSIA Producer & WSRP Consumer or vice versa) if they are passing nulls? (Alejandro)
      • Stepping back to summarize: (ThomasS)
        • We could put these things into performAction
        • We could have get set props be different interface
        • Then we just need to ask if we need to make the decision to have the sacrifice for adding one parameter into performAction
      • No, if we make the sacrifice, we might as well go whole hog (YossiT)
      • Maybe we should use a notion of headers: name-value pairs (EilonR)
        • They have meaning/semantics; these properties don't! (YossiT)
      • No agreement was reached on whether the properties interfaces should be part of the joint WSRP-WSIA specification. It was decided that more discussion is needed to form a consensus on this topic.
    • Consumer Registration / Deregistration with WSRP Producers
      • The group agreed that registration / deregistration is required and that the spec editors should come up with a proposal for the next version of the spec strawman.

Adjourn

• Thomas thanks all participants for coming and looks forward to hosting the next F2F Meeting at the IBM Development Lab in Boeblingen, Germany.