|
|
Web 2.0 Roadmap
JSON-RPC
Scenarios:
- A client application invoke a SCA Service using JSON-RPC and the invocation returns a business exception.
- 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.
- 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)
- 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 )
- Better runtime exception reporting, runtime exceptions occurring as part of a JSON-RPC interaction should be properly reported to the JavaScript client. (TUSCANY-2394)
- 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)
- 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
- 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.
- Ability to negotiate content types (XML, JSON etc) and use the corresponding Tuscany data bindings to provide data with the requested content type
- 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.
- 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
|
