I am trying an application to write an application on which I have used a client/server architecture. The client side is developed using .NET\C# and the server side is developed on python. To communicate the both sides, I used first tcp/ip socket; so i put my python's methods on a loop then I ask each time from my c# application to run an method. This idea is very bad as it require to cover all use cases that can be happening on network or something like that. After a work of search, I have found three technologies that can answer a client/server architecture which are RPC, RMI and WCF. RMI a java oriented solution so it is rejected. So, my question here is: does RPC and WCF support multi programming languages (interoperability) especially betwenn C# and python?
I'm not sure I completely understand your use case, but I would suggest having a look at a REST API approach if you need to have .Net talk to Python, or vice versa.
An alternative is using Pyro4 to expose Python objects on your Python server side and talking to them via the C# client library provided by Pyrolite. This mostly hides any networking specific programming details.
Related
This question already has answers here:
Can I communicate between Java and C# using just sockets?
(2 answers)
Closed 9 years ago.
I am about to develop a server using the Java language for a game.
The game is written in C#, and they are going to communicate through sockets.
The only way I can come up with is using JSON.
What is the proper way to do this?
The proper way is to have either a RESTful or a SOAP-based web service on the server
side and the client to call it. This is also going through sockets on the lowest level.
If you want, you can implement socket-based communication yourself (no REST/SOAP)
but I would not recommend it as it will make your job more difficult and error-prone.
But on the other hand, this may be more efficient, if you implement it well.
So you have many options, it all depends on the exact needs/requirements.
If you want to communicate properly your applications, I suggest you think about a multi-threaded server, in which every worker thread should poll the open socket and deal with the request, and you should write all this with kind of low-level I/O and multi-threading APIs.
Though it is possible to do it, I must recommend you to leave your communications to an application server, for example a Tomcat server or something similar. There you can deploy your java server as a web application implementing a REST or SOAP based webservice.
This way, you are covered with a production-strength server doing your communications duty for you, and can focus on writing a standard webservice client in C# (I admit I can be of little or no help at all in C#, but I guess someone here will be glad to help you there).
If your looking for a convenient API / library to communicate between apps, you may want to consider zeroMQ.
For webserver-client models. You may want to consider implementing a HTTP REST/SOAP interface.
I'm in this project:
A web page that's gonna be used by the front-end company people to query and update data from a SQL DB.
I'm working with visual studio and the code behind (C#) is almost done, so the interactions between SQL and C# are ok.
My original idea was to work with ASP.NET which is familiar to me, but that's not gonna be possible. I have to switch to PHP.
So, today is my first day learning PHP, checking http://php.net/manual/en/index.php and a lot of things seem quite similar to ASP.NET so I guess it won't be that hard.
Anyways, some questions popped up quite fast as I wanted to script something else than a "hello world".
Is there an easy way to get/send C# variables from my class using a php page? I've read soemthing about using XML in order to do so, but still I'm scratching my head, is there another, easier, way to do this?
You have options.
direct integration. PHP can instantiate and use .NET objects . See the DOTNET library in PHP. So if you run PHP on Windows, and you expose your .NET logic according to the requirements of the PHP DOTNET infrastructure, then you can just call .NET classes directly from PHP. Some restrictions: PHP is built to integrate with the .NET 2.0 runtime. You can't build .NET 4.0 objects and connect to them from PHP.
synchronous network protocols. As others have suggested you can expose your C# logic via aREST or web services interface, then invoke those services from PHP using the curl library or file_get_contents(). The C# logic could be, but need not be, publicly exposed. In other words, you could make it accessible only from within the firewall of your app, so that no anonymous public access is possible. on the other hand your architecture may call for access to the same API from 3rd-party or user apps. In that case it needs to be exposed publicly.
in either case, public or private, you will want to use WCF or ASPNET MVC to expose these services implemented in C#.
asynchronous mechanisms. PHP can connect to MSMQ. See Using PHP to Open MSMQ Queues . Of course C# can do likewise. You could use MSMQ as a buffering communication mechanism between the two worlds. To do this you'd need to come up with a data serialization protocol, for the messages you put and get on the queue. JSON or XML would be appropriate choices here.
Database. If you are concerned about employing MSMQ as it is "one more piece of infrastructure to manage" you can also employ a database as a go-between. A shared database can be accessed by both PHP and C# and used as a message queue or communication conduit. PHP inserts messages in a MySQL Table, and the C# app could read and process them, then place reply messages in a different table. This would require some work by you to design the message formats, protocols, indexes, and request/reply correlation mechanism. But it relies on proven, existing technology that you already know how to use.
Finally, there is Phalanger. This lets you compile PHP onto the .NET Framework. This means integration between C# and PHP will be simple. I haven't tried this but it might satisfy your requirements.
What "technology" would you suggest to exchange some kind of messages between a Java server and several clients written in C#, Javascript and Java?
The background story:
In our current project we're trying to build a generic UI backend in Java (running on the server) which is then "bridged" into several UI frontends by means of different UI adaptors (running on the client, the server, or both). While our server technology will always be Java, there will be C# (Silverlight), JavaScript and Java clients. Maybe even more in the future (different Smartphones, Tablets).
The UI backend and UI frontends communicate through a bunch of more or less simple messages (mostly name/value-pairs) each of which encapsulates a specific property/state/data change on the client or server respectively. Within a single request cycle, several such simple messages are aggregated into one big message which is then passed from backend to frontend or vice versa. At the moment sending and receiving messages is done at a single entry point on the client as well as on the server. So there are no server methods exposed as WebService etc. - simply because this would most definitely be to slow in our case.
Our current prototype consists solely of a Java server, a Java Desktop Client (Swing) and a Java Web Client (Vaadin). The message exchanged between backend and frontend is effectively a list of POJOs (each representing a specific "change") serialized/deserialized to/from XML. So far, so good.
Now C# and Javascript come to the table. Since we want to work with some kind of object in each technology, we thought it would be a good idea to specify the messages/changes/pojos in some kind of abstract language and then generate objects for each target language. At some point these objects could then be serialized/deserialized and sent over the wire (probably via http/s). For this purpose we thought of Google's protocol buffers or Thrift. What do you think?
For the moment our synchronous request-response-cycle is enough but we will need asynchronous request-response or server-push respectively pretty soon. That's why we thought of using something like ActiveMQ straight away. What do you think? Too much? If not, how can we accomplish the object generation mentioned above (xsd, jaxb, ? for js)? Are there better ways? I've never used ActiveMQ but according to the website it should be possible with Java, C# (Spring.NET) and somehow with Javascript (STOMP) too. However, this seems pretty complex to me...
Any tips, hints, experiences or comments about this or related topics would be really helpful.
Thank you in advance.
I would recommend using webservices. The WSDL language defines objects and messages of your protocol in abstract form. Most modern languages like Java and C# have tools for converting WSDL to native types and libraries for handling I/O.
For the last two years i have been involved in building a similar system: backend for our project is c#, java and bunch of other languages, frontend is phone clients for ios, android, symbian, all the common webbrowsers and even windows desktop apps.
For all these services we use JSON, since it seems to be most widely supported format across all languages and platforms, it decodes fairly fast on the clients compared to xml based solution (esp. webbrowsers/javascript) and it has a pretty low overhead that compresses extremely well which is great for clients that lack bandwidth.
I want to make a chat server by using .NET technology (C# and SQL server) and chat clients with iOS Apps and C# Apps but i don't know where to begin :( Anybody can tell me what i need to know to do it :(
What you are trying to do is perfectly possible.
If you are doing it as homework of for the sake of learning, I would suggest start learning some general Network Programming concepts (sockets, TCP/IP, protocols). After that, you will need to learn of to do Network Programming in .NET and in C (or Objective-C). After that, you will need to design and implement a CHAT protocol (unless you are planning to use an existing one like IRC). Then, jump into coding the server in C# or VB.NET, and the client in C, C++ or Objective-C.
If you are trying to develop a product, try reusing as much components as you can. For example, use Jabber or IRC as your communication protocols. You will find several libraries you can use in C#, Java, Objective-C and C to implement the software you are planning to.
the ways I can think of
Web service or soap
Socket
Database table
shared file
Any concise example you know of for webservice?
Web services or soap would be fairly easy, however, if the C++ application isn't a web server naturally (or the C# application), it may be easier to just use socket programming directly.
Sockets are fairly easy to use from both C# and C++. They give you complete control over the type of date transmitted, at the cost of potentially a little more work in the handling.
The biggest issues to watch for are probably endianness of binary data, and encoding of text data, if you use sockets directly. Otherwise, it's very easy.
Since you are already aware of the Web service and socket approach, I'll mention some other options. If you like simplicity, check out XML-RPC. This is what SOAP was before large standards committees and corporate interests began to control the specification. You can find implementations of XML-RPC for just about every major programming language out there. Hessian is an interesting binary protocol that has many fans and supports just about every major language as well. Protocol Buffers is popular within Google. The official version from Google does not support C#. However, the two highest rep users of SO do provide ports of protobuf for the .Net space.
I will probably be ridiculed for this, but also take a look at CORBA. It's not in vogue these days, but has many substantial technical creds, especially if one end of the communication is C++. IMHO, it's WS-* with OO support and no angle brackets required. For interop, I think it still should have a seat at the table. When engaged in C++ development, I found OmniOrb to be quite effective and efficient. Take a look at this SO Question for some pointers concerning using CORBA in .Net.
Sockets are easiest; and I would always go for that first. If database is an option, that's also trivial, but that would really depend. If it's queued events, that would make sense, but if it's request/response, it's probably not so great.
you can use gsoap to have a C/C++ program use a webservice.
You can also call a cgi program that is written in C++.
I have written a server in C that communicated with a C# client, and the endianess can be a pain to deal with, webservices is so much simpler.
Do you want it to communicate with each other (for instance, through tcp (like many others have pointed)) or do you want to be able to translate objects from C# to C++? If so, check out Apache Thrift (http://incubator.apache.org/thrift/).