implementing simple Document management
Asked Answered
S

5

5

My qustion is: How would you go on implementing simple DMS(document management) based on following requirements?

  1. DMS shouls be distributed web application.
  2. Support for document versioning.
  3. Support for document locking.
  4. Document search.

Im already clear on what technologies I want to use. I will use Sring MVC, Hibernate and relational (most likely MYSQL) database.

One thing Im not very clear on is if I need to use webdav, since I could just upload or download documets. I thing I have to because I need to acomplish point 2. and especially point 3. somehow. Is this the right way to go?

Any examples or experience with this would come very handy :). May be Milton is not the best library to pick for webdav?

Selection answered 31/5, 2011 at 7:17 Comment(1)
Okey I see Ill update my question, by DMS I mean document management.Selection
S
3

@Eduard, regarding dependencies on 3rd parties - are you doing this as a college/university exercise or something that will affect real users in a production environment?

At the risk of sounding very pretentious; don't reimplement the wheel! I'd definitely 2nd the call to use JCR, this way you are depending a standard and not a 3rd party implementation.

JCR is a well defined standard (that means a lot of people invested commercial effort (i.e. cash and expertise in huge amounts) into this). I would seriously reconsider looking into JCR - think of it as an API where 3rd parties provide the implementation (no vendor lockin).

Have a look at the features you'll get out-of-the-box, I believe 99 - 110% of the functionality you require is available through a JCR implementation. Plus you'll benefit from the fact the code you'll be using has been tested by hundreds of people in real world situations.

Where I'd differ from bmscomp is in suggesting JackRabbit http://jackrabbit.apache.org/

Spiegelman answered 2/6, 2011 at 11:27 Comment(5)
You are getting me convinced :) since you are all saying the same thing +1.Selection
Glad to hear it =). If an off-the-self product offers +80% of what you need (and is designed from the start as an extensible API), then you'll get far further and have the possibility of contributing your more specific extensions back to the wider community (either through code submissions, blog or wiki posts) On the webdav front: jackrabbit.apache.org/jackrabbit-webdav-library.html Good luck & happy codingSpiegelman
Edit: Looking at JackRabbit a bit closer I think it's offering more like 99.99% of what you're after (and it's an active project and there'll be plenty of support on the mailinglists and Jira). From the four points you list, all are covered and if the cooperative locking isn't what you're after it's pluggable: jackrabbit.apache.org/api/2.1/org/apache/jackrabbit/core/util/… and wiki.apache.org/jackrabbit/RepositoryLockSpiegelman
Yeah, I wonted you all up, it will be hard to decide to whom to gice that +200. But anyway I would like to hear more about webdav and if it can be helpuful for my scenario.Selection
I can see from later comments that webdav isn't looking too favourable, JackRabbit supports quite a few transfer types, including NFS/SMB. I was really hoping to find fuse-j integration, but didn't (it probably wouldn't be a huge task to implement this and would be very cool)Spiegelman
B
3

Option 1:

I am not sure about webdav, no real experience on it. But I would highly recommend you using a Document database like MongoDB.

With mongodb, you can:
1. Handle document versions
2. MongoDB has atomic operations, you can add your logic of document locking.

This will give you some awesome added benefits of search your documents store.

Option 2:

Apache Jackrabbit: A Content repository

A content repository is a hierarchical content store with support for structured and unstructured content, full text search, versioning, transactions, observation, and more.

Binder answered 2/6, 2011 at 8:25 Comment(1)
This sounds good and Ill look into it. But may be Im looking more for answer that would lead me more on how to develop this functionality by myself. MogoDB is way too specific db - I need my app not to be so database specific. And to use content repository when I only need to store documents seems overkill.Selection
S
3

@Eduard, regarding dependencies on 3rd parties - are you doing this as a college/university exercise or something that will affect real users in a production environment?

At the risk of sounding very pretentious; don't reimplement the wheel! I'd definitely 2nd the call to use JCR, this way you are depending a standard and not a 3rd party implementation.

JCR is a well defined standard (that means a lot of people invested commercial effort (i.e. cash and expertise in huge amounts) into this). I would seriously reconsider looking into JCR - think of it as an API where 3rd parties provide the implementation (no vendor lockin).

Have a look at the features you'll get out-of-the-box, I believe 99 - 110% of the functionality you require is available through a JCR implementation. Plus you'll benefit from the fact the code you'll be using has been tested by hundreds of people in real world situations.

Where I'd differ from bmscomp is in suggesting JackRabbit http://jackrabbit.apache.org/

Spiegelman answered 2/6, 2011 at 11:27 Comment(5)
You are getting me convinced :) since you are all saying the same thing +1.Selection
Glad to hear it =). If an off-the-self product offers +80% of what you need (and is designed from the start as an extensible API), then you'll get far further and have the possibility of contributing your more specific extensions back to the wider community (either through code submissions, blog or wiki posts) On the webdav front: jackrabbit.apache.org/jackrabbit-webdav-library.html Good luck & happy codingSpiegelman
Edit: Looking at JackRabbit a bit closer I think it's offering more like 99.99% of what you're after (and it's an active project and there'll be plenty of support on the mailinglists and Jira). From the four points you list, all are covered and if the cooperative locking isn't what you're after it's pluggable: jackrabbit.apache.org/api/2.1/org/apache/jackrabbit/core/util/… and wiki.apache.org/jackrabbit/RepositoryLockSpiegelman
Yeah, I wonted you all up, it will be hard to decide to whom to gice that +200. But anyway I would like to hear more about webdav and if it can be helpuful for my scenario.Selection
I can see from later comments that webdav isn't looking too favourable, JackRabbit supports quite a few transfer types, including NFS/SMB. I was really hoping to find fuse-j integration, but didn't (it probably wouldn't be a huge task to implement this and would be very cool)Spiegelman
N
2

Think about using JCR Java content Repository http://en.wikipedia.org/wiki/Content_repository_API_for_Java or you can have a look at the job done on Alfresco or and Exo framework they did a good job

Neutrino answered 2/6, 2011 at 8:28 Comment(1)
Yes they did a good job but their solution is way too complex for me. I just need to store documents version them anable to put lock on them and search trough them. Another thing is that I dont want to be dependent on 3rd party solutions way too much. So I prefer to develop this by myself.Selection
A
2

You can use these open source projects to meet your requirements:

  1. http://sourceforge.net/projects/logicaldoc/ - LogicalDOC is a modern document management system with a nice interface, easy to use and very fast. It uses open source Java technologies such as GWT, Spring, Lucene in order to provide a flexible and scalable DMS platform. http://www.logicaldoc.com

  2. http://sourceforge.net/projects/openkm/ - OpenKM Document Management - DMS Updated 2011-05-25 OpenKM is powerful scalable Document Management System (DMS). OpenKM uses Jboss + J2EE + Ajax web (GWT) + Jackrabbit (lucene) Open Source technologies. http://www.openkm.com/

Atwitter answered 3/6, 2011 at 20:0 Comment(0)
C
1

Spring MVC is a good choice. If you want to use a relational database then can also check out Datanucleus. At least the JDO layer (plus maybe the JPA layer) provides versioning support. For search I recommend apache solr, based on lucene, wich has excellent and powerful fulltext search capabilites.

Although webdav seems like the natural choice as a simple and cross plattform file transfer protocol I never had good experiences. Either the Client or the Server didn't work well (konqueror, internet explorer, zope 2, ...). So abstract from the protocol and provide multiple ways to access the file.

Compilation answered 5/6, 2011 at 21:53 Comment(1)
+1 I guess webdav is more trouble then I imagined when I started to search this topic.Selection

© 2022 - 2024 — McMap. All rights reserved.