Scenarios for developing app around Alfresco

[pk_simmons]

Hello

I have a question about possible ways for implementing a custom application around Alfresco.

Lets say that my application contains a set of services - some would need access to the document repository but others contain an unrelated business logic (custom logic beans, scheduled jobs, database access - all this generic stuff).

1. Implement a separate application (separate WAR/EAR), communicate with Alfresco using webservices (SOAP, REST)
- I can build my application any way I choose,
- a (unnecessary) overhead from using webservices.

2. Implement my application as a set of WebScripts
- direct access to Alfresco API,
- custom services must extend DeclarativeWebScript (why not interface/annotation or - lets go crazy (;-)) - JAX-RS?),
- what about testability?
- what about code-deploy-test cycle, in-vm code hot swap?

Any other possibilities?

I've played with Apache Jackrabbit before - it has an interesting feature of exporting repository as a shared JEE resource. There is some kind of JCR JNDI adapter (http://wiki.alfresco.com/wiki/JCR_JNDI_adapter) but:
- is it production ready?
- it restricts me to JCR API; Alfresco is not Level 2 compliant so some important features will be lost,
- no access to native, full-featured Alfresco API.

[jpfi]

Hi,
I'd prefer 1. Instead of using JCR, CMIS is perhaps also a possibility:
In short using an CMIS repository (e.g. Alfresco) by a standardized WebService or AtomPub(REST) based access.
Cheers,
Jan

[t_broyer]

Hello

I have a question about possible ways for implementing a custom application around Alfresco.

Lets say that my application contains a set of services - some would need access to the document repository but others contain an unrelated business logic (custom logic beans, scheduled jobs, database access - all this generic stuff).

1. Implement a separate application (separate WAR/EAR), communicate with Alfresco using webservices (SOAP, REST)
- I can build my application any way I choose,
- a (unnecessary) overhead from using webservices.

Alfresco Share is built this way, so the overhead probably isn't as big as you might think (depends what you want to do with Alfresco though, of course)

I'd personnaly go this way (using web scripts to expose Alfresco as "RESTful services")

[pk_simmons]

Hmm, so something like:
- expose a repository related functionality via REST services,
- consume them in separate application.

I must do some prototyping - a performance overhead is a wild guess now as there are few other factors like additional thin client. A direct access would be more performant and elegant, but maybe some JAX-RS client could provide at least easy marshalling/unmarshalling.

Testability of the all-in-Alfresco-solution isn't clear, either.

Ok, thx for yout throughts.