Date: Jan. 29, 2008
People: Craig Counterman, Mike Moretti, Qing Dong
Purpose: Qing wants to understand the purpose of the proposed REST api and how it fits into the overal stellar architecture
1. Why Stellar needs to use a ECM service now?
The current stellar content structure was based on designs in 2000 when we don't know anything about ECM beyond database and filesystem. It works, but very fragile and not scalable. Also Stellar wants to move to a more standard ECM architecture within IS&T.
2. The current Stellar architecture:
Single DB base server running Oracle
Single stellar web server hosts different tools. The tools are very different. Some use structs, some use spring MVC, and some use an inhouse implementation. Tools all use a common service api to access the database. Older tools use OKAPI objects and newer ones use hibernate.
3. What Alfresco API to use:
Stellar wants to use a remote Alfresco api so the repository is more distributed and scalable. Ideally this API should be implemented on JSR170 and JSR283. However, the alfresco JSR 170 api is in process, and JSR-RMI extension doesn't work (http://issues.alfresco.com/browse/AR-706). So that leaves us with either the Web services API and the web script.
Web Services API: fasted and most portable remoting interface. Qing has lots experience with it implementing Thalia's REST api with it. problem: Alfresco specific. not JSR 170 compliant.
Web script API: new in Alfresco 2.1 and allows developers to write tailored RESTful apis for repository access. A web script consists of three parts: description document (describes the URL that that will inititate the script), execution javascript (does the actual work), freeMarker templates which render outputs in desired format. Problems: Qing is not familiar with it. Will have to go through learning curve. The scripting language might be too simple to be very useful. Don't know if you can plug in authentication methods other than username/password. Access control is very basic. Scripts live inside the alfresco repository. Might be hard to maintain.
Stellar doesn't really care which Alfresco API we use internally as long as the REST API is stable and scalable.
4. Authentication and authorization
Currently Stellar supports username/password authentication as well as x509 certificate or kerberos id/password authentication through touchstone. How should the REST api handle authentication? Since it is consumed by the stellar java api that runs on the server, it should probably accept application certificate and the java api will pass in the authenticated user info.
Currently Stellar does authorization at the application level. Since Alfresco provides authorization, would it be easier and more efficient to let Alfresco handle the authorization part? Does Stellar have special authorizations needs that Alfresco can't meet? How does Alfresco implement groups? Can group contain sub-groups? How do we migrate stellar users into Alfresco?
5. Caching:
Stellar uses a lot of caching. Should the REST api do any caching to improve performance? Or Are Alfresco's caching and stellar's caching enough.
6. Performance and Scalability:
Stellar currently has 800 unique logins per hour during peak usage. It has a maximum pool of 500 threads. We need to verify the clusterability of Alfresco to make sure that moving to Alfresco is worth the effort.
7. The REST API will use xml as input/output. We will use JAXB with a schema language such as Relax NG to marshal java classes into xml and vice versa.
Action Items:
Mike and Craig: give Qing Stellar's data model and current api specification.
Qing: discuss with Catherine on Alfresco's scalability.
Investigate web scripts and how Alfresco uses groups.