Suppose we have a remoting enabled application with server and client components, which can run on different machines.
Now we have a set of files containing data that need to be saved to DB via server. We can have 2 approaches:
1). Convert the data into a list of Objects, serialise them and send them over to server
2). Serialise the files and send them over to server
Is there difference between the two approaches? How do I test them?
Sending the files as they are is always going to be more efficient than translating them into and out of different formats at both ends.
You should probably define a little API for the server (the file format it expects e.g. CSV or JSON with some schema) and send it the files in that format. If you are only going to have to interact with one client then the format might as well be whatever the files are already in. Otherwise make it more general and the client must convert the files to that format. I wouldn't use Java serialisation as it is very fragile - generally the client and the server have to have the same versions of the classes involved (you can use readObject and writeObject and version numbers to work around this but its not worth the hassle).
Related
An application that I am currently working on contains several files of the above mentioned type. These files are created using NSArchiver from an legacy framework called OpenStep.
If I am correct than this is a data format which was used pre and begin OS/X and is now replaced by NSKeyedArchiver. Although I think current OS/X implementations of NSUnArchiver can still read this older format.
When opening these files there are some contents which can be read by humans like dataformats such as BlockArray, NSObject etc. The rest is binary data which does not make sense.
I have to be able to retrieve information from these files to process further in a Java based application. I would love to know what you would advise me to do in this case so that I am able to use the information in these files.
A side note:
The GNUSTEP implementation does not support this typedstream data.
My main application is written in Java.
Preferably a solution which does not require me to develop on the OS/X platform.
Solution should run on Windows platform.
What is the most efficient (uses least amount of bandwidth) method of sending a java bean from a java application to a Spring MVC servlet?
I am currently using XML, but I think it's using more bandwidth and more time to serialize the bean into XML because it is more verbose, which I do not need, because it's being transferred directly from one application to another, where no person is actually reading the serialized data.
JSON could be an option I guess..
What I understand here is that the two applications are not in the same VM and you need a way to pass on data between these two application. If it is so, here I would suggest you to use below approach:
Try using Java's default serialization and stream the output to
next application.
Optionally, you should use a compression mechanism (like gzip api in java) to compress the serialized file.
Also, if you want to stick with XML version, you can add compression step to reduce the size of the xml. This should be a minimal code change, if it is an existing application.
Environment
My application (war) has a JavaScript frontend and a Java REST service.
The files to be uploaded will be generated in the frontend, but not directly by user interaction -- this is not a use case where the user is uploading files herself. For that reason, it's necessary to initiate the upload from the JavaScript code.
I need to be able to send metadata (generated by other parts of the application) about the binary data when I'm uploading it -- which is why I need some sort of protocol instead of just uploading a file.
Question
What I haven't been able to determine is what the best practice is for uploading files, with regards, primarily, to the protocol used.
I've come across the following protocols:
json
xml
proctol-buffers (via protobuf.js)
However, the internets has, as usual, lots of different info that hasn't been giving me a coherent picture:
With regards to reliability, the internets seems to say that you're better off using the multipart/mixed type to transfer data, instead of the pure application/octet-stream type.
json doesn't natively doesn't support binary data, and apparently, Base64 has a high processing overhead.
It's a JavaScript frontend, so json would be preferred.
Sure, I could use protobuf.js, but I'd rather use leading-edge tech than bleeding-edge tech.
My priorities are:
reliable data transfer of files between 1 and 10 megabytes.
performant and efficient data transfer.
readable code/architecture
In short, which of the 3 formats mentioned above fits those requirements the best, given that I'm using a Java REST service on the backend?
(If the fact that I'm using a Java REST service -- instead of say, a servlet -- to upload the files is going to be the biggest slowdown, that's also a good answer!)
EDIT: added information asked by the comments -- thanks!
I'm currently working on a project which needs some server-client communication. We're planning to use Websockets and a Java server (Jetty) on the server side. So, messages sent must be interpreted with Java from the server and with JavaScript from the client.
Now we're thinking about a protocol and which structure the messages should have. We already have a reference implementation which uses XML messages. But since JSON is designed to be used with JavaScript we're also thinking about the possibility to use JSON-Strings.
Messages will contain data which consists of XML strings and some meta information which is needed to process this data (i.e. store it in a database, redirect is to other clients...). It would be important if the processing of the messages (parsing and creating) would be easy and fast on both server and client side since the application should feature real time speed.
Since we have not the time to test both of the technologies I would be happy about some suggestions based on personal experience or on technical aspects. Is one of the technics more usable than the other or are there any drawbacks in one of them?
Thanks in advance.
JSON is infinitely easier to work with, in my opinion. It is far easier to access something like data.foo.bar.name than trying to work your way to the corresponding node in XML.
XML is okay for data files, albeit still iffy, but for client-server communication I highly recommend JSON.
You are opening a can of worms (again, not the first time).
have a look at this JSON vs XML. also a quick serach on stackoverflow will also be good.
this question might be duplicated across. Like this Stackoverflow XML vs JSON.
In the end answers stays the same. It depends on you. I though agree with many comments there that sometime, XML is overkill (and sometime not).
I agree with Kolink,
The reason, it is better to use JSON because the XML has a big Header, which means each transfer has a big overhead.
For iOS or Android, you have to use JSON as opposed to WLAN XML.
I agree with Kolink, but if you already have an XML scheme in place, I'd use XML to save you some headaches on the Java-side. It really depends on who's doing the most work.
Also, JSON is more compact, so you could save bandwidth using its format.
There seem to be some libraries for parsing JSON in Java, so it may not be too hard to switch formats.
http://json.org/java/
For a program i'm writing I need to marshal ActionScript classes to a format that is later to be read by Java (and back again).
What solutions exists for such a need ?
Is there a way (like when using Java through XMLEncoder/XMLDecoder) to generate that XML using standard flex libraries (that would be compatible with later decoding using XMLDecoder) ?
Or is there a good existing library ?
EDIT Yes, this question is a duplicate of Are there any tool mapping of JavaBeans to ActionScript Class through xml serialization and deserialization?, but I will accept correct answers and eventually start a bounty if no answer satisfies my needs. (in other words, i plan to make the previous - unanswered - question a duplicate of mine).
EDIT 2 To be even more precise, I have an application divided in two parts : one Flex GUI and one Java core. They communicate over a non http layer which requires data to be sent in XML. In this context, I replicated my Java objects in Flex (using GAS3) and now want some of these objects to be sent from Flex to Java and back again.
For that purpose, I have to serialize objects (on the Flex end) in XML and deserialize them in Java (and all that back again).
We are using http://www.spicefactory.org/parsley/index.php which supports XML-to-object conversions back-and-forth. Their documentation is very decent: http://www.spicefactory.org/parsley/docs/2.4/manual/.
See describeType function if you really want XML. But I seriously recommend considering the other serializations formats too.
You can look into JSON. The classes needed for the actionscript serialization/deserialization are part of the as3corelib library.
You might also want to take a look at BlazeDS.
Solution used was to put XStream on the java side and FleXMLer (with some adaptations that can be found there : https://github.com/Riduidel/FleXMLer) on the Flex side. it works quite good (once FleXMLer is adapted to XStream architecture).