OASIS - Committees - OASIS Web Services for Remote Portals (WSRP) TC

OASIS Web Services for Remote Portals (WSRP) TC

WSRP Meeting One Day One (March 18, 2002)

Thomas Schaeck, Chairman of the WSRP TC
Architect for IBM WebSphere Portal Server

Intros

In Person:

Mark Cassidy - Netegrity - dev of portlets
Angel Diaz - IBM
Brian Dirking - Stellant - specifying portlet code
Alan Kropp - Epicentric - WS architect
Jeff Broberg - SilverStream - vp of r&d
Petr Palas - Moravia IT
Greg Pavlik - HP - Principal architect on multi-modal portal
Bob Serr - Divine - Web Services technology
Peter Quintas - Divine - directo
Mike Friedman - Oracle
Carston Leue - IBM - web services into websphere
Lothar Merk - IBM
Charlie Wiecha - IBM - chair of WSIA
Aditi Karandikar - France Telecom
Gino Filicetti - Bowstreet - portal product
Jon Klein - Lexis Nexis - on portal intiative
Adam Nolen - Lexis Nexis
Nigel Ratcliffe - Factiva
Adrian Fletcher - BEA - engineer on portal product
Bill Cox - BEA - CTO office
Alejandro Abdelnur- Sun Microsystems - (working on JSR 168)
Takao Mohri - Fujitsu
Madoka Misuoka - Fujitsu
Yossi Tamari - SAP Portals Israel
Ron Daniel - Interwoven

Phone:

Tim Granshaw - SAP Portals
Andreas Kuehne - from Germany ind. Member
Mike Hillerman - Peoplesoft
Karl Best - OASIS

Intro/Welcome from Karl Best of OASIS

OASIS TC process doc
- Need to be conducted in open and public manner
- Minutes taken and posted to web page
- All discussions on mailing list - publicly archived
- Nothing behind closed doors
- Two steps to approval - committee approval and OASIS level approval
OASIS Intellectual Property Rights
- You can donate technology, but you must identify all copyrights, patents, and specify what the licensing policy is
- Spec will be copyright OASIS
Relationships with other committees

Election of WebMaster, Secretary, & Editor; specification of mail list

mail list will be open to members of OASIS
Lothar Merk - web master
Secretary - Sasha & Bob Serr for one quarter
Editor - Carson Leue & Jeff Broberg & Alan Kropp

Charter Review

Create XML/WS standard for plug/play of: portals, other intermediary web apps that aggregate content.
Work closely with WSIA TC
Harmonize WSRP with existing programming models (portlets, WSIA, ...) & with W3C standards (Xforms, DOM, XML Events, etc.)
Promote WSRP to status of international standard for conduct of XML & Web Services based web app development, deployment, & management
Comments?
- What do you mean by intermediary web apps?
  - Thomas - we'll get to use cases later
- Jeff - it looks like we have 3 committees working on the same problem. We should have a more formal relationship.
  - Thomas - we should probably create a joint working group on base services
  - Jeff - WSRP seems to have more relevance in the short term. There's a possibility that folks will do WSRP and not go ahead and do WSIA.
- Bill Cox - Latent assumption: resource issues are significant. There isn't as much overlap between JSR and this, but lots between WSIA & WSRP.
  - Thomas - WSRP is for remote invocation, JSR is for local invocation
- Alejandro - JSR is in "javaland"; WSRP doesn't require Java
  - Angel - Web Services are "above runtimes"; they are about interop
  - Thomas - we need to take care since Java & .NET web services stacks are not entirely compatible
- Bob - Should we change the relationship with WSIA officially?
  - Charlie - we should wait until end of the meeting to decide.
  - Angel - possibility of joint subcommittees
  - Bill - we can come back to the charter at any time
Deliverables: spec of set of WS interfaces/contracts that will allow businesses to
- Implement WSRP services according to spec so that they are interoperable
- Publish WSRP services into UDDI with meta-data for their capabilities
- Implement consuming apps according to spec so that they are interoperable with compliant WSRP services
- Find WSRP services in UDDI directories and exploit the associated meta-info to determine capabilities.
Comments?
- Bill - current charter doesn't really say what Web Services for Remote Portals (WSRP) are. Is "vacuous".
  - Angel - we haven't really discussed what they are. This is another way of saying that we should fit in
  - Bill - I'm expressing a discomfort. Are other folks unclear?
  - Mark - it might be useful to talk about what makes a WSRP service different from other Web Services
  - Thomas - we should add defining WSRP services in the charter as a TODO
- Ron Daniel - part of the charter is to define what is out of scope
  - Thomas - let's wait until the presentations
  - Charlie - main difference is that these are user facing/interacting web services.
Following should be possible
- Portals should dynamically plug WSRP services
- Portals should be able to publish local portlets as WSRP services
- WSRP services should be implementable on any Web services capable platform (J2EE vs. .NET)
Comments?
- Adrian - saying any local portlet is problematic
  - Thomas - both local and remote portlets are needed
  - Alejandro - there will be a close relationship between JSR 168 & WSRP
  - Leue - make sure we limit ourselves to constructs that are implementable on many platforms
  - Bob - we're going to have a lot of services to send out from both Java & .NET without a portal at all
  - MikeF - a lot of what we should look at is performance, not developer-centric issues. People should program against an interface without knowing whether they're remote or local
  - Peter - we need to have a better definition of Remote Portlet/Portal
    - Thomas - We wanted to have a broad charter that people could agree to, detail can now be added as the WSRP TC agrees
  - Adrian - we need a term for the container that the portlet lives in - runtime that it lives in
    - Jeff - I'm uncomfortable with defining things outside of Portals, going into generalized containment
    - Bob - the client is the portal, let's just look at the interface, it will narrow scope
  - Bill - confused with difference between WSIA/WSRP. WSIA is trying to define terms to talk about interactive apps in a generalized sense. WSRP needs a much more focused vocab for the interactions. WSRP is more focused than WSIA, is that true?
    - Charlie - can we defer that til the WSIA presentation?
    - Rich - the second bullet seems to talking about a particular technology
      - Thomas - this is just an example of how things could be used
    - Bob - portal can consume it, people can create it, language independent is important
    - Greg - are these use cases or part of the charter
  - Bill - use of "shall" is "interesting". I think what we mean is that the spec "will allow" the following things.
    - Thomas - let's incorporate those changes
  - Sasha - let's put the discussion of what a Remote Portlet is on the agenda
  - Alejandro - I want to know what we mean by Portal and Portlet
  - MikeF -- we want to make sure the service definition can be efficiently expressed
    - Thomas - we should definitely try to minimize roundtrips and size of datasets
    - Angel - this gets into implementation
    - MikeF - there are things that are part of the protocol; chattiness, markup style, etc.
    - Thomas - gives examples of things that could be efficient & inefficient, points out that protocol design in the standard has major impact an achievable efficiency of implementations.
  - Yossi - security issues: there are two levels here: the communication between the portal and the portlets, and the users in the portal are another level. How do you impersonate a user? How do you make sure the client has impersonation facilities?
    - MikeF - I don't think that this belongs in the spec. Let's look at what is important and then talk about it.
    - Yossi - security is always talked about after things are done. We send sensitive info so this is important.
Phases
- Gather Requirements across vendors, etc.
- Produce initial draft of spec for review by members
- Produce initial spec of WSRP that can be commented on and a ref implementation
- Finalize version of spec and update ref implementation
- Define design patterns for developers. Encourage implementation, suites, and interop
Do phases 1-4 in one year. Phase 5 in one year.
Comments?
- Greg - who will work on ref implementation?
  - Thomas - IBM can donate folks, we have a policy that we create ref implementations; could be under apache license
  - Adrian - what is the position of the ref implementation? Is it normative?
  - Thomas - Reference implementation is not normative, the OASIS Specification defines the standards, not a reference implementation.
    - Alejandro - there doesn't have to be a ref implementation; not required. There just need to be 3 companies who implement
  - MikeF - will we discuss organizationally how we are going to do the ref imp?
- Peter - how does this line up with the timeline of WSIA? We didn't talk about ref imp, right?
  - Charlie - no, we didn't talk about it.
  - Thomas - anyone from the TC could help with the ref imp.
  - Sasha - do we have dependencies on WSIA's schedule?
- Ron Daniels - test suites should not be created a year afterwards. They should come out with the spec
  - Various folks - make it part of the ref implementation.
  - Thomas - are folks cool with that? Perhaps they should be different developers, otherwise errors that are consistent in the reference implementation and the test suite will not be discovered. Let's put a parallel test suite deliverable as a goal.
- MikeF - What about extensibility? Do we have the notion of incorporating the union of functionality of various portals? Is metadata extensible?
  - Bill - in general, extensibility seems a good idea, but interop problems always happen
  - Alan - if the consumer doesn't understand the metadata, portlet should be viable
  - Rich - WSDL helps out with required and optional portTypes
  - Sasha - this is on a collision course with plugability
  - Carlton - is this going to make companies make proprietary extensions and crush compatibility?
  - MikeF - or will it encourage innovation?
  - Bob - does everyone agree that this will be a constant tradeoff?
  - Bill - I think that this is an important thing to have in the spec, along with security
  - Thomas - let's say that we want to aim for extensibility while maintaining interoperability
  - Adrian - the question is do we want to restrict people to what they do, or do we want to give them free reign?
  - Jeff - I feel very strongly that we should have extensibility.

Break for lunch

Overview charts

Web Clients, Portals, Clients, Registry, WSRP Services
Scenario 1: using WSRP service in portal
- Aggregate services
- Services are (optionally) aware of portal context. User profile, language/markup-type, device type
Scenario 2: Portal sharing Portlets
- Client Portal and Server Portal
- Server Portal aggregates portlets and republishes them as WSRP wrapped things
Scenario 3: Client Apps with WSRP services
- Client apps could embed using activeX, applets
Architecture diagram
- Transport: HTTP
- Languages: HTML, WML, VXML
- Then Portal
- Then Portlet API
- Perhaps Generic Portlet Proxies over Intra/Internet using WSRP
- Remote Portlets
- Directory: UDDI, etc.
Positioning
- WSRP = platform independent standard
- Several platform specific apis may be created: Java Portlet API, c# portlet API?, plain, visual, user facing API
Related standards
- WSIA - some overlap (perhaps base interfaces - lifecycle, etc.?)
- UDDI - publish, find, & bind
- WSDL - description
- SOAP - invocation
Comments
- Sasha - why is Scenario 2 different/interesting?
  - Thomas - the server is republishing local portlets

WSIA intro - Charlie Wiecha

Been around for about 2 months
Check out www.oasis-open.org/committees/wsia
We've put together some use cases; goal is to have requirements doc done at end of April mtg
We're not looking at "no programming" approach
- We're interested in the consumer adding value/reusing content
- We want to know specific things about how the provider can change its UI and its data
Positioning in the Web Services stack
- Incorporates flow description - might want to know what the flows are to change dynamically on the consumer side
We need to liaison well with other committees
All of our use cases fall out into producers, consumers, client
- Is recursive - consumer can be producer
Services can go directly to client or be aggregated with the same dev effort
Business scenarios at www.oasis-open.org/committees/wsia/scenarios/index.shtml
Want to be able to pull apart the content coming from the producer
- For example, take out pulldowns or buttons based on knowledge of the user
There's also the question of how to wire up separate portlets or components on the same page
Use cases
- Embedded
  - Placing WSIA web service inside a new container side-by-side
  - Ex: stock plot in a portal
- Customized
  - Embedding WSIA inside a new Web app, with L&F mods, add or exclude elements, alter actions for element
  - Ex: altering the options in the nav bar for stock plot or excluding some elements customization can be static or dynamic (per-user, per-session, etc.)
- Coordinated
  - Integrating and providing in-page wiring for different components from diff. Producers
- Orchestrated
  - Adapting flow of the component
- Republish
  - The consumer turns around and becomes the producer
Embedded Services Diagram
- There's no kind of integration; just an HTML table
- Potential APIs
  - Lifecycle (createInstance/destroyInstance)
    - Hopefully this will go away in the long-term and be pushed down into the web services stack
  - User Interaction (getOutput/invokeAction)
  - Service Description (getInterface/hasInterface)
- MikeF -- do you rely on another repository for definition? Did you talk about services describing themselves?
  - Charlie - we've talked about it among the WSXL group, but it's open
Customized Services Diagram
- APIs
  - Consumer modifies the content from the Producer
  - GetPropertySchema, get/setProperties
Coordinated Services Diagram
- Wiring of events among different components form producer
- Ex: Producer is sending data; another producer is sending nav bar control
- Implications from one component should trickle out to the others
- Event handlers associated with arcs can modify data structure/presentation, make external calls, trigger new instantiation
- Constraints are propagated, essentially
- Event handling is essentially the first step, and then comes presentation
- MikeF - do we have to define statically who is listening for each event
Overview of service model
- Lifecycle,
- Service Desc.
- User Interaction
- Properties
- Custom
Assumed design point
- Pluggable Producers
- Standard Types for profile, device, markup
We should align at Lifecycle and User Interaction APIs
- Let's get some joint sub-committees together around these.
Orchestrated WSIA
- Came from a customer who wanted to use web mortgage without all of the annoying steps
Questions?
- Alejandro - played around with WSUI from Epicentric, and WSIA. WSIA seems to be dealing with the business logic within a fragment; they seem at different levels of abstraction
  - Charlie - WSIA is interaction logic, not business logic. It's interaction coupling.
  - Alejandro - could make WSRP as a WSIA model?
  - MikeF - they want to get more into the pieces of component

Carsten Leue of IBM's presentation

Present the basic ideas and concepts the led to this meeting
It is a good idea to have local portlets running on the same machine, but cooler to have remote portlets
Ideas & Goals
- Motivation is to enable the sharing of portlets (markup fragments) over the internet
- Nice to have a "visual component pool"
- Also would be neat to integrate into things like word processors
- Goals are to allow visual, user-facing, interactive components to be easily plugged into portals
- Should let anybody create and publish content & apps as user-facing web services
- Should be able to do this without any programming efforts
- Remote Portlets vs. data-oriented WS
  - Current WS's are mostly data oriented
  - In WSRP, presentation layer is remoted as well
- Sample Usage
  - SOAP layer between remote web services and presenter
  - Could have multiple client systems
- "Advertising"
  - Propose UDDI as central advertising
- Entities
  - Service (exposes WSRP interface)
  - Aggregation (client)
    - Consumes multiple WSRP services
    - Aggregates onto pages
  - Device (browser)
    - Displays aggregated markup to user (always)
    - Handles user input
- Instances
  - Same service may be accessed multiple times with different settings
  - The server must manage and identify each of these settings
  - Service & settings for a "remote instance"
  - Clients always integrate instances of WSRP services
  - Management of instance's settings can be negotiated between client & server
  - We and WSIA both need instancing; we should share/interop
- What needs to be defined?
  - Interfaces
    - Lifecycle management
    - Markup
    - Action processing
  - Protocol
    - Sequence of calls
    - How to make it user/device aware
    - Action and namespace encoding
  - UDDI configuration
    - How and what to publish?
- Traditional Usage Scenario
  - Local Portlet scenario
    - efficient (good),
    - local deployment, specific UI, business & presentation layer are on portal server, portlets cannot be shared (bad)
  - "traditional" web service model
    - Data separate from presentation (good)
    - Specific UI, etc. (bad)
  - WSRP
    - Remote connections unified, no coding required, stable/standardized transport mechanism, visual/user-facing (all good)

Questions
- Adam - I'm concerned about the visual nature of this. What about data being sent?
  - Carsten - we have been focused on sending visual components; you could still use a data based WS for the back end
  - Bob - you could also tell a portal about a data-based WS and a stylesheet
  - Jeff - there are uses for non-visual portlet (i.e. things put into shared memory)
    - Discussion of what "non-visual portlet" could mean
    - Let's table til we talk about scenarios
- Sasha - Should we talk about going out of the Web Services stack (i.e directly to backend)?
  - Ron/Carsten -- It's a possibility; let's talk about it

Lifecycle Management
- Service, binding, instance are persistent
- Session transient
- Instances are identified by handles which might be all the data or be a pointer into a map
  - Alejandro - handles are usually 64 bytes or whatever. Forcing the client to store arbitrary data in a handle is difficult
    - Carsten - we could limit it

State management
- An idea of the client storing the state that is sent back from the service and resending to service

Markup, Actions, & Persistence
- Markup retrieval
  - Send user info and data to service and responds with a markup response (with potentially more info)
  - Jeff - do you think that the service knows how to create different kinds of markup (HTML, WAP, etc.)?
    - Carsten - yeah
  - Bill - we shouldn't confuse this by mapping it on to actual software products; these are questions of level and deployment rather than protocol
- Action handling
  - URLs that the device has must in turn invoke WSRP on the backend
  - The service doesn't know how to write the URLs because it doesn't know who the aggregator is
  - The aggregator needs to rewrite URLs
  - MikeF - Are you implying that we want to do URL rewriting? The service could do the URL writing to begin with
- Namespace Encoding
  - Portlet can contain named entities that have to be called different things (i.e. forms names)
  - Aggregator must lift every named entity into a unique namespace or send it to service so that the service will do it

Alejandro - Have you that about aggregating several requests (for multiple portlets) in one HTTP request?
- Thomas/Carsten - we haven't done that, but it's a great idea

Break
Implementations
- Tomcat implementation and .NET implementation
  - Tomcat counter and .NET file browser
  - Actions invoked are sent back to WSRP
- ActiveX component which gets markup from portlet
  - Uses UDDI to find portlet, puts it into MS Word doc

Eilon Reshef of WebCollage's presentation

WebCollage
- Web Application Integration Platform
  - About turning standard Web application into reusable Interactive Web Services
- Focus on B2B scenarios
  - Travelers Checks, Boutiques, Configurators
  - "Application syndication"
- We want a way to make standard Web applications into portlets
American Express example
- Checking your account
- Can do lots of things, like "print out", "dispute transaction", etc.
Learned that Data APIs are not enough
- They are too difficult to integrate
- Rich applications, like commerce tools, SAP, Siebel, etc. have lots of steps and app logic
Data APIs especially inadequate for B2B
- Don't send ideas of brand, cross-sell, up-sell, and privacy
High level requirements
- We are interested in portlets that are multi-step processes
  - This allows for drag-and-drop, coarse grain, loose coupling, easy to integrate
  - We don't want portlet specific code on the portal
- Also interested in explicit adaptation points to fit in a portal
  - Lots of folks use screen scraping right now
  - Changing look & feel needs to be codified, as does data & flow
- Also interested in leveraging existing paradigms
  - Existing know-how, apps, & code base should be used.
WSIA Use Cases
Web Collage Integrated Web Services (IWS) process
- End user calls portal,
- which calls GetPresentation() of the portlet,
- Portlet sends back presentation
- Which portal integrates and sends back to user
WSIA/IWS Functionality Elements
- Definition
- Instantiation
- Navigation (URL rewriting)
- Adaptation
- State Management
- Data Export
Definition for IWS
- Portlet has standard WSDL interface, which can have multiple SOAP operations
- Some of the operations are interactive and have the same signature ("GetPresentation")
- 2 types of integration points
  - Navigation/presentation
  - Operation invocation
Instantiation
- Any SOAP operation can instantiate a Portlet
- Can start directly with "interactive" operation
- We do not yet have destruction
Navigation
- Mostly about URL rewriting
- Could be done by Portal, could be by portlet
- We have the Portal transfer a "controller" URL as part of the call
- Portlet responsible for rewriting relevant links because many (including JavaScript links) are difficult to find
Adaptation
- WSIA has been debating property-based vs. stream-based
  - Property-based: the portal sends property values as part of call, & portlet returns adapted output
  - Stream-based: Portlet defines locators into the output, and portal implements logic for manipulating. To happen robustly, you must have descriptors of content
- We have used property-based adaptation
  - We use a property schema
  - Property sheets can be stored persistently by Portlet or Portal, preferably at the portlet
State management
- We have transient state and persistent state
- Transient state is returned by portlet and resent on portal on every call
- Persistent state is returned by portlet and stored persistently by the portal and resent on every call
Data Export
- Any SOAP operation can return data, but must send state
- An example is Chanel being aggregated by Macy's and returning to Macy's what has been selected by the user
Points to get answers around
- Basic Model for "interactive components"
- What are the portal-specific requirements
  - Admin, user management, ...?
Looking forward to a standard
- Very strategic for WebCollage
- Don't really have technical prefs, they integrate into other folks' stuff
- Want to contribute knowledge and experience, and can show folks their implementation
Questions
- Charlie - how big is the case where you send 250 properties to portlet?
  - Eilon - we actually store the persistent props with the portlet

Alan Kropp of Epicentric's presentation

WSUI presentation is going to be similar to the presentation given at WSIA
Modular Web Services might also be applicable to what we're talking about
WSUI has been contributed to WSIA
- Was promoted as a standard in the past; now we look to use WSIA
- Will release it as a service pack to EFS 4.0
- Will continue to use it as a company, but will move forward to WSIA when ready
WSUI is about consuming web services into a visual form
- Didn't want to describe business logic
- Comes out of developing "modules" in their portal product
  - Module is interchangeable as a term with portlet
Business Drivers
- Current vendor solutions have been useful, but vendor specific
- 6 mos. To 1 year ago, there was no real way to try and display a Web service
- Current web service technologies are designed for a developer audience
- WSUI is designed to make it easier for business users to create a display
XML Web Services
- Standard Web service integration just by looking at descriptor is flexible, but requires custom development
Dozens of app delivery platforms, hundreds of app vendors, etc. make this painful
Modules support multiple views
- Front view is what is shown in the portal - allows you to see something
  - Can be all there is (like a weather gadget that just has temp)
- Results view can give you more info (like a search results)
- Edit view lets you change a preference (like city for weather)
- Admin view
WSUI is designed to create a multi-stage, interactive app without changing service interface
Timeline
- Epicentric Portlet API in early 99
- Modular Web Services protocol from mid 2000 was a SOAP based protocol to enable remote Portlets to plug into Epicentric portal platform part of EFS 3.0
- WSUI was a weekend project that became a consortium to build vendor-neutral WS display format
  - Resisted internal and external pressure to add features
  - Epicentric has the only implementation I know of
- WSIA late 2001
- WSRP early 2002
Why create it?
- Proprietary approaches increase costs for app vendors, publishing services
- Etc.
Real world scenarios
- Content syndication
- ASP apps - email, vertical apps
- App vendor provides a single Web Services based interface to its application
- Intra-enterprise application/content syndication
Travel Web Service Scenario
- Underlying Web Services: Available Flights, Flight View, Flight Booker, Airport Lookup, Airline Lookup, Calendar Data, etc.
Technical Discussion
- Supports the concept of multiple views (i.e. search box and results pages)
- "Components" are put into "container" pages
- Web service "component" has 4 aspects: Presentation, User Prefs, Service Data, app logic
- WSUI component has XML file that defines the component and an XSL for rendering component output
- XML component definition defines "events" (largely go from one view to the next)
- WSUI flow
- All form based for Request-Response
  - Post to a servlet which takes you from view to view
- MVC based
  - Java-based model & controller, & XSLT-based views
- Focus on multi-view interaction
  - More complex cases are important, in a stateful sense
- Transport-protocol compliant
  - SOAP
  - Looking at WSDL as main descriptor
    Plan to register WSUI as a service type
  - Released a .NET SDK for WSUI components
Can publish to UDDI directory
Benefits
- Single component display standard
- App vendors can use any language
- Not depending on client side things
Questions?
- Peter - Is there a migration path to WSIA/WSRP?
  - Alan -- We're trying to submit to WSIA and morph WSUI as WSIA is a standard so the changeover is easy
Modular Web Services
- We'll postpone until tomorrow due to tech issues

Bob Serr of Divine's presentation

Divine overview
- "Extended Enterprise Company"
  - four walls of enterprise are going to broaden
- Mission
  - Has PSO, software services, and managed services
  - Want to be able to break up the software into manageable pieces and deploy as web services
  - Want to leverage partnerships with portal vendors
- Content Agg, Collaboration, and Customer Interaction and Enterprise Content Management are the main types of software they want to manage
Portal strategy
- Acquired a portal company, but are no longer in the portal business
- Try to be the infrastructure that fits into people's portals
- Thus, pluggability is very important for folks
Example: divine Enterprise Content Center
- Provides "loads and loads" of content
- Acquire the content, normalize it, and present it
- Data comes from App Server, eCRM, EAI
- Brought together by infrastructure, displayed by portal, etc.
dECC will have lots of different sources (journals, faxes, reports, etc.)
divine will package up various portlets to sit side by side (for example, creating a page about energy)
- Allow users to make a query and have many portlets react (i.e. tell me about energy in this particular state)
Can track clicks so that they can track payment of content and ROI for customers
Personalization/Customization is important
Question Charlie - how do you get the portlets to talk to each other?
- Bob - depends on the portal implementation, some of them we're able to create a pseudo-event; sometimes it has to just be one portlet
dECC Integration
- Receive requests by SOAP - all the portals are the same right now
- We try to abstract integration of various portal vendors
- Customization mostly done through XSL
Large issue for us is authentication and authorization for content
- Both from tracking and a licensing/number of seats issue
- We've got to know when a portlet is instantiating
- Have to also know information about where users are
Apps will require multipage interaction
Have to store user prefs - this has already been talked about
Peter-there's a trust issue around what the portlet believes about the user
Case study
- Dynegy had a TIBCO portal that wasn't being used, and they bought dECC to augment their portal
Questions?
- Greg - are you worried about supporting multiple devices?
  - Bob - it's on the radar, but not there yet?
We've also talked about and need the ability to share instances of portlets
Questions?
- Adam - what were the painful parts of normalizing across portal vendors?
  - Bob - personalization was big. Synchronization of different portlets was a huge problem. We jumped through a lot of hoops.
  - Peter - Charlie's presentation showed a page that had dECC components that we did. We would like to also have the ability for third party components to tap into this.

Ron Daniel from Interwoven's presentation

What are we trying to solve?
- I want to look at the use case of managing content in portals
- Difficulty is the impedance mismatch between specialist content management functions and end user
Requirements we had when integrating with portals
- Users need to see tasks and respond to them (edit content or just approve)
- Surf & edit portal content
- Add, delete, edit content from CM portlet/gadget
- Tag content with metadata
- Merging of conflicting edits is an "anti-requirement"
  - We just want to lock folks out
- For ease of use, repository should look like file system
- Etc.
Architecture
- Workflow, specs, & active, forms, user/groups/roles, updated content
- Then a Content Services Server Stub
Suggested Interfaces
- File Management, Workflow, Collaboration, Data Entry
- Interfaces do not output UI, have differing WSDL
Few issues that came up
- Session management
  - Had to maintain state and track
  - Have startSession/endSession calls that take in roles etc.
- Role management
- Coarser grained APIs are better for performance
  - GetFilesInfo vs. GetFileInfo
  - Shouldn't block until the end of the message
- "Surf & Edit" is simple in concept, but a pain
  - Runtime and design time content are in different places
  - You have to have a linking between design and runtime files, so need to have markup that identifies that
- Layering
  - We should be careful to not add too many layers, but "we have layers" too
  - HTTP to SOAP/HTTP to SOAP/HTTP to RPC to file system is an issue
- State management
  - Two kinds: relatively trivial or huge
  - Your workspace needs to look the same, no matter what portlet you're on
  - Things like which branches are shown is not important to share
- Portlets are content too, they will have to go through testing, approval, etc.
Questions
- Charlie - what are the organization boundaries (what hops are going on?)
  - Ron - goes over the architectures
- So you're main interest in presenting to us is about user and role management?
  - Ron - there's also an issue of content management here.
- Jeff - CM system has large datasets. Do you think it is important for WSRP to address large datasets?
  - Ron - we want coarse grained operations, so we're going to have to learn to stream. It's something to consider.

Alejandro Abdelnur from Sun's presentation

Sun & IBM are leading the portal specification (JSR-168)
Several folks on the expert group; several folks in this meeting as well
JCP is controlled by Sun, and three things are required
- Specification
- Reference Implementation
- Compliance test suite
Licensing model usually decided by the leading companies
- For this JSR, ref imp & test suite will be free Apache projects
Schedule -- aggressive
- March - Expert Group meeting
- May/June - first draft, spec, and RI
- October - final draft, spec, and RI
- December - v.1.0 spec, RI, & TCK
Many disagreements in first meeting, but goals are
- Define a common portal metaphor - What is a Portal?
- Define a standard Portlet Java API
- Ensure interop and portability
- Enable multiple markups support - don't want to bind to one markup
- Maximize the leverage of existing Java APIs - don't want to reinvent the wheel
- Ensure compatibility with other technologies - particularly WSRP
  - We want to use WSRP to expand the power of the spec
Portal ref architecture
- Aggregation engine
- User configuration/personalization
- Portlet dispatcher
- Persistent Data Store
- Security
- Window configuration - for maximize/minimize
- Interfaces to define: portlet dispatcher –> portlet, persistent data store –>portlet, & window config –> portlet
Tech topics
- What is the relationship with the servlet container?
  - Should we extend or replicate?
- What window states (minimize/maximize, etc.) & portlet modes (edit, etc.) do we want?
  - We need to see if we can allow extensibility without breaking portability.
- Portlet requests & events
  - User action should be taken before being able to notification and then rendering at the end.
  - Lots of vendors use parallelization, which means we have to break this down and send notifications
- Packaging
  - Similar to WAR files, probably
- Caching
  - Should be able to effectively cache portlets that are not being used
  - Want to use something similar to HTTP caching
- Persistent configuration data
  - Same portlet may be configured in different ways for different users, or even different ways for the same user
- Security
  - Consensus that J2EE security model falls short
  - But doesn't make sense for us to define security model when it probably will be addressed in J2EE
- I18N & L10N
  - Much of this is addressed by servlet spec
  - All the controls around the portlet are provided by container
- Hot (re)deployment
  - Should be able to update without bouncing portal
- Parallel execution
- Aggregation
  - How things are laid out is outside the scope of spec
Remote execution
- Overlap with WSRP
- We are not going to require local or remote in the spec/API
- Is going to be very important to define lifecycle of request (events, notification, presentation may be problematic)
Questions?
- Peter - have you addressed ideas about display metadata (narrow, wide, etc.)?
  - Thomas - sounds like part of the metadata
  - Alejandro - we had a discussion about how much info the portal would have to give to portlet to let it know what to display
- Jeff - What did you mean by SSO like SAML?
  - Alejandro - implementation might use SAML
- Jeff - is caching associated with JSR-107?
  - Alejandro - we thought it was more complicated than JSR-107
  - Others - JSR-107 isn't really going anywhere right now
- Jeff - what about Hot (re)deployment?
  - Alejandro - we don't see that as being in our scope. It's a larger problem that will be solved forever when it's solved once. User profile information is in the same class.
- Greg - user profiles seem to be pretty important for portals, much more than EJBs. How could it work without user profiles?
  - Alejandro - we don't want to have to deprecate a portlet spec-specific user profile
- Jeff - is there an event model defined?
  - Alejandro - unresolved, but my take is that we will trigger events by using namespaces before rendering. My take is that it should not trigger remote portlet events.
  - MikeF - everyone agrees that events and event models need to be part of spec, but the schedule is super aggressive
- Jeff - we keep focusing on HTTP, but other things like JXTA (?) are coming. Should we be looking at those?
  - MikeF - in general, sure. But we're looking at now, and it's something that is cut for now.
  - Alejandro - we are writing on top of Servlet, so if those things change, we can hopefully take advantage of their experience. It could be that we have a different API (or a different JSR) for remote portlets, but right now we want to leave it open to both.
- Does the fact that getUserPrincipal is in Servlet mean that WSRP needs to send over UserPrincipal information?
  - MikeF - The WSRP to JSR API would be responsible for that.
  - Greg - do you plan to address WSRP in the spec explicitly
  - Alejandro & MikeF - no, it will hopefully be done through our intersection of membership
  - Greg - you might want to be explicit about it to ensure interop
  - MikeF - timing is an issue; WSRP is longer than portlet API

Break for the day

WSRP Meeting One Day Two

Going over Agenda (Thomas)

Several changes made to the agenda

Alan from Epicentric continuing presentation (Modular Web Services)

MWS is an older technology than WSUI
- In 3.0 version of product
- Allows a company (service provider) to host "remote modules"
People who wanted to run remote modules did not have to run EFS
Uses the MWS protocol
- All SOAP/XML based
Business logic is always located at provider's location
There is a restricted set of requests that pass from customer/remote provider
- There is a multi-view/multi-page interaction
- Presentation is done by the portal server
- Local XML descriptor on portal side
- MWS presentation is specific to a particular MWS (installed on client)
Proposed a registry called "Epicentric Web Service Marketplace"
- This was pre-UDDI
- Not shipped as a product
All based on descriptors (PBDs)
Remote access, with Java & ASP implementations
There are some request types (can deal with updating and moving of WS)
- View
- Module upgrade
- User upgrade
- Update Configuration Descriptor
Toolkits in Java & ASP
To create a MWS
- Create all the views
- Link the views (including custom views)
- Update remote service descriptor
Admin side
- They have a palette (local and remote portlets look exactly the same)
Questions?
- Adam - what other than SOAP could be used?
  - Alan - Not familiar with it
- Charlie - this is interesting; it's another way to separate MVC than what we've talked about.
- Eilon - the XML flow is relatively static, makes it difficult

Voting Members

Names I didn't get right yesterday - not a total list of voting members

Yossi Tamari, SAP Portals
Takao Mohri, Fujitsu
Madoka Misuoka, Fujitsu
Aditi Karandikar, France Telecom
Gino Filicetti, Bowstreet
Petr Palas, Moravia IT
Andreas Kuehne, Ind. Member
Mike Hillerman, Peoplesoft
Mark Rosenberg, TIBCO
Tim Granshaw, SAP Portals
Stephen A. White, SeeBeyond
Gregory Pavlik, HP
Adrian Fletcher, BEA
Brian Dirking, Stellent
David Taieb, Lotus
Adam Nolen, Lexis-Nexis
Jon Klein, Lexis-Nexis
Khurrem Mahmood, Peoplesoft

Membership for WSRP/WSIA joint committee

Volunteers
- Jeff Brobeck
- Mike Friedman
- Rich Thompson
- Angel Diaz
- Bob Serr
- Pete Quintas
- Adrian Fletcher
- Sasha Aickin
- Eilon Reshef
- Alan Kropp
- Carsten Leue
- Charlie Wiecha

Terms

Suggestion from Jeff - in WSIA, we pulled a glossary from another TC. Might make sense to share terms with WSIA
- Thomas - good idea, we should also look at the glossary in the Portlet API
- Jeff volunteers to help out
- Lothar - Alejandro, do you guys on JSR-168 have a glossary?
  - Alejandro - sure. We defined:
    - "fragment" - a piece of markup that is not part of a full document
      - part of aggregate
      - not binary, but not necessarily XML
      - generally a markup language
      - can aggregate a bunch of fragments
    - "portal page" - complete document rendered by a portal
    - "portlet window" -- portlet has a set of controls that decorate it
    - "portlet content" -- what the portlet renders without controls that decorate it (fragment that the portlet creates)
    - "portlet" - component that generates fragment
- Mark - I don't want portlet to be presentation component. It doesn't have to be on a page.
  - Sasha & Bob - why not just a Web Service or component?
- Alejandro - more defs
  - "window states" max, min, normal, detached
  - "portal modes" view, edit, help, config is under debate
  - "portlet container" environment where portlets run (lifecycle, security)
  - "portal application" - component that is the controlling application and is responsible for aggregating portlet content and displaying the portal page
  - "portlet application" - the equivalent of the WAR file
- MikeF -- personalization is important
- Alejandro - more defs
  - "portlet class" -- implementation of portlet as a Java class (compiled code)
  - "portlet object" - instance of portlet class (no defined portal state)
  - "portlet instance" -- portlet object with given user configuration; essentially the handle
  - "portlet window instance" - instantiation of a portlet on a page in a portlet window
- Sasha - there are lots of other types of state (admin, community, etc.)
  - MikeF - but you don't know where they came from
  - Sasha - you could
- Discussion about how Servlets associate with Portlets
- Thomas - what is the thing you select out of a list for your page?
  - Portlet Template?
  - Registered Portlet?
- Alejandro - User configuration data doesn't have a term.
  - "preferences"
- Thomas, etc. - how do we deal with the ways properties are keyed
- MikeF - we're not looking to specify levels; still better than current way things are set up
- Jeff - why would I implement this?
- Angel gets us back on track

Break

Susan Levine from Peoplesoft

Back to Terms

WSRP Service is not defined in the charter
- Visual, user-facing web services? Has problems with VXML
- Greg - "Presentation" is a better idea
- Thomas - "Interactive" should be added yes?
- Jeff - can we put "normally" in front of "presentation"?
- Adrian - you just need a "hidden"field.
- Alan - this could be done by intermediate steps, just not doing presentation
- Adrian - this also covers the case of "I only want to show up some times"
- Greg - embeddable/aggregatable is also important
WSRP Service - presentation oriented, interactive web services that can be aggregated by consuming applications
- WSRP services can be published, found, and bound in a standard manner, describing themselves with standardized metadata
- Bob - we're missing the notion of context from the portal
- Debate about whether we should actually use the word portal
Include user data, device information/locale information
Phone - what about republishing WSRP services
Change to "portals"? People say yes.

Discussion of Ref Implementation & TCK

Proposal to create open source reference implementation
- Would be available for free
- Proposal to put it into Jakarta
- Would need charter
  - Intended to be ref imp for WSRP, always updated to current level of WSRP specification
Greg - do we want a .NET RI? Would it be the only one?
MikeF - this doesn't seem like a RI; I would like to see a RI of JSR/WSRP bridge
Thomas - I would like to see an easy platform for creating portlets
- Isn't that an SDK?
Jeff - I don't want to tie JSR to this
- MikeF - yeah, but it would be weird to have two java apis for portlets in apache
Client would have to be a simple "show the info" client - same as conformance test?
Consensus - we do a simple "Hello World" implementation, but hold off on a marshalling layer
Big debate about whether we should implement a generic producer and/or sample producers
Who is interested?
- Jeff
- Carsten
- Peter
- Dave Clegg
- Mike F
- Adrian
- Bob
- Gil
- Greg
- Eilon
- Rich Thompson (added on day 3)
Open question: Jarkarta (Java specific) or Apache-XML ?
- Deferred to later.

Business Scenarios

Mark
- What makes a portal successful is content. There are lots of content providers that portals want to consume
Jeff
- Concerned with consumer; how things get aggregated. Want to make it easier for devs
Alan
- Committed to the idea of portlets/modules. There is a certain limitation to the services in a portal. This a way of opening up the gates, allowing for more content locally & remotely
Petr
- Standards to support deployment, visible and invisible, provide services composed by other portals
Greg
- Development, deployment, & provisioning across multiple businesses and bus. Domains
Bob
- I'm a portal admin. Through my admin tool, I can browse remote portlets, provision them into my portal, specify what users and groups have security. Portlets will be automatically available, be able to instantiate on page. Establish identity and do access control in the portlet.
Peter
- Allowing for consumers of application to use all the things we use today (portlets to communicate with each other). Hosted environment; multi-tenant WSRP apps
Carsten
- Aggregating content from the Internet
- Ability to aggregate portlet from one location in many portals to decrease maintenance cost
Charlie
- Ability to change the flow of application
- Have a model of what the
Lothar
Aditi
- Looking to go from provider to intermediary
- Provide services to mobile users
- Application syndication
- Incorporate remote services in gadgets
- Mobility scenario
Eilon
- Allowing companies to integrate web applications
MikeF
- We have to keep existing functions and add extra functionality (extensibility, ...
- Interested in fast aggregator
Nigel
- Content Provider: access control of content; passing through auth info
- If interaction of portlets is here, that's important too
Gino
- Interested on the consumer side of the protocol; dynamic assembly & consumption, cohesion of presentation
Adam
- Want to make money without support getting calls when we integrate with a portal
- Security:
  - end user can't get content they haven't paid for
  - shouldn't show portlet to user who doesn't have security
  - enterprise as well as user level customization
- Caching refreshes specified
- Needs to be hidden or on visual support
- Needs to be trust relationship standardized
- Ability to figure out who end user of service is
Alejandro
- Having several portals developed and not having to go and configure every one with portlets
Sybase
- Would like to have a standard so that we make the market more robust/mature
- Big opportunity for
Madoka
- Application to inside enterprise
  - Many services, very important to integrate low cost,
  - customization is important
- Extend to mobile area
  - Very important in Japan
Takao
- Mobile environment
- Generic proxy
Yossi
- Federated portal is very important
- Not all instances are from the same vendor
- Would like to see that as a standard
- Workset - group of portlets that together form an application
DavidT
- Creating translation services
- Plug those services into portal like content management system to provide localization services
- Plug and play modules
- Caching technology is going to be very important
- Producer allowed to send back language info (bi-di, etc.)
TIBCO
- As portal vendor, increase value to end user with services out of the box
- We want to wrap our EAI and give user facing experience, allowing to be used in other portals
Oracle Integration
- ERP products; we need to get security info
- Launch out
Brian
- ConMan/ConInt, we've got integration with tons of portal products
- Offer between 15-40 actions
  - Content gets checked in, checked out, etc.
- Have a lot of difficulty putting on many platforms (WebSphere vs. WebLogic)
- Wireless is important
- Starting to expose over web services (like translating Word doc to HTML)
- Security / SSO is a big issue
- User synchronization
We will discuss business scenarios on first con calls

Pub / Find Bind & Metadata

Discussions about whether or not this is a good thing to do f2f
Proposed Metadata
- Name
- Markup types supported (how to specify what is in the markup)
- Natural languages
- Description
- Default Portlet Params
- List of properties
Jeff & MikeF - Discussion of whether admin props should be enumerated in description and auto-generate UI or have the portlet UI created
Sasha - Name might not make sense, might be something you have to ask the portlet.
Discussion of roles and role mapping
- What is the trust relationship?
More metadata
- Sizing, placement, Supported Window States
- Icon
- Notifying what sorts of events we generate & listen for
- Allowed Caching / Timeout
- Cookies that the portlet is going to send to portal?
- Version number (of the codebase?) / WSRP version number
  - Alejandro - portlet version number and WSRP version number
- Client support (may already be in UDDI)
- Author, publisher, etc
- Browser constraints
- Information about "portlet group"
- View types supported
- P3P Information (privacy)
- Categorization
- Charging info (pricing model)
- Security Policies ("I may only be contacted via secure channel")
- Public/private caching
MikeF - you often want to go directly against a SOAP service and don't need to put things in a registry

Invocation Protocols

Calls
- CreateInstance
- GetMarkup
- PerformAction
- DestroyInstance
Question from MikeF - what's the diff between action and event?
- Long discussion around what the event/action/markup calls are from an API perspective...
More calls
- PropagateEvent
- ProcessMessage
- GetMetadata(Schema)
- Get/SetConfigProperties on instance
- Bind/UnbindPortal
  - Happens when portlets are registered and deleted from portal
Dave: We should see if we could make stateless and stateful versions of portlet API
Discussion about sessions
- Should we make sessions explicitly, or just implicitly
- MikeF - we might want to make it explicit so that sessions can be shared
CreateInstance is actually persistent, happens when user adds to his or her page