Remote API Research

[resplin]

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com

Research For Future Features
NOTE: This page represents research.  Features mentioned in this page are not necessarily going to be part of the Alfresco product or added to the development time line.

Table of Contents

• 1 Goals


• 2 Requirements


• 3 How the APIs fit together


• 4 Federated Repository Servers


• 5 Tasks


• 6 API Services

Goals

Alfresco currently supports the following remote APIs:

1. Alfresco Web Services
   
2. JCR-RMI to allow remote JSR-170 access
   

Both of these APIs are fully supported, but do not expose the full capabilities of Alfresco.  Also, the development of new Web Services is expensive.

With this in mind, and looking to future features we'd like to support, it's time to take a look at how we provide a full-featured Remote API.

Providing a Remote API in itself is not a technical issue.  However, it touches on many (current & future) aspects of Alfresco and so some thought-time is worth while.  In parallel, the industry is focusing on standardising content management repository & services interfaces.

Moving forward, we would like to achieve the followings goals:

1. Stand-alone Repository Server (equivalent to database)
   
2. Detached Alfresco Web Client
   
3. Multiple Alfresco Web Clients against single Repository Server
   
4. Federated Repository Servers (distributed, not clustered)
   
5. Consistent API approach for server communication / application development
   
6. Make it easier to expose new Web Service APIs
   

Also, potentially touches on:

1. Federated Search (remote api is just one of many implementation approaches)
   
2. Public Query Language
   
3. Server Administration (run-time configuration)
   

Requirements

1. Remote API is the definitive specification of public Repository capabilities
   
2. Remote API is specified in Java??
   
3. Provides all functions required by detached Web Client
   
4. Designed for remote access (really - latency, bandwidth)
   
5. Also accessible in-process
   
6. Support pluggable remoting protocols
   
   • RMI
     
   • SOAP
     
   • HTTP
     
   • ...
     
7. Allow direct client access to remoting protocol
   
   1. BPEL engine (SOAP), Ajax client/Browser (HTTP)
      
8. Support de-referencable (cross-repository) content/meta-data/node handles
   
   • URI
     
   • WS-Addressing
     
9. Authentication context
   
10. Transaction context (start, commit, rollback as part of protocol?)
    
11. Support content/meta-data,node caching
    
12. Client API Factory (ala JDBC connection)
    
13. Support for client-side object-oriented API wrappers for developer
    
    1. Batching statements
       
    2. Statement order
       
    3. Transient references for new objects
       
    4. ...
       
14. Rid Apache Axis
    

Also, potentially touches on:

1. Allow a RESTful HTTP remoting plug-in
   

How the APIs fit together

600px

Federated Repository Servers

TODO: List out typical network topologies (repos, caching, clients, search etc)

Tasks

1. Catalog
   
   1. Current Foundation, Web Service API methods
      
   2. Web Client / API interactions (very important)
      
2. Research
   
   1. XFire
      
   2. Spring Remoting
      
   3. Atom, Atom Publishing, OpenSearch, Micro-formats, REST vs. Web-Services
      
   4. Restlets
      
3. Java API definition
   
   1. Cross-cutting concerns (auth, trx, references)
      
   2. Services
      
   3. Java API / remoting protocol mappings (cross-cutting concerns to RMI/SOAP)
      
4. Java API Implementation
   
   1. Client API Factory
      
   2. Service implementations
      
   3. RMI bindings
      
   4. SOAP bindings
      
   5. In-process bindings
      
5. Developer API re-hosting
   
   1. JSR-170
      
   2. PHP?
      
   3. Javascript?
      
6. Custom Remoting protocol definition
   
   1. RESTful HTTP (future?)
      

API Services

TODO: Define