interfaces between microservices
Brian Tingle
hypothetical alternative architecture for OAC/Calisphere inspired by
the hydra architecture.
http://tingletech.tumblr.com/post/1556487739/based-loosely-on-or-at-least-inspired-by-hydra
http://tingletech.tumblr.com/post/1556126392/from-the-hydra-framework-and-its-parts-via
Via Twitter, Mark Matienzo suggested this email list might be a good
place to have some discussion about the diagram.
http://twitter.com/#!/anarchivist/status/4673684140724224
The sketch also relates to some Mellon funded research I've been
working on with Jonathan Smith of Northwestern University
http://groups.google.com/group/content-connect
In the content connect project, we demonstrated a "virtual repository"
model where content from a fedora repository was combined with content
from XTF using the Content Repository API for Java (JCR). Future work
will migrate to using Content Management Interoperability Services
(CMIS) rather than JCR.
The vision of the content connect project is to create a suite of
access tools that are agnostic about the underlying repository (as
long as a JCR/CMIS bridge to the repository is created).
In the context of microservices, does adopting a standard such as CMIS
make sense as a way to make sure different combined microservices
don't become too tightly coupled?
cheers (and happy new year), -- Brian
Seth Shaw
repository or at least some digital preservation tools that would work
with the interface to extend an existing content repository (such as
alfresco or any other w/ CMIS). I think it would make records transfer
and preservation within and between organizations much easier. There
has been discussion about transferring electronic records from donors
with SharePoint and other content management systems that have a
potential CMIS interface but I have had no way of exploiting it. I
considered JCR but I didn't see very wide support for it. It was added
to the ever growing TO-DO list and I haven't had time to look into it
since.
To answer your final question: I think so. Well defined interfaces
serve as the fences (and gates) that make good neighbors. Strict use
of well defined interfaces prevents the internals of micro-services
becoming intertwined which causes migration problems in the future.
- Seth
Ed Summers
I haven't looked at CMIS before in detail, so thanks for the nudge in
that direction. The list of implementations on the Wikipedia page [1]
are encouraging. Are you suggesting that the "CMIS (Alfresco)" box in
the first diagram could notionally be rewritten "CMIS (Fedora)" and
that this would make Solrizer/Solr/Blacklight and XTF interchangeable?
Does Fedora currently support CMIS, and if not are there any plans to
add it?
On Tue, Jan 4, 2011 at 8:48 PM, Brian Tingle
<brian.tingl...@gmail.com> wrote:
> Future work
> will migrate to using Content Management Interoperability Services
> (CMIS) rather than JCR.
Would it be possible to briefly describe why the project you mentioned
is moving to CMIS from JCR? Is it because CMIS is more oriented around
the Web as the API instead of Java? Do you have a sense of how complex
CMIS is to implement yet? I'll have to dig in more to see, but from
some of the summary documentation it looks like CMIS offers a REST
binding that uses Atom...which seems good (to me) and makes me wonder
what (if anything) it might have with SWORD [2] which is being resumed
it seems [3].
I'd be curious to hear how you'd see CMIS to Merritt working too.
Could Merritt theoretically offer up a CMIS interface?
//Ed
[1] http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services
[2] http://swordapp.org/
[3] http://swordapp.org/2010/12/swordv2-project-plan-timeline/
peterVG
I think that CMIS is a strong enabler of the micro-services approach
allowing us
to de-couple repository management from the digital curation micro-
services that
we want to run on the 'folder' and 'document' objects in any CMIS-
compatible
repository.
I think CMIS is the most promising repository API out there with a lot
of momentum and broad vendor
and open-source support. It looks simpler to implement than JCR and we
especially like RESTful AtomPub binding which we hope to add support
for in an
upcoming Archivematica release.
Cheers,
--peter
On Jan 4, 5:48 pm, Brian Tingle <brian.tingle.cdlib....@gmail.com>
wrote:
> hypothetical alternative architecture for OAC/Calisphere inspired by
> the hydra architecture.
>
>
> http://tingletech.tumblr.com/post/1556126392/from-the-hydra-framework...
BRIAN TINGLE
Are you suggesting that the "CMIS (Alfresco)" box in
the first diagram could notionally be rewritten "CMIS (Fedora)" and
that this would make Solrizer/Solr/Blacklight and XTF interchangeable?
Does Fedora currently support CMIS, and if not are there any plans to
add it?
On Tue, Jan 4, 2011 at 8:48 PM, Brian Tingle
<brian.tingl...@gmail.com> wrote:Future workwill migrate to using Content Management Interoperability Services(CMIS) rather than JCR.
Would it be possible to briefly describe why the project you mentioned
is moving to CMIS from JCR? Is it because CMIS is more oriented around
the Web as the API instead of Java?