You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@sling.apache.org by sam <sd...@yahoo.com> on 2013/02/24 11:08:25 UTC
Feasible Use Case?
I have been coming up to speed over the past week and some on the various
OSGi offerings and am specifically interested in what Sling has to offer for
an upcoming project.
Based on our requirements I have been toying with the idea of having a
centralized local instance(s) of Sling to act as a gateway to several remote
OBRs. This would permit administration and approval of what is visible to
connecting parties. I think moving forward in a PoC with an approach like
this it would be good to represent or possibly mirror the remote OBRs in a
local Sling *Repository per remote OBR configuration*.
Being fairly new to OSGi and the various offerings and ways of deployment I
am not certain if this is a sound idea or possibly if a better alternative
approach would be preferable? In addition, it is not clear to me how to best
set this up with Sling. I have read the documentation covering the
installation and upgrading of bundles but how to create a new and isolated
repository in Sling is not clear. The idea is that remote OBR foo.bar is
meant for product versions of foo.bar and all access to a local instance
should not inter-mix with anything outside of this. So really having a node
per product that represents a branch in one repository is not enough I
think.
For configuration, I'm looking at running Sling as a feature within Karaf.
Also here I'm not sure if this ideal but the separation provided by Karaf in
being able to easily add additional children is fairly attractive. Future
deployments of web applications into a new war feature is very possible, the
basic feature concept alone seems like it could be useful. I'm not sure if
this done often or if it is better to run Sling standalone?
Thanks
--
View this message in context: http://apache-sling.73963.n3.nabble.com/Feasible-Use-Case-tp4021906.html
Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Feasible Use Case?
Posted by sam <sd...@yahoo.com>.
Ok so actually if I wanted REST access for loading unstructured content in
the case of a non-OSGi based consumer and loading a bundle jar directly for
those that are OSGi where the REST path would distinguish the repository
location would that make sense?
I know it is possible to directly store bundles in the Sling repo. and then
load it as I have tested with the following scenario:
curl -vvv -u admin:admin -F"sling:resourceType=test/A"
-F"testBundle.jar=@testBundle.jar"
http://localhost:8181/content/provider/bundles
#from karaf cli
install -s http://localhost:8181/content/provider/bundles/testBundle.jar
This bundle does not have the Sling-Initial-Content setup though.
The preference would be instead of placing the responsibility on any
third-party providers for laying out the content, they simply provide the
bundles in an OBR, those bundles either contain the Sling-Initial-Content
and structure for non-OSGi or without for normal bundles. Some of these
providers may not work with Java providing content only so keeping the Java
side of things to a minimum is best. An admin will then install them in a
local mirror/cache with the possibility for some bundles to be automated
through a scheduled job.
So given that case how to store the data and make it accessible locally. For
example to have the following:
OSGi
get(install) /content/osgiBundle/consumerA/testBundle.jar
non-OSGi
get /content/contentBundle/consumerB/{resources,binaries,...}
This way things don't deviate too much and you get the same benefits such as
search etc.
Based on the documentation it appears the bundle needs to be activated for
the Sling-Initial-Content to be processed. Obviously this is something that
shouldn't happen in the standard bundle case so it should be simply stored.
I'm guessing to support both cases it will require more agreed upon
convention which is fine as long as it can work with REST access similar to
what I mentioned before.
The goal here is to provide a common packaging and distribution mechanism to
handle the different consumer types. This looks to be a simpler and feasible
approach compared to involving an ESB for example although that might be the
better way to go, another point I'll need to determine.
sam
--
View this message in context: http://apache-sling.73963.n3.nabble.com/Feasible-Use-Case-tp4021906p4022017.html
Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Feasible Use Case?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Sun, Feb 24, 2013 at 11:32 PM, sam <sd...@yahoo.com> wrote:
> ...So basically the flow I'm considering is this:
> - External OBR comes online for product A-C
> - Administrator examines OBR and contained bundles to verify content is
> structured correctly as defined by the Sling-Initial-Content per bundle
> - OBR is approved and is registered with central GW component
> - OBR bundles are then installed (here though I'm not sure how to do this
> atm, the bundles will go into Sling JCR and being accessible through Felix
> is not really relevant)
> - Content is now accessible by internal products A-C...
IIUC what you want to build is an OBR proxy, running on Sling, which
hides artifacts that proxied OBRs provides, until those artifacts have
been approved by an administrator. Is that correct?
If yes, the above scenario looks good to me and is certainly feasible
with Sling, but I don't see why you want OBR bundles to be installed
in the Sling instance that runs the proxy. I don't think you need
that, and it would mess up that Sling instance. The proxy just needs
to consider those bundles as abstract artifacts that have requirements
and capabilities.
As you mention Karaf, note also http://blog.nanthrax.net/tag/obr/ - I
don't know what the status of that is, but it might provide what you
need, and looks like it uses a plugin-based storage architecture where
you might be able to integrate a Sling repository.
-Bertrand
Re: Feasible Use Case?
Posted by sam <sd...@yahoo.com>.
Hi and thanks for the response.
This looks to be pretty much what I'm looking for:
http://sling.apache.org/site/content-loading-jcrcontentloader.html
<http://sling.apache.org/site/content-loading-jcrcontentloader.html>
I want to structure an existing bundle in such a way that it can be loaded
in the Sling JCR in an unstructured way. These Bundles are located in remote
OBRs.
You can register remote OBRs with Felix making those bundles accessible.
This Felix instance will be administered and will be the central GW for
obtaining info from the remotes. An administrator will explicitly add or
remove these OBRs based on business criteria but all internal consumers can
only access this information through the GW and that information is
presented in an unstructured format through Sling's REST based APIs
So basically the flow I'm considering is this:
- External OBR comes online for product A-C
- Administrator examines OBR and contained bundles to verify content is
structured correctly as defined by the Sling-Initial-Content per bundle
- OBR is approved and is registered with central GW component
- OBR bundles are then installed (here though I'm not sure how to do this
atm, the bundles will go into Sling JCR and being accessible through Felix
is not really relevant)
- Content is now accessible by internal products A-C
So by making all content structured and layed out correctly through use of
the Sling-Initial-Content header then a provider and consumer may agree upon
a contract. I'm looking at this approach because often the consumers
internally will not be able to leverage the bundles directly since many are
non-OSGi based. My hope is that this way a decent generic distribution
channel can be defined.
This is still very early but I'm liking what I see so far. It is also good
to see that these technologies are leveraged in commercial based products
such as some of the blogs I have read on Adobe. So there has already been
some trial by fire so to speak :)
--
View this message in context: http://apache-sling.73963.n3.nabble.com/Feasible-Use-Case-tp4021906p4021933.html
Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Feasible Use Case?
Posted by Olaf Otto <ol...@x100.de>.
Hi Sam
I am having trouble really understanding the use case. OBRs serve the
deployment of bundles, but I take it you are trying to centralize access
to services provided by various bundles? What do you mean by "local"
sling repository? An idenpendent JCR node in an independent OSGi
container? Since OBRs are basically bundle sources (much like a maven
repo), I am uncertain what you mean by gateway to an OBR. Could you
elaborate a bit more on you goals?
Regards,
Olaf
On 02/24/2013 11:08 AM, sam wrote:
> I have been coming up to speed over the past week and some on the various
> OSGi offerings and am specifically interested in what Sling has to offer for
> an upcoming project.
>
> Based on our requirements I have been toying with the idea of having a
> centralized local instance(s) of Sling to act as a gateway to several remote
> OBRs. This would permit administration and approval of what is visible to
> connecting parties. I think moving forward in a PoC with an approach like
> this it would be good to represent or possibly mirror the remote OBRs in a
> local Sling *Repository per remote OBR configuration*.
>
> Being fairly new to OSGi and the various offerings and ways of deployment I
> am not certain if this is a sound idea or possibly if a better alternative
> approach would be preferable? In addition, it is not clear to me how to best
> set this up with Sling. I have read the documentation covering the
> installation and upgrading of bundles but how to create a new and isolated
> repository in Sling is not clear. The idea is that remote OBR foo.bar is
> meant for product versions of foo.bar and all access to a local instance
> should not inter-mix with anything outside of this. So really having a node
> per product that represents a branch in one repository is not enough I
> think.
>
> For configuration, I'm looking at running Sling as a feature within Karaf.
> Also here I'm not sure if this ideal but the separation provided by Karaf in
> being able to easily add additional children is fairly attractive. Future
> deployments of web applications into a new war feature is very possible, the
> basic feature concept alone seems like it could be useful. I'm not sure if
> this done often or if it is better to run Sling standalone?
>
> Thanks
>
>
>
> --
> View this message in context: http://apache-sling.73963.n3.nabble.com/Feasible-Use-Case-tp4021906.html
> Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Feasible Use Case?
Posted by Dave Fisher <da...@comcast.net>.
On Feb 26, 2013, at 3:37 AM, Bertrand Delacretaz wrote:
> On Mon, Feb 25, 2013 at 10:57 AM, sam <sd...@yahoo.com> wrote:
>> Actually ACE was the first thing I looked at but unfortunately it is still in
>> incubation...
>
> What makes you think it is? ACE graduated a year ago [1], if you see
> contrary information please let us know were so that they can fix it.
ACE has not made a release since it graduated at the end of 2011.
The version on http://ace.apache.org/downloads.html is 0.8.1-incubating.
Regards,
Dave
>
> -Bertrand
>
> [1] https://blogs.apache.org/foundation/entry/the_apache_software_foundation_announces23
Re: Feasible Use Case?
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Mon, Feb 25, 2013 at 10:57 AM, sam <sd...@yahoo.com> wrote:
> Actually ACE was the first thing I looked at but unfortunately it is still in
> incubation...
What makes you think it is? ACE graduated a year ago [1], if you see
contrary information please let us know were so that they can fix it.
-Bertrand
[1] https://blogs.apache.org/foundation/entry/the_apache_software_foundation_announces23
Re: Feasible Use Case?
Posted by sam <sd...@yahoo.com>.
Actually ACE was the first thing I looked at but unfortunately it is still in
incubation and the documentation is fairly sparse.
--
View this message in context: http://apache-sling.73963.n3.nabble.com/Feasible-Use-Case-tp4021906p4021963.html
Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Feasible Use Case?
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Sun, Feb 24, 2013 at 11:08 AM, sam <sd...@yahoo.com> wrote:
> ...I have been toying with the idea of having a
> centralized local instance(s) of Sling to act as a gateway to several remote
> OBRs. This would permit administration and approval of what is visible to
> connecting parties...
depending on what your actual use case is you might also want to have
a look at http://ace.apache.org/ which is specifically about managing
and distributing components such as OSGi bundles.
-Bertrand