I could not find any documentation around this on Apache Camel website.
How and what types are supported in the communication between the components in Apache Camel. I would like to understand the magic that happens inside it. Because the doc just says you consume data from a file system or FTP, a message from JMS, SQL data and tons of other possibilities and send them to a producer that magically seems to accept anything and output to tons of possibilities also.
Do they wrote converters for all to all types in the framework?
And I wonder the same question around enriches. All this connectors seem extremely flexible and I could not find any reference to what supports what in there. I'm willing to write a component for a system and I couldn't find a good way to do it.
Do I have to write converters for all possible types that can come?
I have seen that camel works with the Exchange class and it uses it to send back and forth the messages between components. It is pretty vague in my mind how the components deal with different possible message types.
I recommend you to take a look at "Camel in Action" book by Claus Ibsen and Jonathan Anstey. I used to have questions like those. They are perfectly answered there. Chapter 11.3 will guide you through creating your own component. Also, you can check out this github link to start with. It has an example of how to create your own component.
Camel may to know what types you pass in the message body, so it offers you multiple ways to transform the payload, starting from creating a processor for transformation, to using a java DSL transform method which accepts Expression.
Just be ready to handle a case, when an unknown object is consumed. Don't worry about all the incoming objects.
It all depends how the Consumers are implemented.
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.
Have a web service that implements REST (sort of) ,
Client request is made for some entity
Server populates a model (that was created with JAXB)
Converted to Xml and sent back
Client reads Xml into same JAXB Model
This works fine, but i dont use any REST libraries.
Am I missing out, I cant see what complexity they could hide because the code to send /receive a request and convert to/from JAXB is already pretty simple.
For your basic use case, you will probably not benefit a lot from using JAX-RS(http://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services), which is the Java standard for REST.
However, as you can see if you follow the link, there are some useful annotations, which might make your life easier later on. For example, if you would start returning plain text next to xml as well, based on request header, that becomes incredibly easy to configure(with #Produces).
Same for when you want to support multiple types of request payloads(#Consumes).
Check http://docs.oracle.com/javaee/6/tutorial/doc/gkknj.html for a good tutorial.
In short, JAX-RS offers a lot of useful functionality with regard to request headers, parameters,etc.. that would otherwise be harder to implement.
However, many applications do not need this "full fine-grained REST" support, so sticking with just JAXB might be enough for your needs.
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/
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.
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.