You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by Dmitry <mi...@cargosoft.ru> on 2017/08/28 22:42:43 UTC
Architecting a heterogeneous Sling + Java EE application
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
Re: Architecting a heterogeneous Sling + Java EE application
Posted by Robert Munteanu <ro...@apache.org>.
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
Posted by Dmitry <mi...@cargosoft.ru>.
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
Re: Architecting a heterogeneous Sling + Java EE application
Posted by Jason E Bailey <ja...@24601.org>.
> > 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
Posted by Robert Munteanu <ro...@apache.org>.
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