Hi Robert, Thanks a lot for an exhaustive explanation, things got much clearer now. But could you please elaborate a bit on the 3rd deployment option, specifically on what's the difference in general from the WAB scenario initially proposed by me? I thought "deploy OSGi (web-)bundle to Felix" and "deploy OSGi bundle to Sling" were equal notions, but turns out they aren't? (I guess the difference will be at least in using OSGi HttpService with the former scenario vs. Sling ResourceProvider with the latter.) Does it have something to do with the aforementioned "Sling provisioning"? Where can I read about it?
Seems like "going down the full OSGi route" would require some (decent) OSGi knowledge, so I think I'll start with a non-Sling part as a separate Java EE app for a prototype, but will target for a full OSGi solution for a production release. On transactions: Oak doesn't support JTA transactions at all (Repository.OPTION_TRANSACTIONS_SUPPORTED is false for Oak); Jackrabbit does, but AFAIK nobody has ever succeeded in harnessing JPA+JCR combined transactions, so I probably shouldn't rely on this. On databases: Mongo is frequently mentioned alongside Jackrabbit/Oak/Sling, but what about relational DBs? The non-Sling part of my app will use PostgreSQL, as will do IDM/SSO (Keycloak) and probably other components. Oak does have RDBDocumentStore. I wonder how fast and stable is it compared to Mongo? Can it be recommended for production use? On Keycloak integration: I'm glad to hear contributions are welcome :) will continue in my next message. Cheers, Dmitry > 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/res > ou > rce/provider/ResourceProvider.html
