Nuxeo architectural Issues
This section has been built on first user feedbacks. It lists topics that have not yet or only partially been considered. Since most are Nuxeo-related, insight from Nuxeo people is valuable.
-
Need: Allow to distinguish documents whose metadata have been user-validated from the document who have only been generated (and might be irrelevant).
-
Current state: Nothing done yet.
-
Issues: N/A
-
Todo: Specify precisely the lifecycle needs/use cases, implement (by using Nuxeo's workflow system?)
-
ideas : "temporary" boolean metadata and / or "default appli", per user or even workflow driven validation
-
answer : you con define a dedicated lifecycle (steps and transitions) and bind it to your document types. You may want to use it in workflow but it's not needed : you can simply use actions and listeners if you don't need all jBPM stuffs. See LifeCycle extension point for more info.
-
Need: A way to authenticate access to the registry for users, and to the REST APIs.
-
Current state: Only one account (Administrator) + auth. disabled for the REST APIs.
-
Issues: Before auth was disabled, any call to the EasySOA REST API when not authenticated redirected to the login page (didn't request for basic HTTP auth like restlets did).
-
Todo: Get information on how to integrate with LDAP, and especially how Nuxeo handles authentication through REST.
-
Ideas : several different topics : SSO (when already logged in discovery client don't ask for relog when going in nuxeo and vice versa), SSO login (at web discovery client load, redirect to nuxeo login page configured with custom success and error pages), SSO json calls (passing the auth token). NB. auth architecture (like Nuxeo's AuthService being implemented on top of an LDAP or of its own) is not an issue here.
-
answer : Nuxeo authentication works by defining authenticators in chains. You can also define specific chains for a given url pattern or http request. Forcing BasicAuth for Rest call should be easy since this is already done in Nuxeo for all standard Rest APIs. LDAP binding is a completly different subject that is not related to the authenticator. LDAP is only a matter of defining what is the source for users. For that you can use the directory extension point to make Nuxeo use the LDAP as a source of users.
- Need: Show service information in a relevant way for business users, developers and administrators.
- Current state: Implemented "virtual navigations", one for each of the 3 actor types.
- Issues: Services for exemple still show all technical information to business users
- Todo: How to customize in a more in-depth way how the registry is shown to the different profiles?
- answer : the best option would be to define user profiles (i.e. store or compute a attribute or a group), based on this attribute/group you can configure what actions/views are available and if needed you can show/hide the widgtets.
- Need: Implement complex relations between documents (ex: n-n relations). Necessary to introduce Environments, Service references, etc.
- Current state: Mostly agregation relations. "Service references" only store their respective service ID to dynamically build a link to the document, thanks to a custom widget.
- Issues: Agregation apart, relations between documents are badly represented. Nuxeo's "relation" system was also tried, but proved to be quite difficult to use programmatically (mainly web cache issues).
- Todo: How could we store links to documents as metadata? Is there another way to do something similar ? NB. Nuxeo has several relation mechanisms : [RDF predicates] (http://community.nuxeo.com/5.3/books/nuxeo-book/html/relation-service.html), VocabularyService, [Nuxeo Document proxies] (http://community.nuxeo.com/5.3/books/nuxeo-book/html/nuxeo-platform-documentLink.html), [new relation document types] (http://forum.nuxeo.com/m/12299/)
- here we are mixing several different concepts and seam caching is not only bound to relations.