[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [osgi-technology-dev] Python <-> Java Integration via OSGi Remote Services
|
On 7/9/2024 12:37 PM, Scott Lewis via
osgi-technology-dev wrote:
There are 3 other features in the Python.Java distribution
provider that have not been completely documented yet. If
interested in another email describing those features please
just respond to this posting positively and I will describe
these features with example code references from [1].
I've decided to publicly describe these three additional features
now, as I have some time now and it's better for potential
consumers of this work to know about these features. These
features are in *addition* to the general interaction between
Python and Java via Remote Services provided by [1].
Feature 1: There is a 'direct' abstraction layer that allows use
of alternatives to Py4j for the actual inter-process
communication. This allows flexibility in creating custom
distribution providers that are based upon other transports.
Feature 2: Google Protocol Buffers for object serialization.
One of the important components of any distribution implementation
is the object serialization/de-serialization used. It naturally
affects runtime performance, interoperability, security, and
reliability. Google's protocol buffers [i] is a popular,
performant, language-neutral approach, and the current
implementation at [1] optionally supports/uses protocol buffers.
There is a protobuf-using example here [ii].
Feature 3: Via python's path import hook, osgiservicebridge
allows java/osgi service instances to provide python modules (and
arbitrary python code) to the connected python process. For
example, here [iii] is python code inside a java bundle, that via
the osgiservicebridge and the python path hook, be available for
import in bridge-connected python process. Here [iv] is a python
code example 'import foo' imports the module and code in module to
the java/osgi bundle. This can/could be used in a number of
ways...e.g. using osgi versioning and resolver to manage python
module resolution.
Any questions or comments are welcome of course.
Scott
[i] https://protobuf.dev/
[ii]
https://github.com/ECF/Py4j-RemoteServicesProvider/tree/master/examples
(protobuf.hello.javahost and consumer projects)
[iii]
https://github.com/ECF/Py4j-RemoteServicesProvider/tree/master/examples/org.eclipse.ecf.examples.importhook.module/python-src/foo/bar
[iv]
https://github.com/ECF/Py4j-RemoteServicesProvider/blob/master/examples/org.eclipse.ecf.examples.importhook.main/src/run.py
Thanks,
Scott
[A] https://ipopo.readthedocs.io/en/1.0.1/
[B] https://ipopo.readthedocs.io/en/1.0.1/tutorials/rsa_pythonjava.html#
On 7/9/2024 4:34 AM, Dr. James J.
Hunt via osgi-technology-dev wrote:
Dear Colleagues,
I find this project interesting to have integrated into
OSGi. We are generally interested in extending the OSGi model
to code running outside a JVM and this goes in that
direction. If we can add contributors, even better.
Sincerely,
James
On 7/8/24 17:10, Scott Lewis via
osgi-technology-dev wrote:
On
7/8/2024 5:06 AM, Mark Hoffmann via osgi-technology-dev wrote:
Hi Scott,
thank you for this request. In general we are interested
having such a provider that allows communication between
Python and Java via Remote Services.
We already doing that as well in a custom component to
trigger ML applications, that are implemented in Python.
So, having a distribution provider would be nice.
I have seen the Py4J project made its last release in 2022.
Is there still something happening in that project?
I'm aware that the primary maintainer for many years
(Barthelemy Dagenais) stepped away from that role a couple of
years ago, but that others (Apache Spark committers, Eclipse
Foundation committers such as Jonah Graham, who is a committer
on several Eclipse projects) have taken up that maintenance
mantle. In my usage for implementing a distribution
provider, I've not found any major problems so far.
Just to get it right, the contribution would consist of
Python and Java components?
Yes. The repo I've provided has several osgi bundles, and
the primary python component (in that repo) is the
osgiservicebridge, which is available via pip.
Just to be clear, some years ago I also contributed a full
python-side RS/RSA implementation to the iPopo project. https://ipopo.readthedocs.io/en/1.0.1/
in rsa package. This python impl of the pelix/ipopo/RSA
implementation depends upon osgiservicebridge.
It would be great, if we could discuss
that topic, maybe in one of the next specification calls. I
would clarify that. Anyway, you are always invited to
participate these calls.
Please let me know when this is to be discussed and I'll see
if I can attend. I would prefer written questions and
answers, however...either here or some other appropriate
forum.
Scott
Regards,
Mark
Am 04.07.24 um 05:45 schrieb Scott Lewis via
osgi-technology-dev:
Howdy,
For many years, the ECF project has had an implementation
of the OSGi Remote Services (100) and Remote Service Admin
(122) specifications. I believe ECF's RS/RSA impl is
currently still used in the OSGi compatibility test suite.
One of our distribution providers enables remote services
between Java and Python[1]. It uses the Py4j protocol to
do this. Py4j is an open source project [2] that is used
for Apache Spark on the server-side (I believe), Eclipse
EASE project, and other projects and products/services.
As per the OSGi Remote Services specification, a service
registry exists in both the Java and Python processes, and
the distribution provider connects them (via
osgi-standardized meta-data aka the endpoint description)
to export and import services between the two processes.
[1] has all the Java and Python components to implement
this distribution provider, along with some utilities and
examples. This distribution provider can also use Google
protocol buffers as the serialization mechanism and so it
happens to work well with the both gRPC (based upon
protocol buffers) and bndtools-based grpc tooling [3].
If there is interest and community support I would be
willing to contribute this distribution provider to the
Eclipse community, perhaps as an effort to integrate java
and python-based services and apps at the service level
for a broader 'artificial intelligence' effort at Eclipse.
Scott
[1] https://github.com/ECF/Py4j-RemoteServicesProvider/
[2] https://www.py4j.org/
[3] https://github.com/ECF/grpc-RemoteServicesProvider
_______________________________________________
osgi-technology-dev mailing list
osgi-technology-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________
osgi-technology-dev mailing list
osgi-technology-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
--
Dr. James J. Hunt
CEO & Geschäftsführer
aicas GmbH
Emmy-Noether-Straße 9 ● 76131 Karlsruhe ● Germany
https://www.aicas.com ● Tel: +49
721 663968 22
USt-Id: DE216375633, Handelsregister HRB 109481, AG Mannheim
Geschäftsführer: Dr. James J. Hunt
aicas incorporated
6 Landmark Sq., Ste 400 ● Stamford, CT 06901 ● USA
https://www.aicas.com ● Tel: +1
203 435 0521
aicas America limited
4023 Kennett Pike, Ste 810 ● Wilmington, DE 19807 ● USA
https://www.aicas.com ● Tel: +1
203 435 0521
_______________________________________________
osgi-technology-dev mailing list
osgi-technology-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
_______________________________________________
osgi-technology-dev mailing list
osgi-technology-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org