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]> 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
>
> Let me know if this works for you.
>
> Kind regards,
>
> Peter Kriens
>
>
>
> On 30 dec. 2014, at 23:49, Ancoron Luciferis <
> [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]
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> [email protected]
> 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
