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.
Related
One of benefits of using Jackson for JSON processing is:
all modes [i.e. streaming, tree, and binding to Java objects] fully supported, and best of all, in such a way that it is easy to convert between modes, mix and match. For example, to process very large JSON streams, one typically starts with a streaming parser, but uses data binder to bind sub-sections of data into Java objects: this allows processing of huge files without excessive memory usage, but with full convenience of data binding.
Are there XML processors for Java or Scala which also support this scenario?
Maybe you want to check out Smooks
http://smooks.org
HTH
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).
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!
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).
Pals,
I have a requirement to establish a communication channel between C++ and Java layer of my application for the exchange of objects and their properties.
I have got the following options:
XML / SOAP
Postgre SQL
Can you please advice me the Pros & Cons on these. Please share your experiences on the implementation complexities.
Thanks,
Gtk
If the option is between those I would choose XML
Object <=> XML
Java side Simple, C++ side XML Objects
Reason, its simpler for what you want, i.e. pass language objects and not Data Base
Ah, could you specify the communication channel between the apps ?
UPDATE
If you can use JSON I would recommend it instead of XML, here is why.
Another option would be JMS. There are C++ clients out there.
Every time I see XML I think RESTful web service. Both platforms you mentioned have some form of tooling to marshal & unmarshal XML. There are plenty of working examples out in the wild, so a Google/Bing search is good. A nice side-effect is once you have those interfaces built, anything can connect to them.
If you really want to bother with generating a WSDL, then feel free to go the SOAP route. However, speaking with several years of web service integration experience, RESTful is so gosh darned simple compared to anything else.
I would like to suggest a third option : YAML
You have parsing library in YAML for both java and C++. In my experience, it's easier to debug exchange in YAML that in XML (especially if you got full text field or cyclic data structure).
I depends of the kind of message you transfer.
If your message are individual entity that have a short live, I would go for XML, YAML or something similar.
If your message contains information that is going to be used later on and refer to information in previous messages, I would use a database.