[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [science-iwg] java <-> python service bridge
|
Hi Christian,
On 7/18/2016 11:57 AM, Christian Pontesegger 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"?.
Answer: No, not at all.
Explanation: At the service (top) level, this is simply using OSGi
Remote Service Admin specification to hook up any two processes (one of
them typically java+OSGi framework, but even this isn't actually required).
Since ECF's RSA implementation has a 'pluggable distribution provider'
approach (see [1] for diagram), it's straightforward to use Py4j to
create a new distribution provider (that's what I've done here [2]).
[1] http://wiki.eclipse.org/OSGi_Remote_Services_and_ECF
[2] https://github.com/ECF/Py4j-RemoteServicesProvider
In short, if other languages were to be supported with the same approach
(why not?) then they could do a similar thing. Each one would need
it's own distribution provider, but they could all operate in a similar
manner as specified by RSA.
But also: for the science working group the use case of OSGi services
between Java and Python (both ways)...and the benefits of dynamics, and
the availability of Py4j...it seemed like a good way to go.
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.
I would say that that general form is the OSGi RSA specification...as it
does specify the syntax and contents of an 'Endpoint Description' which
is used to communicate about services between processes.
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?
My $0.03: the RSA impl upon which this is based belongs in ECF (where
it is now). It's the distribution provider[2] that's a question.
That provider depends upon Py4j libs for both the Java side and Python
side, and it depends upon the ECF RSA impl (on java side). Given this,
I think the first question is location, licensing and distribution for
Py4j...as I'm pretty flexible about where [2] ends up, who maintains it,
and how it's licensed. Further, there's a chance I can/would offer to
support it as a committer on EASE or January if some means of supporting
that could be found.
Scott
