Sun and Oracle Community Voices How to Buy Log In United States [Change] English

»  Spotlight Articles
»  Projects
»  Publications
»  People
»  Awards
»  Events
»  Downloads
»  Internships
»  Contrarian Minds
»  About Sun Labs
Webwork Report - Options

Webwork
An Application Portal Vision


[ Summary | Introduction | Users | Features | Technologies | Options | Appendix ]

Options for Realizing the Webwork Vision

Our vision of application portal computing creates a compelling user experience that will attract users to this new model of computing. Current application portal efforts that offer only easy administration miss the opportunity to leverage the potential for collaboration and to integrate context among the data and applications that people use. Rather than work being done in isolation, the Webwork Portal model supports work in the context of associated people, related documents, and prior work. Webwork Portal presents an interpersonal computing user experience.

Sun has an opportunity to capitalize on the strong industry interest in application portal computing to deliver an innovative desktop experience. Developing Webwork Portal would enable Sun to provide true end-to-end solutions for our customers while continuing to generate strong demand for Sun servers. Providing an innovative user experience would not only gain industry recognition for Sun, but would also help convince consumers to migrate from stand-alone applications to portal-based ones.

In order to realize the Webwork Portal vision outlined in this report, there are a variety of roles that Sun can play. Below we outline three possible options to serve as the starting point for discussion about the appropriate role for Sun.

Option 1: Define Specifications

    To implement the Webwork Portal vision a set of API specifications must be defined to capture the awareness information and enable the interactions among the applications. A sampling of what the APIs would cover includes:
    • Work context
      • Activity capture and recording
      • Inter-application information and invocation
    • Synchronous collaboration
      • Realtime activity awareness
      • Application sharing
      • Transaction serialization
      • Fine-grain locking
      • User interface toolkit
      • Controlling access to shared data
    • Asynchronous collaboration
      • Document locking
      • Handles
    • Remote application hosting
      • Transactional data modification
      • Remote display
    • Data Storage
      • Data interchange formats
      • Versioning
      • Transaction logging
    • Security and access control
    • Disconnected device synchronization

    In this first option, Sun would coordinate and define API specifications, leaving it to third parties to build the actual production implementations. As with other API efforts, Sun would probably have to provide implementations of the core capabilities and some demonstration applications to convince third parties of the viability of the APIs.

    Option 2: Sell Infrastructure Product

    In addition to defining the APIs, this option entails:

    • Implementing all APIs
    • Providing a core set of applications
    • Providing an API for adding new applications
    • Building an administration infrastructure, including:
      • User management
      • Data archiving and document retrieval
      • Availability monitoring
      • Tools for customer support
      • Tools for billing

    The customer for this product would be application service providers. The ASPs would brand, tailor, offer, manage, and maintain the service for end users. Out of the box, an ASP could install the software on their servers, add their own logo, and run a Webwork portal service. More ambitious ASPs might want to tailor the service by adding their own applications or enhancements to the core feature set. If provided in conjunction with Sun Rays, this option would provide an end-to-end intranet application portal solution for enterprises.

    Option 3: Become a Service Provider

    The next step beyond Options 1 and 2 is for Sun to become an application service provider and offer the Webwork portal directly to end users. In addition to the work described in Options 1 and 2 above, this would involve:

       
    • Setting up (or contracting for) an organization to run the service
    • System maintenance
    • 7 x 24 customer support
    • Billing
    • Etc.

These three options represent major points on a spectrum of possible approaches. They are intended as a springboard for discussion.

Next Steps

This report marks the completion of the mission of the Webwork Study Group. To pursue the concepts presented in this report, management will need to formulate a plan to provide resources for next steps.

The work needed to realize the Webwork vision requires:

     
  • Marketing
    To make a better informed decision about the best approach for Sun, marketing research can help to determine the size of the ASP market and the reception that another set of APIs would have in the industry. Marketing involvement will also be essential in developing an effective business model for application portal computing for Sun.

     

  • Engineering
    Many of the ideas in the Webwork vision are extensions of technologies that already exist. Work could begin immediately on many of the individual components ranging from creating a complete user interface specification to defining many of the APIs. In addition, if Sun intends to reuse the Star applications for an application portal, those applications will need substantial enhancements to support the collaboration features described in this report.

     

  • Research
    Some of the ideas in the Webwork report are untried and untested. Sun Labs can play a role in prototyping various aspects of the Webwork core ideas to confirm their viability, utility, and usability. The Network Communities group in Sun Labs is already committed to prototyping pieces of the Webwork Neighborhood, particularly those components related to the Contact and People Neighborhoods. There are other areas, however, that should be prototyped and tested before proceeding to product development. These include:
       
    • Application Sharing API
      Although various schemes exist for application sharing, realizing the Webwork vision depends on having an application sharing API that is both powerful enough to support the functionality described, but also simple enough that application developers will be willing to implement it, even if they are only building a small application.

       

    • Activity Capture Architecture
      Capturing the user’s activity in order to report activity in the Contact Neighborhood and maintain a meaningful History Neighborhood requires that all devices associated with the portal report activity via some standard interface. The activity information then must be analyzed to determine the difference between context-switching activities and secondary activities. None of these functions is standard in today’s operating systems, so trying out various approaches will likely be necessary.

       

    • Security/Access Control
      Research is needed to determine if current security and access control technology is adequate to support the Webwork concepts. In Webwork, there is a need to handle large volumes of small chunks of data (e.g., e-mail messages, calendar appointments, address book entries, etc.). Each of these require both fine-grained access control as well as versioning support.

       

    • Versioning
      Given that users do not have to explicitly save Webwork documents, more investigation is needed to determine the best way to automatically commit and manage versions. To provide consistency, the Webwork infrastructure will need to provide platform-level support for versioning, which is different from the application-specific version control that is the common practice today.

       

    • People and Documents Neighborhood
      In the Webwork scenario, the correct people and documents automatically appear in the People and Documents Neighborhoods. We recognize, however, that making this happen effectively is a challenge. Determining the appropriate people associated with activities is untried. Current attempts at related documents (at CNN’s web site and Netscape’s related links feature, for example) are unsatisfying. New techniques will need to be developed and tested.

       

    • Automatic Document Organization
      Replacing the familiar folder scheme for document organization with automatic organization is appealing, but doing it well is a challenge. This is another area where prototyping and testing different schemes would be extremely helpful.

     

  • Management
    In our internal investigations we discovered many different parts of the company that are working on projects related to "portals." In order for a Webwork-style portal to emerge, some organization within Sun must be in charge of tracking and coordinating the now highly diffused efforts. An effective management structure must be in place to spearhead a marketing effort, manage the engineering components, and build on the results of Sun Labs research.

 

Implementing the Webwork vision is a big project, but one that has a potentially large impact on the company. The more individuals and businesses that decide to bank their data with application service provider experts, the more need there is for large servers to run those operations. But the reality is that trusting data to a third party is a leap of faith that involves loss of control for people who are now administering their own computers and networks. We believe it will take an innovative user experience and new functionality that addresses substantial end-user needs to convince people to make the move from self-administered computing to application portal computing.

  Appendices