Hmm, all the text ahead what is before ‘Anacron’ should have been removed :-( The actual code is on the link.
I started a few days ago but noticed it was getting too long. This morning I just made an enRoute project out of it. So please discard any code in my mail and look at https://github.com/osgi/osgi.enroute.examples/tree/master/osgi.enroute.examples.backend.application <https://github.com/osgi/osgi.enroute.examples/tree/master/osgi.enroute.examples.backend.application> Sorry, kind regards, Peter Kriens > On 8 jan. 2015, at 15:48, Raymond Auge <[email protected]> wrote: > > Peter is there a typo in the addBackend method on the put operation? > > On Thu, Jan 8, 2015 at 9:45 AM, Peter Kriens <[email protected] > <mailto:[email protected]>> wrote: > This is the archetypical use case for OSGi: > > interface Backend { > void store( String name, byte[] data ) throws Exception; > } > > @Component > public class FrontEnd implements REST { > final Map<String,Backend> backends = new ConcurrentHashMap<>(); > > @Reference(multiple=true,dynamic=true) > void addBackend(Backend backend, Map<String,Object> props) { > backends.put(backend, props.get(“type”)); > } > void removeBackend(Map<String,Object> props) { > backends.remove(props.get(“type”)); > } > > interface PUTRequest extends RESTRequest { > byte[] _body(); > String type(); > } > > public void putData( PUTRequest req, String [] path ) { > Backend b = backends.get(req.type()); > if ( b == null) > throw new FileNotFoundException(“No such type “ + req.type()); > > String p = Strings.join(path, “/“); > b.store(p, req._body() ); > } > } > > @Component > public class FileSystemBackend implements Backend { > > Ancoron, > I though the problem was kind of nice for an example so in the light of the > OSgi enRoute work I turned it into a little enRoute application. I added all > the documentation in the readme file. You can find the app here: > > https://github.com/osgi/osgi.enroute.examples/tree/master/osgi.enroute.examples.backend.application > > <https://github.com/osgi/osgi.enroute.examples/tree/master/osgi.enroute.examples.backend.application> > > Let me know if this works for you. > > Kind regards, > > Peter Kriens > > >> On 30 dec. 2014, at 23:49, Ancoron Luciferis >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> Hi OSGi devs and experts, >> >> I've got a problem which I really want to solve in an elegant way but I >> think I haven't found the appropriate pieces yet. >> >> The problem is the following: >> >> I want to create some abstraction for a little data management system >> which should be connected to different data backends at the same time >> (e.g. S3, Dropbox, local/network filesystem, ...). >> >> Now let's consider a simple example of the logic involving the following >> standard CRUD operations (because I want to publish that in a single >> ReST endpoint): >> >> * create (e.g. upload) >> * read (get metadata or list objects/files/buckets/... or just download) >> * update (e.g. re-upload or change metadata) >> * delete >> >> So, what I actually want is the following: >> >> 1.) For creating/uploading a new object, a specific data backend may be >> specified via HTTP header or determined automatically (e.g. based on >> expected size or some other metadata). >> >> 2.) For listing existing objects all service instances/data backends >> shall be queried at the same time (in parallel) and results combined >> into a single list. >> >> 3.) For retrieving object metadata, downloading a specific object, >> modifying, deleting it or executing some other operation with a specific >> object, the correct service instance/data backend is called. >> >> >> So, for case 1 I would need some way to evaluate the contextual >> information of the upcoming service call (in this case the HTTP header). >> If that is not available, I'll have to look at some service instance >> information that helps me figuring out where to put some object (DNS-SD >> or ZeroConf keep popping up conceptually here in my head). >> >> For case 2 I just need to actually execute the same call for each >> available service instance (like a network broadcast). >> >> For case 3 I need to know somehow (this could be done by a local object >> identity/location mapping) which service instance is responsible (or >> allowed to) manage a specific object. >> >> >> Now, I could code all this inside the ReST layer. However, what I really >> want is to make it abstract in a way that I can hook it into other >> places as well. >> >> So, the initial caller 'A' should just have code like this: >> >> private B b; >> //... >> >> myObjectId = b.create(newObject); >> //... >> >> List objects = b.list(filter, sort, paging); >> //... >> >> myObject = b.get(myObjectId); >> //... >> >> b.updateMetadata(myObjectMetadata); >> //... >> >> b.delete(myObjectId); >> >> >> So that the ReST layer does not even have to know that there is more >> than just one backend. >> >> The magic should be done outside in a generic way if possible, so that I >> could re-use it as it is for other types of services. >> >> >> Does that idea sound familiar to someone? Has that been solved already >> and I just missed something? >> >> I first started with the idea of using an aggregating proxy plus a >> FindHook and stuff, but this imposes the runtime issue that consumers >> need to be refreshed which I want to avoid if possible. >> >> The main problem I think here is to present a single service instance to >> the consumer for which there actually exists no real service >> registration as it is just some kind of invocation handler with a >> specialized purpose (routing/broadcasting service requests). >> >> I would be thankful for any ideas! >> >> >> Thanx, >> >> Ancoron >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] <mailto:[email protected]> >> https://mail.osgi.org/mailman/listinfo/osgi-dev >> <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > _______________________________________________ > OSGi Developer Mail List > [email protected] <mailto:[email protected]> > https://mail.osgi.org/mailman/listinfo/osgi-dev > <https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > > -- > Raymond Augé <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) > Senior Software Architect Liferay, Inc. <http://www.liferay.com/> (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org/> (@OSGiAlliance) > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
