Is it possible to remotely expose a bean in spring boot using REST and httpInvoker
Asked Answered
N

6

12

I need to expose some service for remote use by Java clients (they shall use httpinvoker) and other languages (they shall use REST).

Can I configure spring boot to expose both ? (I would not mind if two separate instances with different ports would be used, like in this post).

I dumped the idea of providing an API for the Java clients that internally uses REST because it is rather tedious to wire all REST endpoints into the code manually using RestTemplate. I like the concept of HttpInvoker because a ProxyFactoryBean gets used automagically. If Spring Remoting would be able to do this in a way it can be done for JMS, AMQP and the others I would head this way.

Negligible answered 21/4, 2015 at 20:17 Comment(5)
You're mixing probably two idioms: RPC and state transfer. httpInvoker is about remote procedure calls. You call simply a method, pass in some arguments and get some sort of result. In REST you're dealing pretty much with changing a particular state of something (it's basically the REST idea). I guess, the best solution for such a case would be having two different facades in front of your service which follow the principles of each API style.Aargau
I think both techniques allow to change the state. In REST it is a http GET, with httpInvoker you call a getMethod. For modifying/creating values REST uses PUT/POST and httpInvoker calls set/create. But when you are talking about the two facades this is where it get's interesting: how can this be done in an elegant way ?Negligible
@Negligible why would you want to use a deprecated tool like Spring's HttpInvoker? It was already deprecated in Spring 2.0, I don't think Spring Boot will autoconfigure that or even manage the dependency.Monroe
I did not yet check support for httpinvoker in spring boot, so missing support from boot might become an issue. Do you have a source for the deprecation of httpinvoker ? I know its support was changed in spring integration but I consider it as actively supported even in current versions of springNegligible
Cant you configure your bean as a usual Rest service and expose it using httpinvoker? HttpInvoker configuration is pretty simple and you could do it by yourself without SpringBootMoorings
C
3

You can use something like this. Expose your services as a rest service. Then make your java clients to consume those services using http or some other library. If any other party is interested also, they can consume it in their own way too.

Else you can create your own jar consuming your rest services and let your java clients use that, without the knowledge about the rest service.

Case answered 24/4, 2015 at 7:12 Comment(1)
Creating a jar that calls the REST interface is the approach I dumped. I seek an easy approach where the biggest part gets created automatically. This works for httpinvoker and REST when I use each technique isolatedly.Negligible
L
3

Exposing HTTP invoker endpoints in Spring Boot is actually so easy that it looks as if something was missing. In a @SpringBootApplication that has spring-webmvc on its path (for instance using the spring-boot-starter-web POM), add the following bean definition:

@Bean(name = "/my.service")
public HttpInvokerServiceExporter myHttpInvokerServiceExporter(MyService myServiceImpl) {
    HttpInvokerServiceExporter exporter = new HttpInvokerServiceExporter();
    exporter.setServiceInterface(MyService.class);
    exporter.setService(myServiceImpl);
    return exporter;
}

The HTTP invoker endpoint is now exposed at /my.service and will not affect any other mappings. You can add as many such endpoint as you want; and then some @RequestMappings for REST on top.

Lifelong answered 6/6, 2016 at 13:38 Comment(0)
L
3

Spring HTTP Invoker is dangerous to be used in case when the trust of the caller can't be verified. It is deprecated from quite a long time and its support will be removed in Spring 6 so don't use it.

It's best to implement the communication as REST call and wrap it in easy to use method, like some other answers suggest, i.e. the Maleen Abewardana's one - https://mcmap.net/q/936795/-is-it-possible-to-remotely-expose-a-bean-in-spring-boot-using-rest-and-httpinvoker.

References:

P.S. Yes, I know this question is very old and I'm sure OP doesn't need the answer anymore, but I write it with all the other future readers in mind, so that they don't use Spring HTTP Invoker nor any other RPC/RMI-like Spring features.

Luann answered 28/2, 2023 at 13:33 Comment(0)
P
2

We use both techniques here. HttpInvoker for Java-to-Java invocations. Plain-old JSON over HTTP for other clients (similar to REST but not true REST). I think that the project jsonrpc4j provides a nice way to implement the HTTP stuff.

Pompom answered 8/9, 2015 at 22:28 Comment(0)
P
2

Have a look at the spring-rest-invoker. It binds Java interfaces to REST services. This doesn't solve the problem of "exposing" the service, but makes it much easier to consume it.

https://github.com/ggeorgovassilis/spring-rest-invoker

Pannell answered 9/8, 2017 at 5:20 Comment(0)
E
0

HttpInvoker was dropped after spring-integration 2.x: http://docs.spring.io/spring-integration/docs/2.0.x/reference/html/httpinvoker.html (!Important header gives details). There is a reference to HTTP Support in 3.x and 4.x versions: http://docs.spring.io/spring-integration/docs/latest-ga/reference/html/http.html

There is also another SO post with someone asking about HTTP support and spring boot with some relevant information: Spring Integration Http with Spring Boot and @RequestMapping

Hopefully this gets you part of the way out of the rabbit hole.

Electronic answered 30/4, 2015 at 19:34 Comment(2)
Perhaps I am misinterpreting this but just because Spring Integration drops support for the HttpInvoker it does not meen that Sprint itself dropped or deprecated it. Because I am not using Spring Integration I should not run into problems.Negligible
Yes... you are correct. docs.spring.io/spring/docs/current/spring-framework-reference/…Electronic

© 2022 - 2024 — McMap. All rights reserved.