Hi Dmitry, I'll try and comment on your pros and cons, see inline. Also I would suggest another option of deployment.
On Tue, 2017-08-29 at 01:42 +0300, Dmitry wrote: > 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. I would suggest considering 3) deploying all the application logic as OSGi bundles in Apache Sling. While Sling is indeed - as you pointed out - geared for hierarchical storage, there is nothing that prevents it from running other OSGi bundles which deal with different data sources. You can very well deploy your business logic as other OSGi bundles, and access JPA, JAX-RS and others independently of Apache Sling. I think there cons are the same as your solution 1) - WAB deployment but the additional pros are: - single deployment model ( Sling with provisioning model ) - ability to split the application later ( just OSGi bundles, you can split them into multiple apps easily ) I would also add that instead of JAX-RS you might consider exposing your data in the Sling resource tree by implementing a custom ResourceProvider [5] . They you'd get the same HTTP semantics as the rest of Sling for free. > > 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?) If you want to access the JCR API directly from the non-Sling part, you will be able to do so if the non-Sling part is part of the same OSGi runtime. > - moreover, we can use transactions that would span both JPA and JCR > realms (can we?) That I am not certain of. The JCR spec [4] may be of more help, also the jackrabbit user mailing list. > - we can use single authentication mechanism for both Sling and JAX- > RS > endpoints (can we?) Since they are part of the same (JEE) application context, I don't see why not. > - 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; That you would need to validate yourself or by asking the Aries mailing list. > - I'll be limited to Java EE APIs implemented by Aries, hence > there'll > be neither CDI nor WebSocket (or will they?) Same below. > - the JAX-RS part couldn't be scaled/clustered independently of > Sling. Well, you need to define your scaling (out) model first. Sling is trival to scale as it's stateless. I would expect mostly the same with the JAX-RS implementation - it's the data layer that needs discussion. Sling with Oak+MongoDB is simple to scale, not sure what plan you have for the 'other' backend. I'd also add that WABs are IMO a crutch towards getting your application fully up to speed on OSGi or a compromise when you need to support both OSGi deployments and classical application server deployments. Going down the full OSGi route would be simpler in the long term. > > 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. Yes, splitting the application makes it easier to scale - one of the main benefits of the microservice architecture. But see my alternate proposal - going the full OSGi route gives you the flexiblity to pick application boundaries as you see fit - doing a split WAR/Sling deployment does not. > > 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?) Yes, concurrent access is safe. > - not sure if JPA+JCR combined transactions will be feasible at all; Not sure either, but probably not. > - 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. Absolutely, we welcome technical discussion and contributions very much :-) Robert > > [1] https://github.com/osgi/design/tree/master/rfcs/rfc0217 > [2] https://github.com/apache/aries-jax-rs-whiteboard > [3] http://keycloak.org > [4]: https://docs.adobe.com/docs/en/spec/jcr/2.0/21_Transactions.html [5]: https://sling.apache.org/apidocs/sling9/org/apache/sling/spi/resou rce/provider/ResourceProvider.html
