We Keep Coding

Pass XML data from C# to Java?

I have two applications: one in C#, the other in Java. I need a way to transfer data from the C# application in XML format to the Java application using some kind of service.
I have only worked with sockets before, but am looking for something less proprietary for future use with other applications. What other alternatives are there?
*Please note that the extent of my knowledge with working with sockets was a simple client/server written in java.

If both programs run on the same machine, you could of course also use files, but in general, this is how it goes down:
Create a webservice in C#, implementing a method that exposes your data.
Use the wsimport tool provided with the jdk, point it at the above created .wsdl file to generate java classes to use as a soap client.
Use generated classes to consume webservice.

(I see now you insist on XML. So forget about it)
These are completely distinct issues - it's like asking if I want to speak with you now, should we have a phone call in French or maybe mail correspondence in Mandarin. So it's:
Means of transferring data (S.A HTTP, or TCP, or whatever).
Some common structure of data.
Confusingly, both are regarded as 'protocols'.
Anyhow I'd say protobuf over HTTP is the most obvious and straight forward thing to use.

TCP/IP vs Web Services for iPhone chat app

How to create a NATIVE chat app for the iPhone? So far we have been exploring a few options:
Creating a web service using php or other web based language and have the app connect to that. Only problem is we can't figure out how to create "push" messaging with this, where the user will not have to refresh the conversation constantly.
Hosting an application on a server such as Windows Azure which will communicate to the iPhone app using TCP/IP. This way it seems like "push" messaging could be achieved by simply sending a packet to the iPhone. However, we have never done this before and don't know if we would run into any unforeseen potholes.
Have any of you made such an app before? If so how did you go about doing it? If not, what method would you recommend?
Thank you in advance!
EDIT:
To tell you exactly what we're trying to do: we need to make an app where a user can join a chat room and send/ receive messages from that chat room. There will also be custom features like that users will have their own profiles, etc. We would also like to make this as flexible as possible, so that we can integrate it on other platforms like android and blackberry later on.
So essentially the part that I'm stuck on is the send/ receive messages from a chat room. What technology should we use server side?

Something with an open socket, like Socket.IO could work. Node.js is a good server-side framework to explore. Here's an related SO question: iPhone Objective-C socket communication with Socket.IO
EDIT:
Question has changed since posting this answer -- originally question asked about web apps. ALso, originally the question was not clear that you wanted answers about the server side more than the client side.
On the server side, I would still recommend Node.js -- sounds like you want to use C# though, which makes me wonder why you're asking again about what server side tech to use. Most languages will provide you with ways to connect a socket to a client and access a database, which are the two main requirements of the app that it sounds like you want to make. Use whatever language you're comfortable with. However, some are going to come with libraries that may come in handy for this type of communication -- Node.js and Ruby on Rails (more useful if you want to do a polling-based solution)
Look at http://code.google.com/p/cocoaasyncsocket/ for a good library for doing socket communication from the iPhone without having to delve too deep into the low-level functions.

I've done this several times. Scaling to 100K concurrent users is non-trivial. If you want an off-the-shelf system I suspect ejabberd may do what you want. although the protocol IMHO is too verbose and uses far more bandwidth than necessary.
If you want to write your own solution and have the flexibility to write your own protocol and have the maximum possible scalability in the future then use a language that allows you to distribute the application across several servers. It is easier to allow that from the get go rather than writing a single server solution then have to retroactively make it distributable.
Having written servers like this in c++, Java and Erlang I would say the easiest and most relevant tool was Erlang. It makes good use of multi core processors and with a good design it facilitates distributing across several servers. C++ was the hardest!
I have also used Java with tools like JETTY and RabbitMQ to write a highly scalable system that required using HTTP as the protocol.
Personally I prefer a custom binary protocol as it allows you to reduce bandwidth to a minimum, and avoids DOS attacks and such as the protocol is well defined and lengths are sent before the packet, where as non binary protocols need to be parsed as they come in, with no idea of how big the packets may be.

Why not try XMPP protocol first? XMPP is based on TCP/IP.
There are several OpenSource server solution, clients, and application libraries. XMPP already supports chat room like service. You can define extension easily.

Object Serialization on different platform

Hi guys I'm creating a very simple socket server that lets its clients save its own object state based on Keys by sending it over the wire. I'm using a very simple protocol encoding the serialized object to base64 string and will be sent out as part of my custom xml format. I wanted to know if the serialization will still be the same if the client app runs on 32-bit and 64-bit Windows and using .net Framework? will this also be the same if all client apps are created using c++ but runs on different platforms?

Serialization between 32 and 64-bit CLRs shouldn't be a problem, but if you want to be able to serialize on non-.NET platforms, you shouldn't use the default binary serialization. Personally I wouldn't use that anyway, as it can be tricky to handle in terms of versioning etc.
There are plenty of other serialization options available:
XML serialization (either the built-in or hand-rolled)
Thrift
YAML
JSON
Protocol Buffers (I declare an interest: I've written one of the ports of Protocol Buffers to C#)
All of these are likely to work better across multiple platforms. Some are human readable as well, which can sometimes be useful. (Protocol Buffers aren't human readable, but it's easy to dump a text version of a protocol buffer message.)
Some effectively build their own object model via a separate schema, whereas others will cope (to a greater or lesser degree) with your existing object model.

Communication between programs in .NET

I want to separate modules of my program to communicate with each other. They could be on the same computer, but possibly on different ones.
I was considering 2 methods:
create a class with all details. Send it of to the communication layer. This one serializes it, sends it, the other side deserializes it back to the class and than handles it further.
Create a hashtable (key/value thing). Put all data in it. Send it of to the communicationlayer etc etc
So it boils down to hashtable vs class.
If I think 'loosely coupled', I favor hashtable. It's easy to have one module updated, include new extra params in the hastable, without updating the other side.
Then again with a class I get compile-time type checking, instead of runtime.
Has anyone tackled this previously and has suggestions about this?
Thanks!
edit:
I've awarded points to the answer which was most relevant to my original question, although it isn't the one which was upvoted the most

It sounds like you simply want to incorporate some IPC (Inter-Process Communication) into your system.
The best way of accomplishing this in .NET (3.0 onwards) is with the Windows Communication Foundation (WCF) - a generic framework developed by Microsoft for communication between programs in various different manners (transports) on a common basis.
Although I suspect you will probably want to use named pipes for the purposes of efficiency and robustness, there are a number of other transports available such as TCP and HTTP (see this MSDN article), not to mention a variety of serialisation formats from binary to XML to JSON.

One tends to hit this kind of problem in distributed systems design. It surfaces in Web Service (the WSDL defining the paramers and return types) Messaging systems where the formats of messages might be XML or some other well-defined format. The problem of controlling the coupling of client and server remains in all cases.
What happens with your hash table? Suppose your request contains "NAME" and "PHONE-NUMBER", and suddenly you realise that you need to differentiate "LANDLINE-NUMBER" and "CELL-NUMBER". If you just change the hash table entries to use new values, then your server needs changing at the same time. Suppose at this point you don't just have one client and one server, but are perhaps dealing with some kind of exchange or broker systems, many clients implemented by many teams, many servers implemented by many teams. Asking all of them to upgrade to a new message format at the same time is quite an undertaking.
Hence we tend to seek back-comptible solutions such as additive change, we preserve "PHONE-NUMBER" and add the new fields. The server now tolerates messages containg either old or new format.
Different distribution technologies have different in-built degrees of toleration for back-compatibility. When dealing with serialized classes can you deal with old and new versions? When dealing with WSDL, will the message parsers tolerate additive change.
I would follow the following though process:
1). Will you have a simple relationship between client and server, for example do you code and control both, are free to dictate their release cycles. If "no", then favour flexibility, use hash tables or XML.
2). Even if you are in control look at how easily your serialization framework supports versioning. It's likely that a strongly typed, serialized class interface will be easier to work with, providing you have a clear picture of what it's going to take to make a change to the interface.

You can use Sockets, Remoting, or WCF, eash has pros and cons.
But if the performance is not crucial you can use WCF and serialize and deserialize your classes, and for maximum performance I recommend sockets

What ever happened to the built in support for Remoting?
http://msdn.microsoft.com/en-us/library/aa185916.aspx
It works on TCP/IP or IPC if you want. Its quicker than WCF, and is pretty transparent to your code.

In our experience using WCF extensively over the last few years with various bindings we found WCF not be worth the hassle.
It is just to complicated to correctly use WCF including handling errors on channels correctly while retaining good performance (we gave up on high performance with wcf early on).
For authenticated client scenarios we switched to http rest (without wcf) and do json/protobuf payloading.
For high-speed non-authenticated scenarios (or at least non-kerberos authenticated scenarios) we are using zeromq and protobuf now.

Is it possible to communicate with an external system over TCP/IP using WCF?

We are building a system that interacts with an external system over TCP/IP using the FIX Protocol. I've used WCF to communicate from client to server, where I had control over both client and server, but never to an external TCP/IP based system. Is this possible with WCF? If so, could the community provide links for me to get started and faced in the right direction?
Unfortunately I do not have much more information that what is supplied above, as we are still in the early early planning stages. What we know is that we have an external vendor whose system will communicate with our system over TCP/IP. We would like to use this as a learning opportunity and learn WCF.

Possible? Possibly yes, but it's going to take some work.
For starters, you will need to write a custom WCF Transport Channel that handles the specifics of your TCP/IP based protocols (i.e. you'll need to write all the socket handling code and hook that into the WCF channel model). This is because the TCP channel in WCF isn't for this kind of work, but uses a relatively proprietary and undocumented wire protocol.
I'm not familiar enough with FIX to say how complex it would be, but there are some gotchas when writing WCF channels and documentation in that area isn't great.
The second part you'll need to deal with is message encoding. To WCF, all messages are XML. That is, once a message is passed on to the WCF stack, it has to look like an XML infoset at runtime. FIX doesn't use XML (afaik), so you'll need to adapt it a bit.
There are two ways you can go around it:
The easy way: Assume the server/client will use a specific interface and format for the data, and have your channel do all the hard work of translating the FIX messages to/from that format. The simplest example of this would be to have your WCF code use a simple service contract with one method taking a string and then just encapsulating the FIX message string into the XML format that satisfies the data contract serializer for that contract. The user code would still need to deal with decoding the FIX format later, though.
Do all the hard work in a custom WCF MessageEncoder. It's a bit more complex, but potentially cleaner and more reusable (and you could do more complex things like better streaming and so on).
The big question though is whether this is worth it. What is your reasoning for wanting to use WCF for this? Leveraging the programming model? I think that's an important consideration, but also keep in mind that the abstractions that WCF provides come at a price. In particular, some aspects of WCF can be problematic if you have very real-time requirements, which I understand is common in the kind of financial environment you're looking at.
If that's the case, it may very well be that you'd be better served by skipping WCF and sticking a little closer to the metal. You'll need to do the socket work anyway, so that's something to consider there.
Hope this helps :)

I don't think it is possible, at least it won't be easy to set it up because you don't know the communication protocol of the other end, except for it's TCP and accept FIX tags.
Why don't you within WCF application open TCP connection a SOCKET. That should do the trick in a simpler manner.

I think so. I have a system that I almost got working that was supposed to do almost exactly that (WCF over HTTP from the internet). The server provider seemed to not want to allow it thought so you will need the right permissions on that end to make it work.
Up shot: I don't see why not.

Not really - Ms didn't make the TCP/IP connection handler to talk to non-WCF services, they assumed you'd write a Web Service to do that.
This is discussed here on SO.