Hi, I'm developing an application that will be comprised of two large parts: the repository part (Sling-based) and the business logic part.
The latter will deal with complex relationships between the content and the users, content workflows etc. - all the stuff that is much more naturally expressed within the relational and object-oriented paradigm rather than hierarchical paradigm which Sling implements; hence the separation between the parts. Thus, there will be a set of two REST APIs, and a HTML5 frontend will operate both of them. I'm an experienced Java EE developer, so most likely the business logic part will be implemented with JAX-RS + JPA [+ EJB]. AFAIK there are two deployment options here, and I wanted to discuss them together with their benefits and drawbacks. The options are: 1) WAB deployed to the same OSGi container Sling runs in, and 2) WAR deployed to a separate application server. Integrated deployment ===================== >From what I've learned yet, I'll have to rely on Apache Aries as an implementation of JAX-RS, JPA, EJB and JTA on OSGi platform (so-called OSGi Enterprise). The application itself should be packaged as a WAB and deployed to the same Felix container used by Sling. Pros: - to work with the underlying repository, we can use JCR API directly (can we?) - moreover, we can use transactions that would span both JPA and JCR realms (can we?) - we can use single authentication mechanism for both Sling and JAX-RS endpoints (can we?) - no separate application server required, thus less memory/CPU overhead and simpler deployment process. Cons: - there are concerns about stability and feature completeness of Aries JAX-RS implementation. The spec itself is in a draft [1], and the implementation [2] AFAIK is not yet a part of the official Aries distro; - I'll be limited to Java EE APIs implemented by Aries, hence there'll be neither CDI nor WebSocket (or will they?) - the JAX-RS part couldn't be scaled/clustered independently of Sling. Separate deployment =================== In this scenario, the application will be packaged as a WAR and deployed to a Java EE server (maybe even the same server Sling runs on, should the latter be deployed as a WAR too). Pros: - immediate access to full Java EE APIs + immediate availability of Java EE 9 upon release; - ability to scale the application independently of Sling. Cons: - to access repository data, I'll have to resort to either REST or remote JCR over RMI (is it safe for a JCR repo to be accessed concurrently both by Sling and an external client?) - not sure if JPA+JCR combined transactions will be feasible at all; - the overall configuration and deployment process becomes more complicated, let alone resource overhead; - will need to deal with unified authentication / SSO. I'll be grateful if someone more experienced with Sling than I shares thoughts on this, especially the conjectures in the first Pros section. Thanks in advance! Dmitry P.S. Regarding SSO, the project will use Keycloak [3] as an IDM/SSO, so I think I'll either way have to implement OAuth2 bearer token auth and/or OpenID Connect for Sling + Jackrabbit Oak. This will bring into Sling a whole lot of powerful auth-related features, like social network auth out of the box, multi-factor auth, identity federation etc. Please let me know if this is interesting, so we could discuss it in a separate thread. [1] https://github.com/osgi/design/tree/master/rfcs/rfc0217 [2] https://github.com/apache/aries-jax-rs-whiteboard [3] http://keycloak.org
