New Remoting Strategy: HTTP Invoker

[tcollins]

Will the new "HTTP Invoker" remoting strategy be included in the new Spring 1.1 release?

Thanks

[Colin Sampaleanu]

Yes, including an example of usage in the JPetstore sample app.

Regards,

[Martin Kersten]

Boy this was it, I am actually was trying to sell to the Spring people half a year ago and again three month ago. Never got any positive reply on this. That were some lines, you didn't needed to write after all. :-(

But I will check the implementation. My implementation also provides a socket connection support. I find using sockets for client programming and server interaction more reliable, since you can attach session attributes on a per connection base very easily.

So I guess it shouldn't called 'Http Invoker' after all. Using serialization for invokation is more general and should be named in more general. I refer to it as simple remote procedure call - SimpleRPC currently.

Boy, I had this all ready half a year ago. It's a pitty.


I think this kind of invocation using serialization should be a stand alone API since I guess many more applications may profitate from such a kind, but I was to bussy to set up a project by myself. So if someone would like to add such a small and lovely API to the open source community, just give me a call. Currently it is about 15kb and 6kb on Client side, I think. I guess this is best for Server<-->Applet/Client communication.

Any thoughts on that?

PS: I am strongly against calling this HttpInvoker. It isn't about http after all. It's more about invokation, http is simple one protocol for using this. Or do you plan a SocketInvoker too?

PSS: It's really a pitty, what a waste... .

[Colin Sampaleanu]

Martin,

What can I say, there is a lot of stuff going on all the time, and some stuff does slip through the cracks. For what it's worth, I can't find any emails from you on the dev (or user) mailing lists, so if you discussed this with anybody I don't think it's somewhere I would have seen it.

For anybody who has written code to add onto Spring, the best thing to do is stick it in the Jira bug tracker so it doesn't get lost, and then start discussing it on the dev list, where new features are theoretically hashed out at least to some extent.

Regards,

[Martin Kersten]

Well sadly I used the sourceforge forum about this issue... maybe the wrong one. But I stated it out clearly what it is all about I think. You know serialization + method invocation. Anyway I would still suggest to think about calling it HttpInvoker.

Maybe I should drop a mail within the dev-maillist, shouldn't I?

[Colin Sampaleanu]

That's by far the best place (along with an entry in Jira, for code, and enhancement requests). This is actually Juergen's code, and I think he'll be pretty busy the next day or so at work and then with the release, and won't be reading messages in the forums here. Unfortunately, we're so close to 1.1 final that I don't think adding new code or even renaming could likely happen, but you can try convincing Juergen; it's not like changes at a fairly late stage have not happened before.

[Juergen Hoeller]

Martin,

Now that 1.1 RC2 is out, including the new HTTP invoker remoting strategy, have a look at the implementation. BTW, sorry for missing your suggestions from last year - must have got lost in forum traffic.

The actual invocation stuff is generic: It's contained in the remoting.support package, with invocation and result classes plus abstract exporters and accessors. The RemoteInvocationFactory and RemoteInvocationExecutor strategies are in there too.

The remoting.httpinvoker package just contains subclasses that specifically address HTTP transport. Note that the remoting.rmi package provides an RMI invoker mode that leverages the same support classes (alongside support for traditional RMI).

So I believe that the name "HTTP invoker" is appropriate for the actual HTTP transport implementation. The generic invoker stuff doesn't have a distinct name; it simply resides in the support package.

If you have specific suggestions for the current 1.1 RC2 codebase, feel free to tell me! We intend to release 1.1 final very soon, but there's still the chance to tweak here and there.

Juergen

[Martin Kersten]

Now that 1.1 RC2 is out, including the new HTTP invoker remoting strategy, have a look at the implementation. BTW, sorry for missing your suggestions from last year - must have got lost in forum traffic.

Already done so I guess I was one of the first one to download the zip. I monitor the spring-dev maillist, you know. :-)

Well the missing suggestion from last year is a pitty, but I should have louder stomp with my feets, so it is actually my fault, I think.

Anyways, I am currently trying to sell my project to codehaus.org. (I just want the project to be hosted there, no money involved.) I hope I get an ok from them soon.

The actual invocation stuff is generic: It's contained in the remoting.support package, with invocation and result classes plus abstract exporters and accessors. The RemoteInvocationFactory and RemoteInvocationExecutor strategies are in there too.

There are some questions left.

RemoteInvocationResult:
- Referres to Exception class rather than Throwable (Throwable would be more abstract so I would refer to it instead of Exception).

RemoteInvocation:
- I used method signatures + Maps of methods, but I guess using parameter types is more outsmarted then my solution. Fewer code to test I guess.

The rest looks like I have already done it. I have used a quite diffrent naming, but it's slightly the same stuff going on. I will change the names of my implementation-classes, I guess.

So I believe that the name "HTTP invoker" is appropriate for the actual HTTP transport implementation. The generic invoker stuff doesn't have a distinct name; it simply resides in the support package.

I didn't have code to play on, when I have written my suggestions. And yes, by utilizing the apache http implementation, the name is well choosen.

If you have specific suggestions for the current 1.1 RC2 codebase, feel free to tell me! We intend to release 1.1 final very soon, but there's still the chance to tweak here and there.

Well beside using Throwable instead of Exception, I guess I have no additional suggestions yet.

The small API I am working on has a slightly diffrent approach. I guess it can add some value to the spring-users anyway. My solution isn't based on any additional library, so the minimum-client API is quite small (around 5kb). Also it currently incooperates socket connections.

Using a socket connection is really simple and quite a good way to avoid pessimistic locking of domain objects (tag them) and to keep rich clients in sync with the server, since the server can simply notify the client on domain changes, so no polling is needed. The socket version is also the main reason, why I try to contribute it now. I would like to see some more people using it.

[Martin Kersten]

By thinking of using Spring's RemoteInvocation rather than my InvocationAction/Response classes, I question myself, if it is possible to add my solutions of socket-based and http-based remote invocation to the Spring code base.

Since it is quite small, the API would fit the Spring code-base well. It also would add a very good option for connecting small clients (mobile or applets) and also would add support for socket connections, which isn't currently addressed by the Spring framework after all (as far as I know).

I also would avoid the burdon of hosting another project and there would be a wider audience of developers using it and hopefully extending it.

So I guess this would be a good deal. What is your oppinion?


Cheers,

Martin (Kersten)

[tcollins]

It's funny that RC2 came out today. I pulled down the latest code from CVS yesterday to play with the HTTP Invoker. I couldn't wait any longer, once I read about it I had to try it out.

Anyway, I was pleased with how easily it was to setup and get working. It seemed very fast, although the client and server were on the same machine and my object graph was tiny.

I need to do some swing client to server communication and think that this may be the approach I go with. I would love to hear what everyone thinks the pros and cons are to this approach. Especially vs RMI and vs SOAP.

Thanks,
Tim