Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [science-iwg] java <-> python service bridge

My general feeling is that implementing all script services + modules
as 1st class OSGi services would be a great move. For Python and
others, using ECF to wire them up would be great.

As for the location of this, it seems that ECF is the logic choice for
hosting the transport and the wiring up at the java level. However I
think EASE is a logical place to host the process launching, remove
service creation, etc.

Jonah
~~~
Jonah Graham
Kichwa Coders Ltd.
www.kichwacoders.com


On 18 July 2016 at 19:57, Christian Pontesegger
<christian.pontesegger@xxxxxx> wrote:
> Hi Scott,
>
> this is an interesting idea you bring up here. For me the first question
> would be "do we have to stick to Py4J"?. Maybe in a more general form this
> could be applicable to any script engine hooked into EASE. Then it would be
> a clear candidate to push this into the core framework.
>
> If it stays limited to the Py4J bridge then our modules repository could
> provide a home for that functionality. I would love to hear Jonahs thoughts
> about this topic. This topic would also need a maintainer and tester. Would
> you step up for that?
>
> Christian
>
>
> On 07/14/2016 06:00 PM, Scott Lewis wrote:
>
> Hi Folks,
>
> Currently with Eclipse EASE it's easy :) to script Eclipse with Python.
> What's not currently as easy to do is:
>
> 1) Allow python code to access/call OSGi services
>
> 2) Allow java code to discover and call python-based services (without an
> explicitly registered listener)
>
> 3) Support the dynamics of OSGi services (services come and go at runtime,
> binding by DS or Spring, etc)
>
> I've recently been working on a thing I call a 'service bridge' [1] that
> using Py4j it bridges Python with the OSGi service registry.   It does this
> by creating a Py4j-based distribution provider for ECF's implementation of
> OSGi Remote Services [2].
>
> The service bridge enables all three of the above, and does it in a
> standards-based (RSA) way.   For example, for 2 let's say we have a python
> class:
>
> class EvalProvider(object):
>
>     def eval(self, expression):
>         'parse expression, evaluate (parse function above) and return as
> float/Double'
>         return float(parse(expression))
>
>     class Java:
>         implements = ['com.acme.prime.eval.api.Eval']
>
>
> with the Py4jServiceBridge we make the following call:
>
> Py4jServiceBridge.export(new EvalProvider(),rsaProps)
>
> and on the java side a proxy will be created (with all the OSGi classloading
> restrictions taken care of) and dynamically registered in the OSGi service
> registry...meaning that consumers of the com.acme.prime.eval.api.Eval
> service will have this instance injected and can use it:
>
>     @Reference(policy=ReferencePolicy.DYNAMIC)
>     void bindEval(Eval svc) {
>             System.out.println("EvalConsumer returns="+svc.eval("21+21"));
>     }
>
> Here's the java-side service Eval service interface:
>
> public interface Eval {
>     double eval(String expression) throws Exception;
> }
>
> and the Python eval expression will be called...and can execute arbitrary
> Python code (any Python impl).    This will work similarly for any service
> (not just Eval :).   There is nothing on either side that requires service
> consumers to care that the implementation is provided by Python (or Java).
> If necessary it can be figured out, but consumers are not required to write
> any custom code, making it easy to switch between languages for service
> impls and even distribution systems (e.g. switching to xmlrpc, rest,
> hazelcast, or some other network distribution provider [3]).
>
> All the dynamics are supported without app-level code...e.g. services come
> and go at runtime, are cleaned up on shutdown, multi-threaded access, etc
> thanks to RSA.
>
> Conversely, if a service is registered in java/Eclipse (any method...via DS,
> registerService, etc), on the python side it can be configured so that a
> listener will be dynamically called to inject the service into python code.
>
> I'm trying to determine how to contribute this...it could be through ECF,
> EASE, January, new project, or other.   One thing to mention:  it's only
> dependent on OSGi, and so will of course work in Eclipse IDE, Che, Orion,
> any RCP app, as well as OSGi servers...Karaf, Websphere and others.  If you
> have thoughts about how you would like to consume please LMK.
>
> Scott
>
> [1] https://github.com/ECF/Py4j-RemoteServicesProvider
>
> [2]
> https://wiki.eclipse.org/Eclipse_Communication_Framework_Project#OSGi_Remote_Services
>
> [3] https://wiki.eclipse.org/Distribution_Providers
>
>
>
>
>
>
>
> _______________________________________________
> science-iwg mailing list
> science-iwg@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from
> this list, visit
> https://dev.eclipse.org/mailman/listinfo/science-iwg
>
>


Back to the top