Is it possible to consume a remote OSGi/gRPC service with plain grpc-java?

[eum2o]

For example I have a local Karaf instance on which I deployed the health service example (following the guide on https://github.com/ECF/grpc-RemoteServicesProvider):

karaf@root()> feature:list -i
Name                                  | Version | Required | State   | Repository                     | Description
--------------------------------------+---------+----------+---------+--------------------------------+--------------------------------------------------
...
ecf-rs-examples-grpc-healthcheck-api  | 1.3.2   |          | Started | ecf-remoteservices-grpc-1.3.2  | ECF Remote Services Grpc HealthCheck Example Serv
ecf-rs-examples-grpc-healthcheck-impl | 1.3.2   | x        | Started | ecf-remoteservices-grpc-1.3.2  | ECF Remote Services Grpc HealthCheck Example Serv
...

I then tried to consume the health check service using plain grpc-java. My consumer/client code looks as follows:

import io.grpc.ManagedChannel;
import io.grpc.ManagedChannelBuilder;
import io.grpc.health.v1.HealthCheckRequest;
import io.grpc.health.v1.HealthCheckResponse;
import io.grpc.health.v1.HealthGrpc;

public class Main {

    public static void main(String[] args) {
	System.out.println("Hello I am a gRPC client");

	ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 50002)
		.usePlaintext()
		.build();

	HealthGrpc.HealthBlockingStub client = HealthGrpc.newBlockingStub(channel);
	final HealthCheckResponse check = client.check(HealthCheckRequest.newBuilder()
		.build());
	System.out.println(check.getStatus());

	channel.shutdown();
    }
}

which leads to the following output:

Hello I am a gRPC client
Exception in thread "main" io.grpc.StatusRuntimeException: UNIMPLEMENTED: Method not found: grpc.health.v1.Health/Check
	at io.grpc.stub.ClientCalls.toStatusRuntimeException(ClientCalls.java:262)
	at io.grpc.stub.ClientCalls.getUnchecked(ClientCalls.java:243)
	at io.grpc.stub.ClientCalls.blockingUnaryCall(ClientCalls.java:156)
	at io.grpc.health.v1.HealthGrpc$HealthBlockingStub.check(HealthGrpc.java:251)
	at grpc.java.course.client.Main.main(Main.java:19)

---

PS: If it's possible to consume OSGi/gRPC remote services outside the OSGi ecosystem, is it possible to activate gRPC server reflection on a Karaf instance? E.g. to get an overview of all gRPC services the Karaf instance provides?

(Btw thanks for that awesome feature. It would be awesome if you can reuse your OSGi services from plain java, e.g. by deploying them on Karaf and consuming them using grpc-java.)

[scottslewis]

It was a surprise to me that your non-OSGi client (provided above) didn't work, so I took your program and modified:

package healthchecktest;

import io.grpc.ManagedChannel;
import io.grpc.ManagedChannelBuilder;
import io.grpc.health.v1.HealthCheckGrpc;
import io.grpc.health.v1.HealthCheckRequest;
import io.grpc.health.v1.HealthCheckResponse;

public class Main {

    public static void main(String[] args) {
	System.out.println("Hello I am a gRPC client");

	ManagedChannel channel = ManagedChannelBuilder.forAddress("localhost", 50002)
		.usePlaintext()
		.build();

	HealthCheckGrpc.HealthCheckBlockingStub client = HealthCheckGrpc.newBlockingStub(channel);
	final HealthCheckResponse check = client.check(HealthCheckRequest.newBuilder()
		.build());
	System.out.println(check.getStatus());

	channel.shutdown();
    }
}

Note that it's using the HealthCheckGrpc class (in org.eclipse.ecf.examples.provider.grpc.health.api project) rather than the HealthGrpc class from the original grpc example. I had to modify the package in the proto file (see o.e.e.examples.provider.grpc.health.api/src/main/proto/health.proto) and class naming conventions for the osgi code generation.

After fussing quite a lot with the classpath/modulepath for this example client, I was able to get it to run successfully against an OSGi-based server...exporting the HealthCheckService as per the org.eclipse.ecf.example.provider.grpc.health.impl bundle. I wasn't using Karaf for this test, but it was still an osgi server running and exporting the HealthCheckService via ECF remote service admin.

So...this use case is possible/currently supported! (non-OSGi grpc client with OSGi server exporting a remote service).

Actually, if you agree to the contribution I would like to use your non-osgi client work to create an example java-only HealthCheckService client in this repo and make it available.

PS: If it's possible to consume OSGi/gRPC remote services outside the OSGi ecosystem, is it possible to activate gRPC server reflection on a Karaf instance? E.g. to get an overview of all gRPC services the Karaf instance provides?

Yes! This would be a very nice addition. I would be inclined to a) add grpc-services jar (and ProtoReflectionClass) to the ECF distribution provider, and b) make a few new gogo commands that would allow remote method calls to be made from the osgi gogo console.

I can't do this instantaneously, but I will try to work on it within a few days.

[eum2o]

Note that it's using the HealthCheckGrpc class (in org.eclipse.ecf.examples.provider.grpc.health.api project) rather than the HealthGrpc class

Ah! By using HealthCheckGrpc it now works fine for me, too (without any other changes). Thanks a lot for the fast reply!

So...this use case is possible/currently supported! (non-OSGi grpc client with OSGi server exporting a remote service).

So you basically can consume OSGi remote services with any language supported by gRPC. You only need to download the .proto file, generate the sources and start coding. I think this is huge!

Actually, if you agree to the contribution I would like to use your non-osgi client work to create an example java-only HealthCheckService client in this repo and make it available.

Sure thing! You could write it yourself within seconds I guess - but I think providing an example in this repository and explicitly documenting this feature/use case is a good idea. In fact, for me the main use case for using grpc-RemoteServicesProvider is to connect OSGi services with the non-OSGi-ecosystem. I don't know what's the benefit of consuming an gRPC remote service with an OSGi client. I would think that you can simply use a usual OSGi remote service (without the gRPC stuff). But I am not deep into this. There might be use cases I don't know or understand.

I would be inclined to a) add grpc-services jar (and ProtoReflectionClass) to the ECF distribution provider, and b) make a few new gogo commands that would allow remote method calls to be made from the osgi gogo console

Sounds great (especially a) for me in personal). Take your time.

[scottslewis]

> So you basically can consume OSGi remote services with [any language supported by gRPC](https://grpc.io/docs/languages/). You only need to download the .proto file, generate the sources and start coding. I think this is huge!

I agree this is very cool. If you do any experimenting with other languages please consider contributing them back (for healthcheck) and I will add to this (or new) repo so that it's easier for people to give a try.

Actually, if you agree to the contribution I would like to use your non-osgi client work to create an example java-only HealthCheckService client in this repo and make it available.

Sure thing! You could write it yourself within seconds I guess - but I think providing an example in this repository and explicitly documenting this feature/use case is a good idea. In fact, for me the main use case for using grpc-RemoteServicesProvider is to connect OSGi services with the non-OSGi-ecosystem. I don't know what's the benefit of consuming an gRPC remote service with an OSGi client.

A common use case with other providers is Eclipse (and Eclipse RCP apps) as OSGi clients. I don't see a reason why (e.g.) existing grpc services (osgi or not) might want to have such OSGi clients also. But...nice thing is this is supported as well.

[scottslewis]

Hi Martin. It seems like it's going to be pretty easy to setup the ProtoReflectionService in the ECF grpc distribution provider. Actually I'm ready to try it out locally but I need the grpc_cli tool...and the grpc team doesn't distribute binaries for grpc_cli....and I don't currently have everything setup to build it on my win64 system. Would you happen to have a built grpc_cli.exe for win64? If so could you allow me to download it and use it for testing? Thanks.

[eum2o]

Unfortunately, I don't have a built grpc_cli tool available. In fact, I tried to build it on my win64 system following their instructions but sadly I didn't manage to succeed (make throws errors due to missing files but don't wanna bother you with details).

However, if you ask for grpc_cli to test the reflection service, let me recommend you Evans:

For example if you have a gRPC server running on port 50002 you can run

evans -r -p 50002

If no error is printed, you already have verified that the reflection service is working. After that, in the Evans console, you can e.g. type*

show service

which, in case the HealthCheck service is deployed/distributed, should lead to an output like the following:

+-------------+-------------+--------------------+---------------------+
|   SERVICE   |     RPC     |    REQUEST TYPE    |    RESPONSE TYPE    |
+-------------+-------------+--------------------+---------------------+
| HealthCheck | Check       | HealthCheckRequest | HealthCheckResponse |
| HealthCheck | WatchServer | HealthCheckRequest | HealthCheckResponse |
| HealthCheck | WatchClient | HealthCheckRequest | HealthCheckResponse |
| HealthCheck | WatchBidi   | HealthCheckRequest | HealthCheckResponse |
+-------------+-------------+--------------------+---------------------+

After that you can type service HealthCheck led by call Check to call the check method for example.

---

[*]: show service will only work if there is just 1 package (e.g. io.grpc.health.v1 on your gRPC server). If there are multiple packages in your test instance, you would first have to type show package and then go into your HealthCheck package, e.g. with something like package io.grpc.health.v1. After that show service lists all services in that package.

[scottslewis]

Unfortunately, I don't have a built grpc_cli tool available. In fact, I tried to build it on my win64 system following their instructions but sadly I didn't manage to succeed (make throws errors due to missing files but don't wanna bother you with details).

However, if you ask for grpc_cli to test the reflection service, let me recommend you Evans:

Thanks...Evans seems pretty cool.

I've updated the grpc distribution provider and target platform to use grpc 1.36.1 (has ProtoReflectionService), and I've been able to add and successfully test the modified disttribution provider (GrpcHostContainer class) with the ProtoReflectionService via Evans! It works pretty nicely with the HealthCheck example as you describe.

I update the grpc distribution provider features from 1.3.2 -> 1.4.0. I would like to do a little more testing before doing the 1.4.0 release, however. I would appreciated it if you would give it a try. I've made it so that the proto reflection service can be turned on via the following system (or service) property: -Decf.grpc.server.protoReflectionService=true. It's default is off (false).

You can also specify this service property: ecf.grpc.server.protoReflectionService=true for an exported service to turn it on as well.

Please let me know if/when you have a chance to try it and I'll get 1.4.0 released.

[eum2o]

I performed some happy day test scenario and it works fine!

How I set up the test environment

I am mentioning this especially to see if this is the way you expected me to test or if I am missing something. I first was looking for a build I can use for testing (some v1.4.0 JAR). But I think I had to build it myself (which generally is no problem - I just wasn't sure if this is the way to go - e.g. should I have used the launch configs?).

1. I cloned your repo
2. I locally built bundles/org.eclipse.ecf.provider.grpc with mvn clean install
3. I locally modified build/karaf-features.xml:
   • Replaced <bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/org.eclipse.ecf.provider.grpc_1.3.0.202009261541.jar with <bundle>mvn:org.eclipse.ecf.provider.grpc/org.eclipse.ecf.provider.grpc
   • Replaced versions 1.3.3 and 1.3.2 with 1.4.0
4. Locally started Karaf and in the console I ran:
   • repo-add file:/pathToClonedRepo/build/karaf-features.xml
   • feature:install -v ecf-rs-distribution-grpc
   • feature:list -i to verify v1.4.0 of ecf-rs-distribution-grpc was installed
   • <Install my own service with the ecf.grpc.server.protoReflectionService property set to true>

Test Result

I now can use Evans to discover all gRPC services that are provided by my Kraraf instance. Calling them works fine, too (tested a unary call only). This is a great feature, thanks for that!

During testing I was wondering if it could be useful to create a dedicated bundle providing the ProtoReflectionService instead of adding it when org.eclipse.ecf.provider.grpc is started. This way you could start/stop this dedicated bundle in Karaf to enable/disable gRPC reflection on demand. What do you think?

[scottslewis]

a unary call only). This is a great feature, thanks for that!

You are welcome.

During testing I was wondering if it could be useful to create a dedicated bundle providing the ProtoReflectionService instead of adding it when org.eclipse.ecf.provider.grpc is started. This way you could start/stop this dedicated bundle in Karaf to enable/disable gRPC reflection on demand. What do you think?

I did add a new bundle: org.eclipse.ecf.provider.grpc.console. This bundle extends the gogo osgi console by adding new commands for dynamically controlling the ProtoReflectionService on 1 or more GRPCHostContainer instances. See the commit notes on this commit:

0751118

I'm pretty happy with it this way...it allows custom defaults for each container instance (via either system property or service property...which is still there), and now with the gogo commands the protoreflectionservice can be added or removed dynamically at any time. Further, the console can be left out entirely...if it's not needed for deployment.

I still need to add the new bundle to parts of the build (e.g. the karaf-features.xml).

Let me know what you think...and if you like I'll get 1.4.0 out.

[eum2o]

0751118

This is nice. If the commands are working as described I think it makes the reflection feature complete and it's ready to release from my perspective.

Unfortunately I didn't manage to test it. I locally built org.eclipse.ecf.provider.grpc and org.eclipse.ecf.provider.grpc.console (for the console bundle I had to add a dependency to org.eclipse.osgi.services, otherwise the tycho-compiler-plugin complains about unresolveable org.osgi imports (@component, @reference)). After that I added the following repository to karaf (repo-add file:/path..):

<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0" name="ecf-rs-distribution-grpc-1.4.0">

    <repository>http://download.eclipse.org/rt/ecf/RELEASE/site.p2/karaf-features.xml</repository>

<feature name="ecf-rs-distribution-grpc-support" version="1.4.0"
	description="ECF Remote Services Grpc Distribution Provider Support. See https://github.com/ECF/grpc-RemoteServicesProvider">
	<feature>ecf-rs-rsa</feature>
	<feature>ecf-rs-console</feature>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/com.google.gson_2.7.0.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/com.google.guava_26.0.0.android.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/com.google.guava.failureaccess_1.0.1.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/com.google.protobuf_4.0.0.rc-2.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/com.salesforce.servicelibs.reactive-grpc-common_1.0.1.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/com.salesforce.servicelibs.rxgrpc-stub_1.0.1.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.buffer_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.codec_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.codec-http_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.codec-http2_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.codec-socks_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.common_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.handler_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.handler-proxy_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.resolver_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.netty.transport_4.1.52.Final.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/io.reactivex.rxjava2.rxjava_2.2.19.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/org.reactivestreams.reactive-streams_1.0.3.jar</bundle>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/org.jsr-305_3.0.2.jar</bundle>
	</feature>
	
	<feature name="ecf-rs-distribution-grpc"
		version="1.4.0"
		description="ECF Remote Services Grpc Distribution Provider. See https://github.com/ECF/grpc-RemoteServicesProvider">
		<feature>ecf-rs-distribution-grpc-support</feature>
		<bundle>mvn:org.eclipse.ecf.provider.grpc/org.eclipse.ecf.provider.grpc
		</bundle>
		<bundle>mvn:org.eclipse.ecf.provider.grpc/org.eclipse.ecf.provider.grpc.console
		</bundle>
	</feature>

	<feature name="ecf-rs-examples-grpc-healthcheck-api" version="1.2.0"
		description="ECF Remote Services Grpc HealthCheck Example Service API.  See https://github.com/ECF/grpc-RemoteServicesProvider">
		<feature version="1.2.0">ecf-rs-distribution-grpc</feature>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/org.eclipse.ecf.examples.provider.grpc.health.api_1.2.0.202009261541.jar
		</bundle>
	</feature>

	<feature name="ecf-rs-examples-grpc-healthcheck-impl"
		version="1.2.0"
		description="ECF Remote Services Grpc HealthCheck Example Service Host.  See https://github.com/ECF/grpc-RemoteServicesProvider">
		<feature version="1.2.0">ecf-rs-examples-grpc-healthcheck-api</feature>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/org.eclipse.ecf.examples.provider.grpc.health.impl_1.1.0.202009261541.jar
		</bundle>
	</feature>

	<feature name="ecf-rs-examples-grpc-healthcheck-consumer"
		version="1.2.0"
		description="ECF Remote Services Grpc HealthCheck Example Service Consumer.  See https://github.com/ECF/grpc-RemoteServicesProvider">
		<feature version="1.2.0">ecf-rs-examples-grpc-healthcheck-api</feature>
		<bundle>https://raw.githubusercontent.com/ECF/grpc-RemoteServicesProvider/master/build/plugins/org.eclipse.ecf.examples.provider.grpc.health.consumer_1.1.0.202009261541.jar
		</bundle>
	</feature>

</features>

The command feature:install -v ecf-rs-distribution-grpc then leads to the following error:

Error executing command: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=ecf-rs-distribution-grpc; type=karaf.feature; version="[1.4.0,1.4.0]"; filter:="(&(osgi.identity=ecf-rs-distribution-grpc)(type=karaf.feature)(version>=1.4.0)(version<=1.4.0))" [caused by: Unable to resolve ecf-rs-distribution-grpc/1.4.0: missing requirement [ecf-rs-distribution-grpc/1.4.0] osgi.identity; osgi.identity=org.eclipse.ecf.provider.grpc.console; type=osgi.bundle; version="[1.0.0.v20210406-0719,1.0.0.v20210406-0719]"; resolution:=mandatory [caused by: Unable to resolve org.eclipse.ecf.provider.grpc.console/1.0.0.v20210406-0719: missing requirement [org.eclipse.ecf.provider.grpc.console/1.0.0.v20210406-0719] osgi.wiring.bundle; osgi.wiring.bundle=org.apache.felix.gogo.runtime; bundle-version=1.1.0; filter:="(&(osgi.wiring.bundle=org.apache.felix.gogo.runtime)(bundle-version>=1.1.0))"]]

Apparently, I lack the org.apache.felix.gogo.runtime bundle in my Karaf instance. I am a Karaf newbie but from my understanding, Karaf uses/builds upon the gogo console so I would expect the gogo runtime already pre-installed. Nevertheless, I tried to fix this problem by installing the features shell and shell-compat. But installing these hasn't fixed the problem. Can you give me a hint what I'm doing wrong or where I can get the gogo runtime bundle from?

I am using Apache Karaf (4.3.0).

[scottslewis]

> > Apparently, I lack the `org.apache.felix.gogo.runtime` bundle in my Karaf instance. I am a Karaf newbie but from my understanding, Karaf uses/builds upon the gogo console so I would expect the gogo runtime already pre-installed. Nevertheless, I tried to fix this problem by installing the features `shell` and `shell-compat`. But installing these hasn't fixed the problem. Can you give me a hint what I'm doing wrong or where I can get the gogo runtime bundle from? > > I am using Apache Karaf (4.3.0).

--

For Karaf, I imported the wrong thing in org.eclipse.ecf.provider.grpc.console. It worked for my testing in Eclipse/Equinox (localhost) because Eclipse uses gogo directly, while Karaf has it's own implementation. I've fixed so that it should work for both and pushed the fix to master.

Your testing is not wasted, however...please just consider this release testing for 1.4.0. Thanks (and inadvance) for that as it's definitely speeding up the release process.

[eum2o]

At this moment the latest commit is dd03903.

• ✅ The console bundle can now be compiled with tycho
• ✅ Both org.eclipse.ecf.provider.grpc and org.eclipse.ecf.provider.grpc.console can be installed to Karaf (all dependencies found)
• ✅ Reflection service can now be activated/deactivated on demand (tested all 4 commands and they work as specified - //edit: haven't tested the optional parameters, tho)

Thanks again for all the cool features! For my use case this is everything I need. I am looking forward to the 1.4 release :)

[scottslewis]

Thanks for the testing and review.

In preparation for release of 1.4, I've created a new issue to detail this new protoReflectionService feature and begin documentation:

#9

If you have things to add (other things I've forgotten about this feature) or other issues that you want in 1.4 please add to that issue or create new issue as appropriate.

Thanks again for the idea for this. I think it will be a nice addition for debugging and testing...especially with non OSGi consumers.

I also created this new issue to capture the desire for examples of non-OSGi consumers (java and other langs) for grpc-exported OSGi Remote Service.

#10

[scottslewis]

I'm going to close this issue in favor of these others. Again...thanks.