Huh? This is a perfect example of the OSGi service model. Why on earth would
you drag in RSA? Of course RSA is lovely when you ant to run your backend
handler on another OSGi framework but RSA/Distributed OSGi seems to be as
orthogonal as you can get to the original question? Or am I missing something?
Kind regards,
Peter Kriens
> On 1 jan. 2015, at 03:16, Scott Lewis <[email protected]> wrote:
>
> Howdy,
>
> On 12/30/2014 2:49 PM, Ancoron Luciferis 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!
>
> Full disclosure: I'm on the ECF [1] project team.
>
> One approach that might suit your use case: Remote Services/Remote Service
> Admin - defined by chapters 100 and and 122 in the OSGi R6 enterprise
> specification.
>
> Remote Services expose an OSGi service (e.g. instances of 'B' in your example
> above) for remote access. The specification defines standard service
> properties that trigger the export of a service, but the spec intentionally
> does not define the underlying distribution provider or transport. Rather,
> one of the standard service properties (config type) allows the distribution
> provider to be selected at service registration time.
>
> ECF's [1] implementation of remote services [2] allows new providers to be
> easily created to customize the service proxy behavior...so that, for
> example, an existing or new REST API can/could be used to implement the proxy
> calls. There is a recently created tutorial [3] with an example how to
> customize the proxy for accessing a pre-existing REST service. You could
> easily create a custom distribution provider and use whatever
> distribution/transport you wished...and/or change the distribution provider
> over time....without changing the actual service interface 'B', or any code
> that uses B.
>
> Also, the RSA spec defines a standard discovery metadata format (called EDEF,
> for Endpoint Description Extender Format) for publishing and dynamically
> discovering remote services. ECF's impl of this spec allows plugging in a
> discovery module of choice, e.g. zookeeper, zeroconf, dnssd, etcd are already
> available as part of ECF, or you can create/plugin a custom discovery module
> if you wish.
>
> Hope this helps.
>
> Scott
>
> [1] http://www.eclipse.org/ecf
> [2] https://wiki.eclipse.org/ECF#OSGi_Remote_Services
> [3]
> https://wiki.eclipse.org/Tutorial:_ECF_Remote_Services_for_Accessing_Existing_REST_Services
>
>
> _______________________________________________
> 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
