|
PURPOSE
The aims of the WSRP TC shall be as follows:
- Create an XML and web services standard that will allow for the
plug-n-play of: portals, other intermediary web applications that aggregate
content, and applications from disparate sources. These so-called Web
Services for Remote Portals will be designed to enable businesses to
provide content or applications in a form that does not require any manual
content or application-specific adaptation by consuming applications.
- Work closely with the OASIS WSIA technical committee to ensure reuse and
compatibility where possible, define common base interfaces in a joined
subcommittee.
- To harmonize WSRP as far as practical with existing web application
programming models (e.g. Portals/Portlets, WSIA, ...), with the work of the
W3C (e.g. XForms, DOM, XML Events, XPath, XLink, XML Component API task
force), emerging web services standards (e.g. SOAP, WSDL, WSFL, UDDI) and
with the work of other appropriate business information bodies.
- Ultimately, to promote WSRP to the status of an international standard
for the conduct of XML and Web Services based web application development,
deployment and management.
DELIVERABLES
WSRP services are presentation oriented, interactive web services that can
be aggregated by portals.
WSRP services can be published, found and bound to in a standard manner,
describing themselves through standardized metadata.
WSRP services have access to context information of portals including
- User data
- Device information / locale information
(Remark: Some WSRP services might not (always) output markup but just
participate lifecycle)
The primary deliverable of the WSRP TC is specification that consists of a
coordinated set of Web Services interfaces and technical contracts that
will allow businesses to:
- Implement WSRP services according to the spec to that they are
interoperable with compliant consuming applications, e.g. portals.
- Publish WSRP services into directories with meta-information that
indicates their capabilities
- Implement consuming applications according to the spec so that they
are interoperable with compliant WSRP services.
- Find WSRP services in UDDI directories and exploit the associated
meta-information to determine their capabilities.
As examples, the WSRP spec ...
- ... will permit Portals to consume WSRP services by using
generic Portlet Proxies to allow to dynamically plug in
any WSRP services without programming effort.
- ... will permit portals to publish local portlets as WSRP services
- ... will permit implementation of WSRP services on any Web
services-capable platform, e.g. J2EE or .NET.
- ... will provide enough information to producing services so that
they for example could do metering / billing / ...
- ... will be designed for good performance
As currently envisioned, the WSRP work will take place in five phases:
- A first phase to gather requirements across portal vendors, service
providers, system integrators, and portal deployers.
- Produce an initial draft for the WSRP specification for review by the
members
- Produce an initial specification for WSRP that can be reviewed and
commented on by the public and provide an SDK.
- Finalize the first version of the specification and update the SDK to
reflect any changes and create a CTK.
- Define a set of design patterns to guide WSRP developers in creating
re-useable application components. In addition the TC will encourage
implementations, test suites and interoperability guidelines.
If the work actually does take place in this form, then it is estimated
that the first, second, third, and fourth will take roughly one year to
complete and that the fifth phase will take roughly one year.
If phases can be combined or run in parallel, then it is estimated that
delivery of an initial set of specifications will take one to two years.
LANGUAGE
The TC shall conduct its proceedings in English.
|
