[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp][all] WSRP Bi-Weekly Phone Call April, 18th
Dear WSRP TC Members, here is the Agenda for the WSRP TC Call today 9 am PST / 12 pm EST / 6 pm CET. Attached, you find the relevant documents. Accept Minutes from the last Call --------------------------------- Duration: < 5 min (see wsrp-minutes-2002-04-04.html attachment) (See attached file: wsrp-minutes-2002-04-04.html) Bob, thank you for the accurate minutes ! Monthly Sub-Group Reporting --------------------------- Duration: 25 min Common Interfaces (Alan) 5 min Interfaces & Protocol (Mike) 5 min (See attached file: InterfacesAndProtocolsStatus-April.htm)(See attached file: InterfacesAndProtocolsStatus-April.doc) Pub / Find / Bind / Metadata (Mike) 5 min (See attached file: PublishFindBind&MetadataReport-April.htm)(See attached file: PublishFindBind&MetadataReport-April.doc) Markup Fragments & Styles (Gino) 5 min (See attached file: MarkupFragment-MonthlyReport-April.htm)(See attached file: MarkupFragment-MonthlyReport-April.doc) Security, Identity & SSO (Mark) 5 min (See attached file: wsrp-security-April.htm) Monthly report templates see MonthlyReportTemplate.* attachements below: (See attached file: MonthlyReportTemplate.pdf)(See attached file: MonthlyReportTemplate.htm)(See attached file: MonthlyReportTemplate.doc) Business Scenarios ------------------ Duration: 20 min In the last call we agreed that the scenarios will be posted to the mailing list by 4/15/2002 ([wsrp][all]) I propose that we review scenarios in the order of posting, i.e. we start with - Content for Portals (Carsten) 10 min (see WSIASCenarioWebServicesForRemotePortals.htm and .doc) (See attached file: WSIAScenarioWebServicesForRemotePortals.htm)(See attached file: WSIAScenarioWebServicesForRemotePortals.DOC) - Portals sharing Portlets (Carsten) 10 min (see Portals sharing Portlets.htm and .doc) (See attached file: Portals sharing Portlets.htm)(See attached file: Portals sharing Portlets.DOC) In the next call, we can then review the remaining scenarios. Comments on WSRP Overview Presentation -------------------------------------- Duration: 5 min (see WSRP Overview.ppt) (See attached file: WSRP Overview.ppt) Conference call details: In the US: 877-302-8255 Outside US: +1 303-928-2609 When you dial in you will be asked for a "conference id". The conference id is: 8814427 Best regards, ThomasTitle: OASIS WSRP
OASIS WSRP Technical Committee Teleconference Minutes Attendance at roll call,
Duration Chair Thomas Agenda - Approve Minutes - Hosting F2F Meeting - Revised Charter - WSRP Directory - WSRP Scenarios - Misc Items Meeting -
People have commented, Sasha will
update minutes. Thomas proposed that minutes are
updated by next Monday; 2 more days for comments, then we post them. Question: Do we post sub-group
minutes on the web site. Answer: Yes, but we need to
organize it intuitively. Leaders should
send minutes to Lothar and he will post them. -
HP ( -
HP is part of both WSIA and WSRP; it might make sense to
have HP host it next since we wanted to host them back-to-back -
Mike: Oracle has a logistical problem in that nobody from
Oracle will be at the first 2 days (since they are not on WSIA). -
The last meeting was on the east coast. -
Decision: we do the meeting on the west coast. -
There is an OMG workshop in -
Mike will need a confirmation to reserve dates and
attendance at the conference center. -
no
comments; Thomas will publish to the website -
Jeff has
received no feedback from the joint committees.
As soon as he receives feedback he will post an update -
Send additions,
changes, deletions: send them to wsrp and wsia mailing lists.
Jeff will reflect the changes into the document -
Draft in
10 days (4/15 – 2-3 days before next meeting) -
6 people
volunteered to write scenarios: o
Syndicated
content – Bob Serr o
o
Publishers
Portal – Karl o
Current
Awareness – Adam Noland o
Corporate
/ WSRP Services – Tim Granshaw o
Multimedia
– Aditi o
Mortgage
Calculator – Alan Knopf -
Template
was sent around to document business scenarios; it is the same as the one used
in the WSIA group -
Document
comments: put a tag around the comment, such as a
<name>Comment</name>. This
way we can identify the comments when formatting is lost. -
Can we
share through a repository documents so we don’t have to continue sending
attachments through emails? Lothar will
look into this (again we don’t want to cloud the website and we don’t want the
public to see these docs yet). -
Oasis
hopefully will have something to support this in their infrastructure. -
Apache
has CVS; Oasis needs something like this (hopefully they have it). -
Subcommittee
Reporting: We will start this in 2 weeks.
Thomas would like to do it verbally in the meeting in addition to in
written form. The written form would be
sent before the meeting so people will be briefed prior to the meeting. -
Mike:
would like to articulate sub-committee milestones in the status, but will use
the summaries for detail. -
Lothar
will send a template for subcommittee reporting. -
Thomas:
gave a presentation at Java One about Java and Portlets,
roughly 1000 people attended. He
mentioned WSRP and received a lot of interest. -
Jeff:
Can we have a short briefing of what the subcommittees are and the schedule of
the calls? Thomas will do this. |
Interfaces and Protocols Monthly Report Report for
month of: April Group
Lead:Michael Freedman Activities Finished: Defined
role and purpose: this subcommittee will develop the requirements that
will be used to define the API for the lifecycle and basic operations of
portlets. Basic
terminolgy: defined portlet service, portlet template, portlet instance,
personalization data, and template settings Described
basic Portlet usage scenario: describes how a portal may interact with the
entities defined by the above terms Identified
90% of the core set of interactions/operations we want to focus on defining
requirements for version 1.0 of the spec. Activities in Progress: Need
to finish the discussion of what operations should be discussed as part of the
core set. Need
to identify questions to resolve/requirements for operations in the core set. Current
ongoing discussion threads include: management
of personalization data. Is it managed by the portal or the portlet? actions
and events. What are actions? What are events? Are they valuable
enough to include in the first version of the spec? terminology.
There is still ongoing discussions designed to clarify and tighten the terms
defined above. New Activities: Need
to idenitfy additional discussion topics that are pertinent but not included in
operational set. For example: form of SOAP message we will use. Defining
the requirements for the operations identified above. |
Attachment:
InterfacesAndProtocolsStatus-April.doc
Description: Binary data
Publish, Find, Bind, and Meta Data Monthly Report Report for
month of: April Group
Lead: Michael Freedman Activities Finished: Activities in Progress: Getting
ourselves organized: We have decided the Bind/Meta Data definition is a
higher priority then Publish/Find. We have decided that UDDI will only be
one possible mechanism for Find, hence Bind operation must be defined on the
portlet itself. In general we are going to try and answer the follow: What
actions should a portal application be able to take based on the published
metadata about a WSRP service? Metadata requirements should directly fall out
of this. Which
metadata is required? Which is optional? Will
we support an extension mechanism to allow vendors to include custom
metadata? Example scenario? Specific
details: Publish:
no discussion yet Find:
there is ongoing discussion concerning identifying/defining the tModel UDDI key
in public/private UDDI servers. Bind:
no specific discussion though the topic is also on the radar of the interfaces
and protocols group MetaData:
no specific discussion over and above the initial list we put together at the
offsite New Activities: Put
together a discussion document that lists the questions needing discussion. Continue
e-mail discussions. |
Attachment:
PublishFindBind&MetadataReport-April.doc
Description: Binary data
Markup and Styles Sub-group Monthly ReportReport for month of: April 2002 Group Lead: Gino Filicetti Activities Finished:
Activities in Progress:
New Activities:
|
Attachment:
MarkupFragment-MonthlyReport-April.doc
Description: Binary data
WSRP – Security Group Monthly ReportReport for month of:___April_______________________ Group Lead:________Mark Cassidy_________________________ Activities Finished:1. defined areas of focus for the group: - portal identity, trust relationship between
portal and portlet - end user identity,
profile, and credentials - secure transmission
of data 2. Identified security-related
standards efforts we will aim to leverage/be compatible with: - XML Signature(W3C/IETF) - XML Encryption(W3C) - SAML(OASIS) Activities in Progress:1. Usage scenarios around the above topics 2. Drilldown on requirements for each topic area New Activities:1. Begin formal requirements document |
Attachment:
MonthlyReportTemplate.pdf
Description: Binary data
<Expert Group Name> Monthly ReportReport for month of:__________________________ Group Lead:_________________________________ Activities Finished: Activities in Progress: New Activities: |
Attachment:
MonthlyReportTemplate.doc
Description: Binary data
WSRP Business Scenario Business Scenario: Content for Portals Version 1.1 Revision History
Table of Contents 1. Web
Services for Remote Portals 1 1.1 Description 1 2. Participants 1 2.1 ContentForPortlets
Inc 1 2.1.1 Role 1 2.1.2 Relationships 1 2.1.3 Business Objectives 1 2.1.4 Solution Requirements 1 2.2 WESEREPOCON 2 2.2.1 Role 2 2.2.2 Relationships 2 2.2.3 Business Objectives 2 2.2.4 Solution Requirements 2 2.3 End-User 3 2.3.1 Role 3 2.3.2 Relationships 3 3. References 3 Business Scenario: Content for Portals 1. Web Services for Remote Portals1.1 DescriptionContentForPortals.com is a provider of visual, user-facing web services that plug-and-play with portals. ContentForPortals.com provides several visual, user-facing web services including functions like weather forecasts, stock quotes, news, sports results, airport flight schedules, etc. This scenario describes the kind of business relationships that will become possible with the introduction of the Web Services for Remote Potals (WSRP) standard. The subject scenario pertains to the proliferation of visual, user-facing web services that can be integrated and aggregated by portals in order to redistribute them to the users of those portals. This document will focus specifically on the consumption of visual, user-facing web services by portal servers. 2. Participants2.1 ContentForPortlets Inc2.1.1 RoleContentForPortlets.com offers a variety of visual, user-facing web services including functions like weather forecasts, stock quotes, news, sports results, airport flight schedules, etc. 2.1.2 RelationshipsContentForPortlets.com offers their content to companies running portal servers either within corporations or on the Internet. Customers who want to use ContentForPortlets.com’s visual, user-facing web services to add value to their portals select the desired services and bind to them to make them available to the users of their respective portals. In the subject situation, a big corporation known as WESEREPOCON wants to make some of visual, user-facing web services provided by ContentForPortlets.com available for their corporate users. 2.1.3 Business ObjectivesContentForPortlets.com wants to make their services available in a form so that portals across the world can find their services and bind to them with minimal effort so that the hurdle of using and buying their services is low. 2.1.4 Solution Requirements§ Effective Publication: Allow ContentForPortlets.com to publish their services to a directory where all portals can find them easily. § Easy Integration: Allow portal administrators to find and bind to the visual, user facing web services of ContentForPortlets.com or similar providers with just a few mouse-clicks in their portal server’s administration UI. § Caching: Appropriate caching must be used at client portals to optimize response times for the end users and avoid excessive load on the services provided by ContentForPortlets.com. 2.1.4.1 Technology Requirements§ Standard Directory Infrastructure. A central directory, accessible in a standardized manner for publication and finding of services must exist. § Standard, pluggable Invocation Interfaces and Protocols.. 2.1.4.2 FunctionalityHere are the main functionality use cases that are required in this scenario: § Development and Publication o Develop visual, user-facing web services and generate meta data describing them o Publish visual, user-facing web services to a directory that can be accessed by many portals, along with metadata describing them 2.1.4.3 UsabilityOwnership of Usability issue resides with the StockPlot client. 2.1.4.4 ConstraintsNon-modifiable fields TBD. 2.2 WESEREPOCON2.2.1 RoleWESEREPOCON runs a corporate portal for their employees. They develop and run custom portlets for business tasks specific to their corporation on their portal platform as well as personal information management portlets. In addition to these local portlets, they want to make external content available to their employees, including airport schedule information and the current stock quote for their company. 2.2.2 RelationshipsWESEREPOCON licenses the desired content from ContentForPortals.com for use in their portal. 2.2.3 Business ObjectivesWESEREPOCON wants to make relevant external information (flight schedules, current stock quote of WESEREPOCON, local news) available to their employees by just plugging it into their portal, without wasting any time for integration or even programming effort for special portlets to visualize the information. 2.2.4 Solution Requirements§ Easy Integration: Allow WESEREPOCON portal administrators to find and bind to visual, user facing web services of many providers with just a few mouse-clicks in their portal server’s administration UI. § Caching: Appropriate caching must be used to optimize response times for the users of WESEREPOCON’s portal. 2.2.4.1 Technology Requirements§ Standard Directory Infrastructure. A central directory, accessible in a standardized manner for publication and finding of services must exist. § Standard, pluggable Invocation Interfaces and Protocols.. 2.2.4.2 FunctionalityHere are the main functionality use cases that are required in this scenario: § Finding and Binding o Find suitable visual, user-facing web services in a directory using appropriate portal admin UIs o Automatically integrate them into the portal as portlets (e.g. through portlet proxies) o Allow portal users to select portlet proxies representing visual, user-facing web service like local portlets § Run-Time Invocation o Invoke visual, user facing web services as appropriate 2.3 End-User2.3.1 RoleAs the final endpoint and actual Consumer of the ContentForPortlet’s visual, user-facing web services, the end-user represents the actual human user of the airport flight schedule and stock quote services. In this case they are users of WESEREPOCON’s portal. 2.3.2 RelationshipsThe end-user performs the actual interaction with the various visual, user-facing web services and is the ultimate trigger of all Run-Time use-cases associated with this business scenario. 3. References |
Attachment:
WSIAScenarioWebServicesForRemotePortals.DOC
Description: Binary data
Business Scenario Document Information Sharing between Portal Servers Version 1.1 Revision History
Table of Contents 1. Web
Services for Remote Portals 1 1.1 Description 1 2. Participants 1 2.1.1 CentralPortalServer 1 2.1.2 Role 1 2.1.3 Relationships 1 2.1.4 Business Objectives 1 2.1.5 Solution Requirements 1 2.2 Client
Portal 3 2.2.1 Role 3 2.2.2 Relationships 3 2.2.3 Business Objectives 3 2.2.4 Solution Requirements 3 Information Sharing between Portal Servers 1. Web Services for Remote Portals1.1 DescriptionLargeCompany is an enterprise that operates worldwide. It manages its internal information and services (e.g. backend access to legacy time management system) using portal servers. There exist several portal server clusters within the company at different locations. LargeCompany would like to make it possible to share content between multiple portal server installations with a minimum of maintenance and administration effort. The services to share are visual, user-facing and should integrate seamlessly into each portal in which they appear. In the current scenario LargeCompany would like to share a portlet that displays the company’s current stock price and a “tip-of-the-day” message with all other company portals. The visual design and content of this portlet are to be managed centrally. The layout of the portlet may change frequently which means changes in either the portlet’s code or in the JSPs which render the portlet’s content. It is important that such modifications are immediately visible on all client portals. For security reasons there must not be the need to install code on the consuming portal servers. The subject scenario pertains to visual, user-facing web services that enable portals to share content with each other. This approach is not limited to sharing content between portal servers of the same type but only requires that the portals export their portlets adhering to the WSRP interface. This document will focus specifically on the exchange of visual, user-facing web services by portal servers. 2. Participants2.1.1 CentralPortalServer2.1.2 RoleThe CentralPortalServer is a portal server that hosts the local TipOfTheDay portlet. It provides not only access to data stored on the server but also implements the visual design of the portlet. This visual design may change on a per-day basis. 2.1.3 RelationshipsCentralPortalServer exposes the TipOfTheDay as a WSRP service and publishes it in the corporate’s private UDDI directory. 2.1.4 Business ObjectivesCentralPortalServer wants to share TipOfTheDay information with all the company’s end users regardless which local portal server they are using. The effort to integrate the portlet into each portal server should be as simple as possible. As the portlet’s visual content often changes it should be managed centrally without any further interaction. 2.1.5 Solution Requirements§ Easy Integration: Allow local portal administrators to find and bind to the TipOfTheDay portlet with just a few mouse-clicks in their portal server’s administration UI. § Caching: Appropriate caching must be used at client portals to optimize response times for the end users and avoid excessive load on the CentralPortalServer. § Remote Access: Allow portals all over the company to access the presentation markup of the TipOfTheDay portlet via the intranet. § Request parameters: The user may enter data in input fields of the TipOfTheDay. These parameters must be transferred to the CentralPortalServer for processing. § User data: To personalize the content of the portlet the client may send parts of its user profile to the remote portlet. § Markup type: Portal users may connect to their local portal using a variety of different devices (browser, PDA, phone, etc). The content of the remote TipOfTheDayPortlet must take this into account and render its content depending on the requested markup type. § Language: LargeCompany is spread all over the world. Users want to connect to their local portals and get information in their preferred language. This is also true for the remote TipOfTheDayPortlet which must either be able to render its content in the requested language or to provide markup in a default language. 2.1.5.1 Technology Requirements§ Standard Directory Infrastructure. A central directory, accessible in a standardized manner for publication and finding of services must exist. § Standard, pluggable Invocation Interfaces and Protocols. This is key for an architecture in which remote content can be plugged into an existing portal without installing, writing, or modifying code. Because the interfaces are the same for all possible portlets, clients can use a generic local proxy to connect to the remote service. § Transfer of user data and preferences: The user of the local portlet may request different markup types and/or languages depending on his location and device. This information must be transmitted to the remote portlet with each request. § Binding: Prior to accessing the TipOfTheDay portlet remotely client portal servers must authenticate themselves to make sure that the portlet is only shared within LargeCompany. This step is required only once per portal by establishing a persistent binding between the two. § Persistent instances: Each user may integrate the remote portlet on a page in his portal server and configure personally. Such a configuration must be persistent both on the client and on the server side. If the user deletes the portlet locally the configuration information on the remote side may be deleted as well. This implies the need for life cycle management of portlet instances between the local and the remote server. 2.1.5.2 FunctionalityHere are the main functionality use cases that are required in this scenario: § Development and Publication o Develop an inspiring TipOfTheDay portlet with useful up-to-date information. o Publish this portlet to a directory that can be accessed by all portals belonging to the company, along with metadata describing the portlet’s configuration properties. 2.1.5.3 Usability2.1.5.4 Constraints 2.2 Client Portal2.2.1 RoleLargeCompany has portal servers throughout the world at many different locations. However there exists content that is of interest to the whole company and should be made available to all employees (e.g. the TipOfTheDay portlet). The client portal’s administrator would like to make this portlet available to his users without making them notice that it comes from a remote server. 2.2.2 RelationshipsAdministrators for client portals locate the remote TipOfTheDay portlet in a UDDI directory and import it into their portal server. Users of the client portal can integrate the imported portlet into their pages and view markup rendered by the CentralPortalServer. 2.2.3 Business ObjectivesAllow information consumption from a central point across portal boundaries. In particular modifications of the TipOfTheDay portlet must not impose management costs on the client portal’s administrator. The remote portlet should look exactly like any other portlet on the server (remote or local) and can be placed onto portal pages by users. Once the administrator has imported the remote portlet, no further action by the administrator is required to keep the portlet up-to-date. 2.2.4 Solution Requirements§ Easy Integration: Allow the client portal administrators to find and bind to visual, user facing web services of other portal servers with just a few mouse-clicks in their portal server’s administration UI. § Caching: Appropriate caching must be used to optimize response times for the users of the client portal. 2.2.4.1 Technology Requirements§ Standard Directory Infrastructure. A central directory, accessible in a standardized manner for publication and finding of services must exist. § Standard, pluggable Invocation Interfaces and Protocols.. 2.2.4.2 FunctionalityHere are the main functionality use cases that are required in this scenario: § Finding and Binding o Find suitable remote portlets in a directory using appropriate portal admin UIs o Automatically integrate them into the portal as portlets (e.g. through portlet proxies) o Allow portal users to select portlet proxies representing remote portlets as local portlets § Run-Time Invocation o Invoke remote portlets as appropriate |
Attachment:
Portals sharing Portlets.DOC
Description: Binary data
Attachment:
WSRP Overview.ppt
Description: Binary data
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC