Where is Alfresco residing?

[alexeyg]

I apologize if this is a stupid question… but where does Alfresco reside?  Is it a Web Application or an API?  Web Client and Alfresco seem to be synonymous…  Are they?

[turgayz]

No question is stupid really In fact, there are so many frameworks, technologies, etc. are involved in a big product like Alfresco, so I believe that it's simply impossible for a single individual to know all of them perfectly.

As far as I understand:
- Alfresco is a content repository. It has APIs to use the repository. Possibilities are, to use the Alfresco's own API, Java JSR 170 API (JCR API), PHP, etc.
- Alfresco product also includes a web application. This is an example of what you can do with Alfresco. The web app. starts the repository when started, so I think that it is an important part of Alfresco. (I don't know how, but) I believe that you can omit the web application and start the repository only, which you can connect to and work with your own client application.
- Alfresco also has WebDav and CIFS access, with which you can import documents to the repository and all the content rules work when you do so.
- Since Alfresco is JSR 170 compliant, I believe that you can connect to the repository with another JSR 170 compliant product. However, I guess that it is not a good idea to work on an Alfresco repository with another product. But I guess that you can export the repository and import into another product and use it there, which is why there is a JSR 170 specification. But of course, Alfresco specific functionality might be lost in such a case.

Hope this helps,

[alexeyg]

There is still one thing I do not get.  Tomcat is a Servlet container.  Everything it deploys is under a specific context, right? 

I think this is what got me confused.  Is this correct?

Alfresco.war is a Web Client that accesses the API.  Web Client "starts" Alfresco either explicitly or by accessing it.  I was playing with it a little bit - I copied Alfresco JARs and DDs into my context and tried to access the Repository from my webapp.  First call took quite a while and I got the "repository started" message.

This part is confusing to me…  It seems you are forced to start a Repository per context.

[turgayz]

It seems you are forced to start a Repository per context.

If you start the application this way, yes I think a new repository will be started.
However, I haven't tried it yet, but the web-service API should serve this purpose: You can start the repository in a VM(From the web app, or from another app), and then access *that* repository from another application using the web-service API, or the PHP API, and I guess there is also a Python interface (?)

[alexeyg]

I wonder what kind of concurrency issues will arise if two repository instances are pointed to the same DB…  This should not be a problem in our case because the service layer API will be read-only.

I'll try to find some docs on the web service API.  Sounds like it is exactly what I am looking for.  Sounds like accessing it accross Tomcat contexts would only be possible via web services…  And web services would be much easier than figuring out which JARs and DDs are required to build ApplicationContext… 

Thanks for your help, this really cleared things up for me.  Hopefully they have good documentation on Web services.  I found Service Layer docs to be rather lacking.  Thanks again!

[turgayz]

You're welcome,
I didn't study the web service documentation and APIs yet, but I see that there are lots of examples and unit tests you can examine in packages org.alfresco.webservice.sample and org.alfresco.webservice.test.

I wonder what kind of concurrency issues will arise if two repository instances are pointed to the same DB…

I think that it is not a good idea to point two repository instances to the same DB and disk space. :roll:

[paulhh]

Yes, I think I can say that we do not recommend 2 instances pointing to the same DB 🙂

Just try to think of the DB as an implementation detail - the software uses it, but we don't expect other software to (with the exception of read-only, e.g reporting).

The web service API is definitely the best interface for flexible integration - since you can then drive Alfresco from your favourite language (I'm sure there's a Fortan web service framework out there for those that want it).  We will be looking at RMI in the not too distant future too.

Cheers
Paul.

[alexeyg]

Yes, I think I can say that we do not recommend 2 instances pointing to the same DB 🙂

Just try to think of the DB as an implementation detail - the software uses it, but we don't expect other software to (with the exception of read-only, e.g reporting).

The web service API is definitely the best interface for flexible integration - since you can then drive Alfresco from your favourite language (I'm sure there's a Fortan web service framework out there for those that want it).  We will be looking at RMI in the not too distant future too.

Cheers
Paul.

thanks for your response!

Correct me if I am wrong, but this means there is no way access JCR using JSR-170 while also using Alfresco Web Client?  Web Services can connect TO the Web Client… but the only way to interface with Alfresco JCR using JSR-170 (while keeping Web Client) is to deploy it in the same Tomcat Context as Alfresco Web Client? 

Sounds like the choice is to use JSR-170 OR Web Client.  Is this correct?  Thanks.

[alexeyg]

What I try to obtain the Repository object from Web Client?

I read that I can specify a "crossContext" attribute in tomcat, call getContext(String uripath) on the ServletContext, and get a hold of the Repository somehow.  Any thoughts?  Thanks!

[davidc]

Please see http://www.alfresco.org/forums/viewtopic.php?t=963.