We Keep Coding

Starting point for Java client/server remote application

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.

Remote Procedure Call Mechanisms between Android and Desktop Computers

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.

Java and .NET application interoperability

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.

Android communicating with servers

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.

What is the best way to make a .net client consume service from a Java server?

I have a user interface in .net which needs to receive data from a server, on a request/reply/update model. The only constraint is to use Java only on the server box.
What is the best approach to achieve this ? Is it by creating a Webservice in Java and then accessing it in .net, or should I create Java proxies and convert them in .net by using IKM ? Or do you have any better idea ? It can be HTTP based, used a direct socket connection, or any middleware.

I recommend the web service route. It offers a standard interface that can be consumed by other client platforms in the future.
.NET clients interact with Java web services pretty well, though there are some gotchas. The best two technologies available for you for the .NET client are Microsoft Web Service Enhancements (WSE) and Windows Communication Foundation (WCF). WSE is an older technology that is no longer being updated by Microsoft, but still works great in Visual Studio 2005 and older. I find WSE to be a bit easier to get started with in terms of how you interface with basic services, but WCF has much more support for WS-* protocols (security, trust, etc.). If your needs are basic and you're still using Visual Studio 2005 (.NET framework 2 or older), then go with WSE. If you like the cutting edge, or you anticipate more advanced security needs (doesn't sound like you will), then go with WCF. Please note that WSE will not work easily in Visual Studio 2008 and newer, and WCF will not work in Visual Studio 2005 and older.
Going the web service route will mean that you will design to an interface that can be reused and will result in a more loosely coupled system when you're done than most of the other routes. The downside is primarily performance: xml serialization will be slower than binary over the wire, and web services do not handle large amounts of data well.

Write webservice in Java and access it in .net

Using a standard type of web service (e.g. SOAP or XML-RPC) is best because not only is it easy to produce/consume, it's easy in other languages as well.