On 12/31/2014 06:23 AM, Bernd Eckenfels wrote:
> Hello,
>
> I would use a Servie Interface which is implemented by all real
> backends and by a virtual backend. The Rest endpoint will look up the
> prefered (virtual) service.
>
> The virtual service would contain the parallel/decision/routing logic
> and dispatch to the actual backends. It needs to discover the backend
> services dynamically, so there is no need to refresh it at all.
>
> This way your routing logic is in its own service, the rest and the
> backend servides do not know anything about it, and in a specific
> usecase (testing) you could still use a direct rest->local-backend
> instead of rest->dispatcher->(local,remote)-backend chain.
>
> Gruss
> Bernd
Hi Bernd,
thank you for the idea with the virtual service.
I was just considering something similar using a generic service for the
"orchestration" part:
interface Routing<T> {
T get();
}
...where an implementation would just return a proxy that implements the
specific logic.
So, the ReST layer would import a service such as:
private Routing<DataService> dataRouting;
...and then would do things like:
dataRouting.get().create(newObject);
On the other hand, I really would like to keep even the awareness of the
routing part outside of the consumer level.
I see some similarities here to the ManagedServiceFactory, which is
supposed to create different service instances of the same type.
However, the most tricky part for me is to provide the most convenient
and least error-prone (non-hackish) way for actual service consumers,
which should only see one single service instance - no matter what. As
soon as a "router" is registered for a service interface, no consumer
should be allowed to get some concrete service instance.
Apart from the FindHook thingy I didn't find anything that would allow
me doing that.
Of course, I could probably work with start-levels to ensure that this
FindHook is installed before any consumers get resolved, but I only use
that for temporary workarounds, not as part of a solution.
Thanx,
Ancoron
>
>
> Am Tue, 30 Dec 2014 23:49:06 +0100
> schrieb Ancoron Luciferis <[email protected]>:
>
>> 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
>
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
