I need to implement rather simple network protocol: there is device with microcontroller (language is C) and Java application, they should communicate: I need to implement firmware update, and maybe some other things.
At least, I need to transmit some data structures as headers.
Only ugly way comes to mind:
I can declare packed structure on C side, and handle somehow the same data flow on Java side.
So, if my structure is changed, then I need to make changes on both sides: C and Java. I strongly dislike this.
Is there some better way to do that? Maybe, something like this: I should write protocol structures in some special format, and then some utility can generate code for C and Java sides.
Or, maybe, something different.
I would be glad to see suggestions.
You might want to look at using a standardized notation for data transfer such as JSON. Here is some info on parsing JSON in c.
Parsing JSON using C
If it were my project I probably would go with just packed data structures. Hopefully once your project matures changes to the data structures are minimal and only occur during major releases. You can keep a version tag in the data structure to handle legacy data formats if needed.
One common solution to this problem would be to use Google's protobuf. However, as you
specified that you need it to work in a microcontroller environment I think you could look
into protobuf-c, which is a pure C-version of protobuf.
Could you describe details of protocol? Is if statefull or stateless?
If your protocol is stateless, then take a look at web-services (especially, REST-WS). This is well known cross-platform communication practice.
Related
I know that XML can be used so that programs in different programming languages could communicate.
E.g. a Java server with C and Python clients.
Could JSON be used as an alternative? I mean also if it can should I go for it? Especially in a case where the clients are not controlled by me.
Would you feel that implementing such a client XML would be prefered?
Yes, you can. Just use appropriate Json libraries on both ends (e.g. JsonCPP on the C++ side, or jansson in C). And learn more about json-rpc.
The big advantage of JSON over XML is that it is simpler (to understand, to implement, to use) and probably less verbose (so shorter messages).
You could also consider YAML which seems less used, but is more "powerful".
Don't forget to document quite well your JSON protocol (i.e. messages).
Yes, you should JSON.
There are many libraries for JSON in nearly all well known languages. And a JSON file with the same content as a XML file is about 75% smaller. So you should use it :D
Per your question of should you do it, I think it's an appropriate use. In the end you simply need something that both ends of the conversation can handle. You could use XML or some other alternative, but I don't think it's any better/worse from a 'should you' perspective.
Sorry for the separate answer. Lacking the rep to comment...
You can, but you should not. Don't get me wrong, JSON is OK as data-interchange languages go, but the XML serialization packages for just about any language are much more mature than most JSON packages. Yes, XML is larger than JSON, and there's good reason - it carries a lot more descriptive information than JSON does. And the more diverse your "endpoints" are, the more that information can help in maintaining robust communication.
We have two code bases, one written in C++ (MS VS 6) and another in Java (JDK 6).
Looking for creative ways to make the two talk to each other.
More Details:
Both applications are GUI applications.
Major rewrites or translations are not an option.
Communications needs to be two-way.
Try to avoid anything involving writing files to disk.
So far the options considered are:
zero MG
RPC
CORBA
JNI
Compiling Java to native code, and then linking
Essentially, apart from the last item, this boils down to a choice between various ways to achieve interprocess communication between a Java application and a C++ application. Still open to other creative suggestions!
If you have attempted this, or something similar before please chime in with your suggestions, lessons learnt, pitfalls to avoid, etc.
Someone will no doubt point out shortly, that there is no one correct answer to this question. I thought I would tap on the collective expertise of the SO community anyway, and hope to get many excellent answers.
Well, it depends on how tightly integrated you want these applications to be and how you see them evolving in the future. If you just want to communicate data between the two of them (e.g. you want one to be able to open a file written by the other, or read a stream directly from the other), then I would say that protocol buffers are your best bet. If you want the window rendered by one of these GUI apps to actually be embedded in a panel of the other GUI app, then you probably want to use the JNI approach. With the JNI approach, you can use SWIG to automate a great deal of it, though it is dangerously magical and comes with a number of caveats (e.g. it doesn't do so well with function overloading).
I strongly recommend against CORBA, RMI, and similarly remote-procedure-call implementations, mostly because, in my experience, they tend to be very heavy-weight and consume a lot of resources. If you do want something similar to RMI, I would recommend something lighter weight where you pass messages, but not actual objects (as is the case with RMI). For example, you could use protocol buffers as your message format, and then simply serialize these back and forth across normal sockets.
Kit Ho mentioned XML or JSON, but protocol buffers are significantly more efficient than either of those formats and also have notions of backwards-compatibility built directly into the definition language.
Use Jacob ( http://sourceforge.net/projects/jacob-project ), JCom ( http://sourceforge.net/projects/jcom ), or j-Interop ( http://j-interop.org ) and use COM for communication.
Since you're using Windows, I'd suggest using DDE (Dynamic Data Exchange). There's a Java library available from Java Parts.
Dont' know how much data and what type of data you wanna transfer and communicate.
But to simplify the way, I suggest using XML or Json based on HTTP protocol.
Since there are lots of library for both applications and you won't spend too much effort to implement and understand.
More, if you have additional applications to talk with, it is not hard since both tech. are cross-languages.
correct me if i am wrong
I need a framework to transfer POJOs between two (or more in a client/server model) Java programs over TCP/IP. I need it to be as simple as possible but it must support several clients per server, and easy implementation of encryption is a plus.
So far I have looked at Java RMI, JRemoting, AltRMI and NinjaRMI. Right now JRemoting looks like the best choice as it is simple and don't require strange and seemingly unnecessary extends and implements as most of the others do. No active development seems to be going on on any of them except a little on Java RMI. I don't know if that is because they are stable and don't need more development, or because these kinds of frameworks are just not "cool" any more.
The POJOs are just bags of properties. I need the server to hold a static list of objects, and the clients must be able to (1) Read the list, (2) Add an object to the list, and (3) Remove an object from the list.
Any suggestions?
You could probably use any serialization technology, for example you could use JSON and add on encryption and compression later in order to cutdown the amount of traffic you are sending. JSON has the advantage of being language agnostic, so you don't restrict the implementation of either side of the connection.
Many JSON libraries are available; see json.org.
Do you need to do remote method calls, or are your POJOs just bags of properties? If the latter, it would probably be easiest to just use plain Java serialization.
look here: http://code.google.com/p/google-gson/
You can have a look on Protocol Buffers. I think Google uses Protocol Buffers internally.
Suppose I have a remote JAX-RS JSON API from a server running Tomcat. I want to access this API from a C/C++ client. Are there any tools available to make life easier for the C/C++ client, e.g. code generators? Or does anybody have a suggestion for an alternative?
I have never heard of such a tool. More to the point, I suspect that such a tool (a C / C++ generator for JSON) is impractical.
There are a number of reasons why. Some of the most significant ones are:
A key problem is that JSON doesn't have schemas. This means that an API generator would have to resort to looking at example messages and try to infer what fields to expect and what their types are. This can be difficult and even theoretically impossible in some cases.
In languages like Java and C#, there are straight-forward "right ways" to generate object APIs; e.g. the JavaBeans conventions. In C++ and especially C, the conventions are not there, and there are complicating issues like container protocols and memory management to deal with.
In languages like Java and C# are runtime type-safe, and have various language level mechanisms are provided that allow you to use dynamic programming to deal with the JSON's schema-less nature. For example, in Java you have reflection, proxy classes, dynamic code generation and dynamic code loading, all of which can help in dealing with JSON. In C and C++, these mechanisms are generally unavailable.
In short, if you are using C or C++, JSON libraries are as good as it will get.
FOLLOWUP
As a comment points out, this may be feasible to implement in the context of a specific JAX-RS-based server implementation. You'd need to get hold of the internal metadata, apply the JSON mapping to it, and generate C / C++ APIs from that. The problems are:
The generator implementation would be platform specific.
The C / C++ based client would not be able to cope with changes to the effective schema without regeneration of the APIs and corresponding client code changes. (By contrast, a JSON library-based solution can in theory be coded to deal with unexpected new attributes, etc)
You still have the container / memory management problem to deal with.
What you need is your choice of library for sending and receiving http requests, and a json parser. Nothing is going to generate code to make it easier for you because the idea of such an API is that it spits out JSON. The point of JSON is to go across language and transport barriers in a consistent way. A bit like XML, but simpler.
This question might interest you: what's the best json parser? JSON Spirit Looks like a particularly good article.
Now, as you're using REST, all you need is to communicate to the right urls. Done.
The final thing you want to decide is what libary to use for network communication. Boost would be many people's recommendation, I'm sure.
I am writing a client server iPhone app. The server is J2EE based.
I need to communicate the state of my client object (objective C) to the server. It is possible (and feasible) to say encode the objective C object, send the bytes to the J2EE server through a socket and create a Java object out of this stream. If so, can you kindly point me to a starting point.
Thanks in advance
Anything is possible, but that does not make it feasible. Except the technical difficulties these interfaces tend over time to create a lot of management headaches, example when one or both sides perform an upgrade.
I would seriously consider using some encoding to some platform neutral format like protobuf, thrift, JSON, XML or similar.
It sounds like it would be easier to serialize the Objective-C object to XML, JSON, or another text-based representation and ingest and unmarshal that in Java. To return it, reverse the process.
There are myriad ways to skin this cat. If you are using J2EE, you might even consider using a standard means of communication rather than rolling your own. For example, you could use a webservice, REST, etc. Objectice-C has good support for HTTP connections and it is fairly trivial to create an XML or JSON payload. SudzC is a great tool for creating a client proxy from WSDL.
Here are a few tools on the Objective-C side:
json-framework
SudzC