I have a small Java SE application, it´s practically a fat client sitting on top of a database. To further my Java skills, I decided to make a client-server application out of it. The server application communicates with the database and handles all kinds of lengthy operations, while the client application only receives the results, mostly ArrayLists of moderate length and primitives.
To this end, I started reading on RMI and did the Oracle tutorial, which I found surprisingly difficult to understand and even get to work.
Is there anything else I can use instead of RMI, without having to dive into JavaEE?
One way I would suggest would be to use JSON as the format for data exchange. You can use GSON to convert the data from Java objects to JSON and back. The transport could be done directly on the HTTP protocol using REST. You can use Jersey as a REST server/client or roll your own (since you don't want to use JEE, which Jersey is part of).
SIMON is as simple to use as RMI, but with fewer traps in the initial setup. It also has some advantages over RMI. Here is a simple hello-world example:
http://dev.root1.de/projects/simon/wiki/Sample_helloworld110
I take it RMI = Remote Method Invocation ...
You can have a look at XMLRPC, JSONRPC, JMS, or if you want to roll your own, use JSON to POST messages and convert the JSON back to a java object on the other side using GSON (from Google) or setup RabbitMQ and use AMQP to submit and receive messages if you don't want to handle the POSTing yourself, Spring AMQP makes it fairly easy to do this.
Related
I have a JRuby/Rails app that needs to get data from a system written in Java. I have already worked out how to call Java code from Ruby.
However, lets say that the Client object I need to create, starts threads, communicates with the internal system etc, and that the data is delivered asynchronously in callbacks.
Do I have to write a separate web service (that creates this Client) with a permanent connection to the Java system? In such a way that my Ruby/Rails code can call it synchronously. Or is it possible to write this asynch handler directly in Rails?
When multiple HTTP clients issue their GET's, I would of course have to connect to the Java system when the first client arrives. For the following clients, the data would already be there.
I realize what the proper solution would be, but I'm curious whether I can do it all in Rails.
I can (for now) live without the realtime updating of the webpage, as long as the data in the Java callbacks are stored "somewhere" so that the next HTTP refresh/GET can return it. Nest step would be SSE, Javascript etc.
I think I know how to create the Java web service, however I would rather keep the solution a bit simpler with fewer services.
Thanks
Since you also have access to the java code, I have two approaches to extend the java backend, in order to provide the data you want to use in your ruby frontend application.
Use REST or a HTTP Service
Your ruby webservice could interact with the backend utilizing REST (or any other HTTP approach). This would result in cleaner and more reusable code. Since you're able to access the backend data with any client that is capable of HTML.
Use TCP together with a little protocol
In this approach the clients have to connect to a TCP socket on the backend to send data back and forth. You have to write a little byte or string based protocol which you also have to parse. It's more complex than the first approach, but also more performat and you don't have to rely on external libraries (e.g. jersey, for REST). It also has all the advantages of the former approach, you can serve any client capable of network communication and socket handling.
2 month ago i started to develop an android application which needs to call remote methods and receive complex objects (custom objects with custom feilds in it) from a server.
My friend and I splitted the work so he worked on the android client and i on the server.
Before we started, we built the base interfaces which provide the functions that the client needs from the server, so my friend can program easly the application (by using fake classes as implementation for the interfaces), and after i finish the implemntations of the interfaces in the server-side he will make the connection and call the functions from the server and not from the fake classes.
Now the problem is that we can't find a way to pass those interfaces from the server to the client.
We tried to use java RMI, but we faild because android doesn't support java RMI,
then we tried to use JAX-WS (with tomcat 7) and we also faild because JAXB can't handle intefaces. (-you can see more details here about jaxb issue-)
My friend and I feel really lost.. we don't have any idea how to pass those interfaces between the server and the android client.
Is it possible what we're trying to do? if not,
what other options avaible for us to call remote methods and receive complex objects from the server?
Thanks!
You can expose webservices on the Server, so the client can interact with the server whenever its needed that might be quickest solution.
Or you can write a kind of servlet programming to get the json request from the client, process it and send the json respoonse back to the client. If the application is data intensive, the JSON helps you a lot
Not sure if this is too late now (after 2 months of development), but there are frameworks that should make RPC easier for you (take care of linking both ends). Two I know of are Apache Thrift (definitely usable with Android - there are apps that use it) or Apache Etch (possibly).
Apache Thrift:
http://thrift.apache.org/
Apache Etch:
http://incubator.apache.org/etch/
Blog about Evernote choice of Thrift:
http://blog.evernote.com/tech/2011/05/26/evernote-and-thrift/
If your application is limited to communication between Java on the server and Android (no other clients e.g. IOS) then an easier RPC path compared with IDL based solutions is to use jsonrpc. This solution provides both server and Android client components. It is extremely easy to implement on both client and server. One limitation is that byte arrays have to be encoded because the JSON transport does not support binary.
im starting with web services. I'm working in a project that needs to communicate Android with a web server and I'd like to save some time chosing the appropriate protocol for the communication.
Between JSON ,REST and SOAP:
Which ones can I run in a non-dedicated server?
Whats the best choice for a high trafic server?
Thanks in advance
JSON and REST are not mututally exclusive. JSON is a data format that the REST interface can return.
You may run either on a non dedicated server. I would personally choose REST for rapid prototyping on Android as it is easier to get up and running. (With SOAP you will probably want to have a schema which takes time to put together)
There's a good comparison between REST and SOAP on the REST wiki article: http://en.wikipedia.org/wiki/Representational_State_Transfer#Concept
REST is more of a framework than a communications protocol. JSON and SOAP could be use to create a RESTful application.
If you're writing something with many resources, I'd use REST as it is far more structured. There are also a lot of libraries that will set most of things up for you. I find JSON and SOAP are better for custom functionality that you want to hack together quickly. They can be lightweight, but less structured.
I have an application in C++, but it'll need to 'talk' to Java based message-service. In the past we used WebSphere MQ and used their C++ libraries to do the 'talking'.
So I am in search of (ideally) free C++ to Java solution which doesn't hold the whole JVM in memory.
The other option I've looked into is SOAP.
I've looked into Axis2-C but it gives me the whole server implementation, which I don't need.
I've seen talk about gSOAP but saw mixed comments here. And again it seems to be providing me with a whole server.
I could write the code myself - but it goes against my (Java based) belief that excellent free code exists out there.
Thanks!
A'z
There are a couple of points here which don't make sense to me, JMS is a java specific abstraction over a generic messaging API, much the same way that JDBC is a java specific abstraction over a generic database API.
I can't imagine anyone wanting a JDBC driver for a C++ application, they would rather use an ODBC driver.
So if I assume that your objective is to send messages without using Websphere MQ from a C++ application, then I can recommend that you consider the following:
Do you need asynchronous messaging? i.e. store message on queue until message is consumed?
If yes, then web-services will not work for your application, unless you are prepared to host a web-server to receive the responses, and call back to your application.
You haven't mentioned whether the underlying java based message service is going to be JMS or WebServices.
You could consider using ActiveMQ as a messaging provider, it provides an implementation of the JMS API and also implements the STOMP protocol, which has client libraries for a number of languages including C++.
You could leave open your decision for end-point protocols while you try out various options, by implementing an integration layer using something like Mule.
You can quickly develop small integrations on Mule e.g. to accept a Message on ActiveMQ, and post it to a WebService and put the WebService response on a different ActiveMQ response queue. Or vice-versa, accept web-service call and post SOAP onto JMS queue, wait for JMS response and build SOAP response.
There are many ESB-like frameworks which can facilitate these sort of integrations to various degrees :
Mule
ServiceMix
Fuse
Apache Camel
Spring Integration
JBoss ESB
EDIT:
Given the clarification I will refine my answer:
You need a common message broker that is accessible to C++ and Java such as ActiveMQ.
You need a small / lightweight integration layer such as some of those above to accept from ActiveMQ and forward to SonicMQ, and vice-versa.
2.1 From what I know of Sonic, they have an ESB stack that should be able to do this instead of using one of the containers/frameworks mentioned above, but that will open up issues of integration ownership between you and the client.
I found 3 links showing Sonic support for C and C++ :
- http://www.sonicsoftware.com/products/docs/sonicmq_app_server_ds.pdf
- http://www.sonicsoftware.com/developer/documentation/docs/sonicmq_c_v60.pdf
- http://communities.progress.com/pcom/servlet/JiveServlet/download/10809-3-10161/cclients_readme_76.htm (dodgy mime type on this link)
The SonicMQ site seems to indicate that they support C++.
It would appear that this is suitable.
There are C++ libraries for SonicMQ. The main constraint is that you have to be using the same build (ie. STL libraries, etc) that Sonic used to compile the libraries.
http://web.progress.com/en/sonic/sonicmq-clients.html
Of course you asked this question over half a year ago, so this information is probably a bit late. :-)
I am building an ESB (enterprise Service Bus). This means i need to
set up tcp connections and communicate with JSON (well not NEED.. but json is light and easy)
I made a server who is able to set up a TCP socket and receive json. This is all very nice but i need to be able to call methods via a tcp connection.
so for example to call a method:
{server:pictures, method:changeImage('name')}
This is just an example and could change.
my question is: Is there a framework that is able to:
set up tcp server
receive json messages and call the appropriate method
return an answer (in json).
of course json could also be xml but i would rather use json (much cleaner)
thanxs in advance!
A Web Server serving RESTful web services is exactly what you're asking about..
If I were you, I would look into using SOAP based messaging and the WS-* Standards. Things like WS-Federation and WS-AtomicTransactions will allow you to build a more robust ESB.
Any modern Servlet container, perhaps? Running DWR or jabsorb? Have you looked at the modern ESB implementations? Sounds like you have a lot of wheel I've seen before here.
Why do you need to create your own ESB? As I understand it's a quite complex task. Have you considered using existing open-source solutions?