I want to perform Remote Procedure Calls between Android and Desktop.
If RMI was there,it would have been mine choice.
But android does not support Java-RMI.
Can anybody suggest similar and simple RPC mechanisms that i can use as easily as RMI,without worrying about lower layer transport layer implementations
Kindly give me the alternative for RMI in android
I think you may be able to use different strategies:
- Web Services calls using SOAP, XML RPC, using Rest invokations types.....many strategies
- alternatives to Web Services available like the one provided in Spring Remoting with Burlap/Hessian protocols (you are not obliged to be tied with Spring to use such strategies)
Main idea is to use as core component a protocol managed by your android device : HTTP...
HTH
Jerome
Another option is Versile Java (full disclosure: I am one of the developers). It is in development but already quite stable, so you may want to have a look. Here is a demo which shows an Android client using Versile Platform to interact with a python based service running on a desktop.
RPC is generally a lousy technique, especially for remote operation. And it's not supported in most UI environments because you're never supposed to "wait". Far better to use some sort of a request/response approach.
Related
I have an existing java project that I wish to create a mobile 'remote control' application that is capable of calling a few public methods from the existing project.
I have no previous experience of any sort of networking development so would appreciate some guidance on where I should start. I've found a few libraries out there but I'm not entirely sure what I'm looking for (or if I'm overcomplicating things!).
Thanks,
Adam
Java RMI technology may be what you need, here's where to start http://docs.oracle.com/javase/6/docs/technotes/guides/rmi/hello/hello-world.html. It can be used when both client and server are in Java.
If you want to use webservices you could take a look at this Exposing existing API as a Web service
You could check this out Java client/server application with sockets? in order to learn from previous discutions on the client/server subject.
Perhaps lean towards JAX-RS unless you want to deal with low level or have any constraints on protocol to use. http://docs.oracle.com/javaee/6/tutorial/doc/giepu.html.
I am having a Java application and a .NET application both residing in two different machines and need to design a communication layer between these two applications. Any inputs or ideas would be really helpful. Below mentioned is the nature of interaction between these two applications.
Java applications sends large amounts of data to the .NET application
Data latency should be kept to a minimum
.NET application should also be able to request for some data (synchronously/asynchronously)
The easyest way .Net and Java can talk is using Web-Services - we have done in my company with much success (using apache's cxf and standard code on the .Net side).
But if latency and size are the main requirements, you should use Sockets - both platforms offer a pretty extensive socketing frameworks and it would give you the best performance possible.
I think this can be done by setting up an xml webservices layer on the java side. You can use RestEasy for restful web services. Just my .2 cents.
Another alternative is some form of MOM (Message Oriented Middleware). There are a lot of implementations, but one to look at first might be ActiveMQ as it has both Java and C# bindings (among others).
I'm not saying this is better than using a web-service, it entirely depends on what your requirements are.
We have had good experiences with providing web services with JAX-WS (part of standard runtime in Java 6). They explicitly list .NET compatibility as a goal and is well supported in IDE's.
The Endpoint.publish() mechanism allow for small, simple deployments.
You can use Web Services. Jax-WS is the API in java that allow you to use it. As the implementation of this API I recommend metro (http://metro.java.net/), this already came with the SDK, and has a great integration with netbeans.
As already someone referred yet, you can use a socket, and create a communication channel on that, but this have some problems, starting with security. Don´t use this in real life applications.
If you need help with this subject you can start reading this:
Getting started with JAX-WS
It really depends on your requirements. The simple way is generally Web services. However, if you want higher performance, or more fine-grained access to the API on the other platform, you might want to consider JNBridgePro (www.jnbridge.com).
Disclosure: I work for JNBridge.
I come from a .Net background and recently x-training to java.
I wanted to develop an Android application that required simple functionality to communicate with a server. For example, functionality such as post a username/score to a website (or service), or request information such as top 10 scores.
What type of communications should I focus on? What is the common technology to use? Does Java have the equivalent of WCF? Or does it have some sort of simple web service? Can web services be secured with authentication?
Ive heard other references to xml-rpc. Should this be something I should look into?
Depends on what your server is running. I usually just use URLs to fetch and/or send data and then parse the response with whatever is suited (such as org.json for JSON or org.w3c.dom for XML or HTML).
Java has the equivalent of WCF in the fact that you can develop Web Services with Java and use frameworks to develop such services to benefit from different features. The format which you send messages to these web services I think is what you are asking as such you literally can use any format you want (Dependent on support of such format by the service). You will find libraries for many of the well known formats like SOAP (KSOAP2), REST (JSON,XML) etc... Since the transport of these can be over HTTP, and you get a library in android to develop such services over HTTP you have quite a choice.
For Reference:
http://ksoap2.sourceforge.net/
https://metro.dev.java.net/
http://msdn.microsoft.com/en-us/netframework/cc950529.aspx
Hope this helps,
Andrew
Without knowing all of your requirements but assuming it's gaming-related, you might be better served trying one of the Android gaming APIs rather than trying to roll-your-own networking solution. Scoreloop and OpenFeint, the two I am currently considering for my own Android game, both offer Android APIs that make it fairly straight-forward for posting and retrieving high-scores, in addition to other game-related features such as challenges and social network integration.
The advantage of this option is that you don't have to worry about how the phone talks to the server nor do you have to host the server itself - they have already solved those problems for you - and they're free which makes it great for us indie developers.
I have made a Java Swing application. Now I would like to make it a Client-Server application. All clients should be notified when data on the server is changed, so I'm not looking for a Web Service. The Client-Server application will be run on a single LAN, it's a business application. The Server will contain a database, JavaDB.
What technology and library is easiest to start with? Should I implement it from scratch using Sockets, or should I use Java RMI, or maybe JMS? Or are there other alternatives that are easier to start with?
And is there any server library that I should use? Is Jetty an alternative?
Given that you have the application already, perhaps the simplest thing to do is to identify the interface that you require between the client and server, and first of all to refactor your application to use that interface to talk between the back-end/front-end within the same process.
Then you can start to split this apart. A simple solution would be to split this apart using RMI (since you're talking Java objects and have Java method calls). Spring contains useful tools to simplify/automate the RMI exposure of interfaces.
For the notification requirement, a simple UDP multicast (or broadcast) would suffice.
Note that as soon as you split your application up, you have issues re. maintaining consistent views of data, managing timely updates, handling cases when the server is down, possible loading issues when you get lots of clients etc. In a sense, splitting the application up into a client and server is just the start of a new architecture process.
Mina is a good choice as a network application framework for building a simple server for this purpose - it's a much better option than using raw sockets.
http://mina.apache.org/
If you really need an application server then you could take look at JBoss. It also provides a remoting component (as an alternative to something like Mina):
http://www.jboss.org/jbossremoting
You probably won't have much need for Enterprise Java Beans though. In most cases a simple POJO based framework is more than sufficient - you could tie this altogether with a dependency injection framework such as Guice:
http://code.google.com/p/google-guice/
or Spring. Keep it simple, don't use a J2EE server unless you really need to. Hope that helps.
This is much of what J2EE does, but it's a whole new learning curve because they have pre-solved many of the problems you will run into and many you may not and therefore add on a lot of new technologies.
But at it's most basic, J2EE answers just that question.
I worked in a project like this. We implemented Client-Side Swing and Server side with J2EE. We used EJB,Stateless beans and Message Driven Beans.Also I have been in a device tracking, management project. Our clients were trucks+Swing users and We have used Servets+TCP/UDP,Apache Mina framework to handle and keep connections.
I have been working in Java Swing Client/Server applications for almost 3 years. I would suggest you to go for RMI/EJBs. The initial application that we developed was doing this using RMI/EJB for client-server communication with WebLogic being the server.
But we later found out that there are lot of "browser-like" features to be included to the application such as session-timeout etc., So, we used the BrightSide Framework which wraps the RMI calls through HTTP. One more enhancment we made is that we replaced Weblogic with the open source JBoss server.
The wrapping of calls with HTTP will become very handy and you can make your swing applications really rich. Later, when the situation demands for you to use a website strictly, you can deploy your swing using jnlp.
Hope this helped.
I'm currently in the research phase of my dissertation project.
My project is a ticket booking system for a mobile device and I have chosen to target Android.
I anticipate the need for a client/server architecture with a central server, and so am currently looking at how Android could communicate with such a server. The server would grant the client access to ticketing information, and the client would send information about ticket bookings to the server. I'm looking at Java EE for the server as Java is the language I'm most experienced with.
I'm aware that Android comes with java.nio and java.net, as well as some org.apache packages, but am also looking for libraries/technologies that would be possible to use with Android.
So far I've not found anything massively helpful on the internet, so I'm seeing what SO can suggest.
Specifically I am interested in knowing:
What support is there for various middleware technologies in Android? e.g.
RPC based middleware
CORBA
Message based middleware
Web services such as XML-RPC, SOAP, REST
How well (or not) do existing Java libraries work when used on the Android platform? (e.g. If I wanted to use a library/API designed for Java SE rather than Android what problems might I encounter?)
Ideally, as the focus of my project isn't meant to be the communication between the server and client, I could use an existing middleware to handle the communication, but I am prepared for the worst case, which is having to write my own.
What support is there for various
middleware technologies in Android?
My personal opinion -- though I do not feel I am alone in thinking this way -- is that only protocols specifically designed to run over the Internet are remotely suitable for use with a mobile client. So, of your list, the only one that I would even entertain would be:
Web services such as XML-RPC, SOAP, REST
Some people have been maintaining an Android port of kSOAP2. However, I get the distinct impression that most Android developers working in this area have tended towards REST and REST-ish protocols. If nothing else, that's what all the fun Web sites and services are using for an API, particularly compared with XML-RPC (old) and SOAP (old and icky).
I have successfully used both the java.net.URLConnection and Apache HTTPClient libraries in Android for communicating with REST-style endpoints -- both directly and through third-party JARs -- with no real Android-specific issues.
How well (or not) do existing Java
libraries work when used on the
Android platform?
It is difficult to answer that in the abstract. Android implements a substantial subset of JavaSE, but not all of JavaSE, so there's a chance that any given JAR will expect something Android does not offer. Similarly, Android does not use environment variables, command-line switches, or a variety of other things that developers focused on the desktop might have introduced as semi-requirements. So, some things have worked for me with nothing more than a recompile (Beanshell), and some things have worked for me after removing redundant classs (JTwitter), and some things looked like they were going to be ghastly to get working (JavaMail).