Article: Application Integration Through Mail Servers
- Share
-
- |
Read later
Reading List
In this article, a book excerpt from Open Source ESB in Action, Tijs Rademakers and Jos Dirksen present a way of integrating applications through mail servers when speed and performance are not paramount. The article shows how to use SMTP and POP3 protocols from Mule and ServiceMix to communicate back and forth with Apache James, an open source mail server.
Read: Application Integration Through Mail Servers
Rate this Article
- Editor Review
- Chief Editor Action
Submit
Submit
Related Sponsor
Are microservices really just “SOA done right”?
Download this exclusive O’Reilly Report to find out.
Hello stranger!
You need to Register an InfoQ account or Login or login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think
Community comments
Come on guys. This is stupid. Why would anyone want to go through all this
by
John Wheeler
Posted
Re: Come on guys. This is stupid. Why would anyone want to go through all t
by
Andreas Breiter
Posted
Re: Come on guys. This is stupid. Why would anyone want to go through all t
by
Gregor Rosenauer
Posted
Re: Come on guys. This is stupid. Why would anyone want to go through all t
by
Christophe Hamerling
Posted
Re: Come on guys. This is stupid. Why would anyone want to go through all t
by
John Wheeler
Posted
Re: Come on guys. This is stupid. Why would anyone want to go through all t
by
Dan Doyon
Posted
Re: Come on guys. This is stupid. Why would anyone want to go through all t
by
Porter Woodward
Posted
Message Broker
by
Bob G
Posted
Nitty Gritty of ESB
by
C L
Posted
Come on guys. This is stupid. Why would anyone want to go through all this
by
John Wheeler
trouble to make something so slow and convoluted work
Re: Come on guys. This is stupid. Why would anyone want to go through all t
by
Andreas Breiter
Because it works, is easy to implement and every company has a mail server.
We use e-mail and SMS to interface with Lufthansa. We only get sporadically messages and they already had it, so there was no need to re-invent the wheel...
We use e-mail and SMS to interface with Lufthansa. We only get sporadically messages and they already had it, so there was no need to re-invent the wheel...
Re: Come on guys. This is stupid. Why would anyone want to go through all t
by
Gregor Rosenauer
Imagine human workflows or HumanTask's - you get an incident message, work on it, and when done, forward it to the "done"-box, from where the system picks it up and continues...
Or mobile services where users interact with the system via SMS or e-mail.
There are many useful applications for such a scenario. I own the book and can highly recommend it.
Or mobile services where users interact with the system via SMS or e-mail.
There are many useful applications for such a scenario. I own the book and can highly recommend it.
Re: Come on guys. This is stupid. Why would anyone want to go through all t
by
Christophe Hamerling
I really think that you do not understand SOA... This article is just an introduction of what you can do with ESBs. Of course you can say why do I need an ESB and tons of configuration to send an email but SOA and ESBs are not limited to that simple case!
Re: Come on guys. This is stupid. Why would anyone want to go through all t
by
John Wheeler
I wouldn't go so far as to say any of this is "easy". It seems complicated and convoluted. If performance and speed aren't issues, then why not just opt for standard messaging as to get the fault tolerance along with it? I could be wrong, but at first glance, this integration approach seems redundant, more complicated, and if I saw it in the wild, I'd probably assume developers were just over complicating things for fun and profit like some of us unfortunately sometimes do. As far as Gregor's use case goes, I am assuming this can be used instead of something like OSWorkflow, but you'd have to manually program the workflow since all this buys you is the work baskets essentially.
Message Broker
by
Bob G
Hello,
Although this example seems a bit naïve, it does provide some good functionalities out-of-the box. Before implementing a full blown JMS solution, we might have to consider the followings:
- Most of JMS brokers do not provide any centralized message auditing out-of-the-box (i.e. saving all message content that went through a queue). It is built-in a Mail server with archiving etc.
-When it comes time to view ,sort, move, copy messages, don’t count on a WebsphereMQ client tools to help you. Using an email server you can leverage the use of a good email client to interact with your messages.
-Everybody knows how to send an email. Sending MQ messages using JMS (without Spring) is not the easiest task.
That said, if you are building an enterprise solution (with time, skills and money), you might consider other approaches.
Cheers
Although this example seems a bit naïve, it does provide some good functionalities out-of-the box. Before implementing a full blown JMS solution, we might have to consider the followings:
- Most of JMS brokers do not provide any centralized message auditing out-of-the-box (i.e. saving all message content that went through a queue). It is built-in a Mail server with archiving etc.
-When it comes time to view ,sort, move, copy messages, don’t count on a WebsphereMQ client tools to help you. Using an email server you can leverage the use of a good email client to interact with your messages.
-Everybody knows how to send an email. Sending MQ messages using JMS (without Spring) is not the easiest task.
That said, if you are building an enterprise solution (with time, skills and money), you might consider other approaches.
Cheers
Re: Come on guys. This is stupid. Why would anyone want to go through all t
by
Dan Doyon
I recently worked on a project where we needed to connect a couple of systems and decided to use existing exchange server (IMAP accounts) and a few python scripts for the glue. It turned out to be a nice way of doing things. We got a free gui (outlook), it was easily unit testable. When the mail server was down for maintenance, no problem, things just resumed when it came back up. Was it an elegant solution? Depends on who you ask. Durable? It did have a little brittleness but easily traceable. At the end of the day, we got it running quite quickly. It required little interaction from a subsystem we treated as a blackbox. If the need to replace with a more durable, sophisticated messaging construct is required the scaffolding in place.
my 2 cents
my 2 cents
Re: Come on guys. This is stupid. Why would anyone want to go through all t
by
Porter Woodward
Well, the example is trivial. It's just intended to show off how to send/receive mail messages in the most basic sense. Keep in mind though - that once that information is sent/received - there's potentially a lot you could do with it.
How about building a photo posting service? Just email your photo from your cell phone and it gets posted to your online photo album.
One of the nice things that an ESB can do for you is abstract away the protocol details. Your core application for handling the posting of a picture to the album doesn't change... And it then becomes pretty easy to introduce new end-points (email, web forms, sms, ftp, etc) without writing much (if any) new code.
How about building a photo posting service? Just email your photo from your cell phone and it gets posted to your online photo album.
One of the nice things that an ESB can do for you is abstract away the protocol details. Your core application for handling the posting of a picture to the album doesn't change... And it then becomes pretty easy to introduce new end-points (email, web forms, sms, ftp, etc) without writing much (if any) new code.
Nitty Gritty of ESB
by
C L
I know that this solution is convoluted and troublesome, but it's nice to see how ESB actually works, since it actually does work even if it's alittle complicated. Some companies are still using this way of implementation to get their information through their pipelines. You could say that it's old school.
