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.
Related
I am learning about REST apis and after some time of researching, I know the basics of how REST works and I can write an api that generates a JSON response in the web browser with appropriate url. However, I can't seem to understand what is the purpose of it. Surely just generating JSON response seems useless for production application, as you have to assume that most of your website visitors won't even know what JSON is, so there must be some other uses of rest api that I still don't know about. I have been searching a lot about why I should use a rest api, but besides websites praising it ("because it is scalable, portable, flexible" and so on and on) and saying that JSON is simpe yet powerful data exchange format, I have found no concrete answer.
As of this particular case, I am learning to develop RESTful api with Spring. I understand simple CRUD actions using #RestController, but It seems ridiculous to just sent JSON object as a response and especially to expect a client to understand JSON data.
So I am guessing that there must be some other uses for RESTful api that I am not aware of and can't seem to look up either.
So my questions are:
Why should I write RESTful controller if all it does is generate JSON data as a response.
1.1) I am assuming that it IS NOT all it does, so why is it necessary exactly?
Where and what should I use JSON data for?
I know that I am far from understanding this fully, so there probably are many misconceptions, but I want to understand the reasoning behind everything I do and not blindly follow whatever studying resources say, so I am asking it here. Thank you for your time
Its very important to understand that API (yeah, capital letters are quite important) is acronym for Application Programming Interface, it is not user interface, it is interface for other programs/applications to use.
So, API will be used solely by some other code to exchange data (interface with each other) and to do this you need some structure or protocol to follow by both sides of this exchange, otherwise applications will not understand each other.
So, you decided that your application (service) will provide some API for other applications (again, not users), you decided what kind of functions those applications will be able to consume (like get current weather, or create new user - basically methods in your controller).
Next step is to define protocol - how exactly information will be presented on wire (serialized to binary stream, because you can send only bytes via physical connection), JSON is quite popular choice because it provides quite easy format to parse for application (libraries for JSON exist for almost any programming language), but also is still readable enough for humans (there many offline and online formatters to help you).
But, JSON is not most efficient in terms of space, this is why you can pick many others - BSON, protobuff, kryo, java RMI and so on.
Now, lets actually answer you questions:
Why should I write RESTful controller if all it does is generate JSON data as a response.
Because you as developer decided to provide API for others, and you decided to use JSON as data format, and you decided so (probably) because it is quite famous and easy to work with, it is provided by default in many frameworks, etc, but there is no real objective reasons for that, several years ago SOAP/XML was holding the same niche, for the very same reasons.
Where and what should I use JSON data for?
Anywhere and for everything where you think it will fit: non performance critical inter-service communications, config files, personal notes, structured or non structured data, JSON is very flexible format (as almost any other generic purpose one, like XML or simple text files).
A ReST API will usually be called by another service or e.g. by a JavaScript based frontend application, not directly by users. JSON can be processed quite comfortably by other applications, that's why it's widely used (by now there are other formats as well, especially for high performance applications, but that's on an advanced level).
So to your questions specifically: If you are offering a service, that will be used by other applications, then use a ReST API with JSON responses, if you are offering an application that will be used by users directly, and don't want to have a JavaScript frontend application, you would use something like Thymeleaf to implement the frontend and have that returned in your controllers.
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).
I have a client set up to send a request to the National Weather Service SOAP server. I am receiving the response that I expect, but I am unsure as to the best way to extract the data from it that I need.
For example, there is a lot of extra data in the XML (in the SOAPBody), but I only want to grab the data for the parameters that I set (such as temperature) to my POJO.
What's the best way to extract this data?
I started out trying to consume SOAP Web Services by hand like you describe - there are better ways.
There are libraries out there that will do all the work for you - no need to parse anything by hand.
Check out JAX-WS. Most Modern IDEs (Certainly Netbeans and Eclipse) also provide point and click support for building web service clients given a WSDL.
The biggest potential problem down this route is if there's no WSDL, or the WSDL is wrong, in which case the tooling I've linked might struggle.
The next safest thing would be to use an XML Parser like JAXP's SAX & DOM etc (they're right there in your JRE) to parse the response and then walk the data structures involved.
Finally you could go the string hacking route using splits or regexes but down that path lies a great deal of potential pain - there's more to the XML spec then nested tags.
It's strongly receommended that you not try and decode SOAP by hand :)
Just to expand on what #Brabster said,
Netbeans has extensive Web Service support, especially using the JAX-WS library.
http://www.netbeans.org/kb/60/websvc/jax-ws.html#Exercise_3_1
I'm looking for a Java library for SWIFT messages. I want to
parse SWIFT messages into an object model
validate SWIFT messages (including SWIFT network validation rules)
build / change SWIFT messages by using an object model
Theoretically, I need to support all SWIFT message types. But at the moment I need MT103+, MT199, MT502, MT509, MT515 and MT535.
So far I've looked at two libraries
AnaSys Message Objects (link text)
Datamation SWIFT Message Suite (link text)
Both libraries allow to accomplish the tasks mentioned above but in both cases I'm not really happy.
AnaSys uses a internal XML representation for all SWIFT messages which you need to know in order to access the fields of a message. And you need to operate on the DOM of the XML representation, there is no way to say "get the contents of field '50K' of the SWIFT message".
And the Datamation library seems to have the nicer API but does not find all errors.
So does anyone know other SWIFT libraries to use?
Have you looked at WIFE? We use that in our application which translates SWIFT messages to an internal XML format and back again. We haven't had any problems with it. Also, it's licensed under the LGPL, so you can hack it up if you need to. Check it out.
SWIFT is releasing a "Standards Developer Kit" which includes an "MT/XML Schema Library".
From the doc:
"The MT/XML Schema Library is a complete set of XML schema definitions for MT messages, and software which shows how to convert messages from an MT format to an MT XML representation and back. This approach allows XML integration between applications while the MT (FIN) format will continue to be transported over the SWIFT network."
Java source code will also be made available, again from the doc:
"Working sample Java source code that converts a message in MT format to an XML instance and from an XML instance to a message in MT format."
See: http://www.swift.com/support/drc/develop/standards.page
This can be a great aid in dealing with FIN messages in XML syntax.
You can combine the open source implementation WIFE with the commercial validation component from http://www.prowidesoftware.com. It validates that the messages you create with the model or XML representation are good through SWIFT network validation rules.
There is a product call Volanté that make a great job. Their solution is certified by SWIFT and the integration is easy ( I sound like I'm working for them ... I'm not). I've been using it since a couple of month .
IBM is also offering a solution (cannot remember to name right now) but then you are committed to the big blue.
If your company is not comfortable with the LGPL license, You might want to check Progress Sonic ESB, or ArtixDS (recently acquired), TIBCO ActiveWhatever or Oracle/BEA Aqualogic. Chances are you are already using something from these companies and you can get decent discount.
Along with jodonnell, we also use WIFE. It works very well. I'm not sure if it does the network validation rules (#2 on your list) though.
paymentcomponents (http://www.paymentcomponents.com/) parser was easy to use and found all errors. Their site definitely needs work but if u look there, u'll find what u r looking for
I can not really help you out with a Java implementation. Microsoft of course, have their own Biztalk adapter for ISO15022 and 20022. And they will actually do the validation fairly well. But as you say you are actually looking for a java solution.
You might find, as I did when I researched this 6 years ago, that mapping FIN messages to XML and then to into objects, a standard library will only get you partly to your goal. You will have to integrate this with your backend application and whatever market practices you face in the particular messages you need to support.
I finally ended up writing a generic FIN parser /150022 class library in c++.
Anyway, good luck. An idea is to be more specific in your question. What types of messages do you need to support?
Datamation's libraries have evolved since then. If you need a corresponding solution in 2021, you can check FINaplo by PaymentComponents (formerly called Datamation), a multi-purpose implementation for financial messages.
It provides online validation/parse/translation/envelope services, Java SDKs, as well as REST solutions, all including error specifications. I am actually one of the authors.
A demo for a SWIFT MT Java library can be found in this GitHub link.