Web 2.0 Roadmap

JSON-RPC

Scenarios:

  • A client application invoke a SCA Service using JSON-RPC and the invocation returns a business exception. (tick)
    • e.g Empty catalog throws a Busines Exception. Business Exception should properly propagate and display nicely to client.
  • A client application invoke a SCA Service using JSON-RPC and the invocation returns a runtime exception. (tick)
    • e.g Try to retrieve catalog items from a catalog service that is un-available. Runtime exception properly propagate and display nicely to client.
  • A client application needs to access a service exposed trough JSON-RPC binding that requires authentication.
    • e.g make sure if nobody can get to the catalog if it's not authenticated

Features/JIRAS

  • Exceptions not properly reported to client by JSONRPC binding (TUSCANY-1961) (tick)
  • Support for security (this will require exploratory work to understand what SCA security policies make sense to implement) (TUSCANY-2394 )
  • Business Exception reporting, business exceptions raised by a service should be transported to the client through JSON and reported to the client as proper JavaScript business exceptions (TUSCANY-2394 ) (tick)
  • Better runtime exception reporting, runtime exceptions occurring as part of a JSON-RPC interaction should be properly reported to the JavaScript client. (TUSCANY-2394) (tick)
  • Complete data binding support, a set of test cases should be written to make sure that the POJO and JAXB patterns supported in Java components have a proper mapping to JSON and that the application developer can easily understand the corresponding representation of these objects in JavaScript. (TUSCANY-2394) (tick)
  • Build some samples that consume publicly available JSON services (e.g from programmableweb, or yahoo)

ATOM

Scenarios

Features/JIRAS

  • Complete support for ATOM API
    • Analyze specification gaps
    • Complete support for location header
    • Full support for lastmodified in HTTP headers and etags (tick)
      • needs to involve application logic, to properly find the lastmodified data...
  • Support for postMedia and putMedia, including the ability to stream that content in the target application component
  • Support for security (this will require exploratory work to understand what SCA security policies make sense to implement)
    • Provide security support for verb actions (e.g. delete)
    • ATOM pub users often need to login. Google GDATA supports SSO
    • Provide support for Authentication|Encryption|Signatures ???
  • Enhanced error reporting, mapping errors like resource not found to HTTP 404. Other errors might be mapped to HTTP 500 with proper exception in the message body. (tick)
  • Ability to negotiate content types (XML, JSON etc) and use the corresponding Tuscany data bindings to provide data with the requested content type (tick)
  • Enhance performance on low-bandwidth by providing gZipped contents enabled by http headers
  • Improve the client side programming model by researching available JavaScript Atom API or investigate creating one.(tick)
  • Integrate Atom binding with persistence repository (e.g database and implementation.data.xml)
    • investigate how to handle relationships (e.g When you have a customer that owns multiple accounts, you can define HREF to a account feed, but how do you handle that sub-set of accounts that the customer owns.)
  • ATOM workspace support

References:

Widget

Scenarios

Features/JIRAS

  • Support references wiring to services from multiple hosts/ports (cross domain support using on demand js pattern)
  • Add support for other bindings (e.g DWR)
  • Support widget implementation over web-app
    • Discuss possible deprecation of scaDomain.js
  • Enable support for google widgets (using shindig)
  • Upgrade to latest open ajax (tutorial)

Sample, Scenarios and Tutorial

  • Integrate implementation-data-xml to provide data feeds.
    • Use store tutorial to drive this item
  • PhotoGallery scenario ?
  • No labels