We Keep Coding

Consume .NET web services in Java

I have created .NET web services. I want to run it on a remote server and have the Java Applications (clients) contact the server for data. How should I implement the Server such that the Clients can make use of the org.apache.xmlrpc.client.XmlRpcClient package?
I just want the clients to generate a request for data and does not want to have any other dependencies.
Here is a good material on using eclipse for this purpose: http://wso2.org/library/tutorials/creating-web-service-client-3-steps-using-eclipse
Thanks.

Although both are rightfully called "web services" the SOAP based web services usually created in .net are incompatible with web services following the older XML-RPC standard.
In my opinion you can follow 2 routes to solve your problem:
either you go the SOAP route under Java, one of the most common API's for that purpose would be jax-ws - some excellent pointers to tutorials here, in Pascal Thivent's answer
or you transform your .net webservices to XMl-RPC by using xml-rpc.net
Both routes have advantages and disadvantages, it's hard to make that choice for you without knowing more about your project. A priori choosing the SOAP route might look "safer" as there the entire communication will be based on standard components.

If you have the Web Services on the .NET side, you must have a Web Service Description Language (WSDL) (if you are not talking about REST), you can easily create the client classes to consume this Web Service using an IDE, check this link here: http://netbeans.org/kb/docs/websvc/client.html

If you are using Eclipse I suggest you this tutorial to build a simple WS client.
You can adapt this example application to your real needs.
NOTE the example uses an old version of Eclipse, but the wizard is very similar also in newer versions.

Building java server which share interfaces wtih Android client

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.

Php - middleware

I am developing a php based application which has java as middleware for web services. Is there any frameowork/middleware available in php stack which allows me to write services in php and also hosted on php based app server, lets say Zend?
Thanks

Typically I'd expect the middleware to be the webservices - are you consuming or providing webservices using PHP?
Not that it makes much difference, PHP supports both.
You can roll your own solution, or use PHP Soap, the nuSoap PHP lib and xmlrpc. There's also the php/java bridge which implements a socket based abstraction for both ends (but obviously this is not strictly a web service).

Java and .NET application communication

I don't think this is quite possible or if it is recommended to do... but is there a way to connect or comunicate or deploy Java and .NET application for method beside Web Services. I mean I understand there are Messaging server that allows Java application communicate to each other but I dont know if this can cross development environment, any suggestion about it or thoughts about this?
I'm limited to web and desktop environments.

Apache Thrift is a way to go. You will need to write a service definition like this:
serivce helloworld{
string sayHello(1:string name)
}
Thrift then will generate RPC interface with network layer already implemented, It support many others language such as Java, C#, PHP, Python. Thrift support binary protocol over TCP/IP, so it's very fast.
for more, go to its wiki page http://wiki.apache.org/thrift/

You can use something like Apache ActiveMQ which uses JMS on the Java side and the .NET Messaging API on the .NET side.

We ended up writing our own implementation of Java-.Net communication protocol based on Hessian (later added JSON as well), but Thrift is a valid option.

The virtual machines (JVM vs CLR) are not going to talk to each other except through some OS level open standard. Shared Files (yuck), Sockets and Web Services come to mind. There is nothing that would allow you to call a .net subroutine from java or vice-versa.

C++ JMS client or C++/C SOAP Client

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. :-)