Re: Architecting a heterogeneous Sling + Java EE application
Hi Dmitry, Sorry, this somehow slipped, see my answers below On Fri, 2017-09-01 at 02:48 +0300, Dmitry wrote: > 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? To me WABs are a transitional middle ground towards moving fully to OSGi. I have not used them so far but by reading the spec I see that: - a WAB requires application server support - a Web Extender - a WAB still uses web.xml and the 'classic' JEE structure It may make more sense to you to go the WAB route first but I suggest you at least keep your options open and migrate to a pure OSGi setup. Looking forward to hearing more about your progress, once there's news about it :-) Thanks, Robert
Re: Architecting a heterogeneous Sling + Java EE application
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 > >
Re: Architecting a heterogeneous Sling + Java EE application
> > 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. > It's been a while but I've used remote access to the JCR before. https://wiki.apache.org/jackrabbit/RemoteAccess On a personal note, I would avoid JCR level manipulations and if possible stick to the Sling API. You'll discover that that you'll be writing a lot of boiler plate only to find that the Sling has come up with a graceful way of handling it already. -- Jason
Re: Architecting a heterogeneous Sling + Java EE application
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
