I guess it depends on what you want the Common Document Service to look like to the clients calling it. If you want it to look like a repository, it could be implemented as a server. But I suspect you'd rather have it look like a higher level service and that you'll have a fair amount of needs in your Common Document Service API not covered by CMIS.
Jeff On Thu, May 29, 2014 at 8:56 AM, Lucas, Mike <[email protected]> wrote: > Hi! I'm pretty new to CMIS and OpenCMIS so please bear with me. > > We are building a Web Service whose purpose is to be the Common Document > Service for our enterprise. It will provide an abstraction layer in front > of multiple different content repositories in the enterprise. The API to > this Common Document Service will be CMIS. > > For now, we just have to build it to talk to (sit in front of) IBM FileNet > and Microsoft Sharepoint. Both of these support CMIS APIs so we will almost > certainly use those (unless we run into problems with them, then we can use > native APIs). In the future we may also integrate non-CMIS content > repositories. > > My question is, is this a good use case for the Apache OpenCMIS Server > product? It seems like it may be based on what I have read in the Server > Development Guide (https://github.com/cmisdocs/ServerDevelopmentGuide). > On the other hand, it may be overkill if the back-end repositories are > already speaking CMIS (as FileNet and Sharepoint do) -- since our service > would be doing a lot of translating from CMIS to objects then back to CMIS > again. > > Thanks in advance, > michael lucas | Senior Software Developer | Great-West Life | > [email protected]<mailto:[email protected]> > "Say not in grief that she is no more, but say in thankfulness that she > was. A death is not the extinguishing of a light, but the putting out of > the lamp because the dawn has come." - Rabindranath Tagore > >
