Where's the problem? I know at least two ways for automated mail
processing in Java EE:
(1) Java EE allows you to query for a JavaMail resource. Using that, you
can check your mail inbound using POP3. If you do that in a timer (e. g.
from inside a MDB) it should be no problem to regulary process your mail
inbound.
(2) Java EE allows you to attach to a JavaConnector. There should be
SMTP connectors on the market that serve as SMTP receivers and push a
MDB in your application.
Both is 100% pure Java EE and a straightforward solution. I cannot see
anything bad here.
Either way, as soon as an email was processed, an MDB will be triggered.
>>From that point, all the rest should be a breeze. If you need help, just
write. :-)
Have Fun
Markus
> Folks;
>
> in the process of moving some of our internal apps to JEE/glassfish, I
> have kinda hit a wall right now: Right now we do have a scripted-up
> (Perl and Unix-shell) to do automated processing of incoming (SMTP)
> e-mails, which works more or less bad and is just more or less
> manageable. I want to rebuild this solution in JEE, so I mainly have to
>
> - handle inbound (SMTP) messages
> - extract information using their headers
> - extract body text (if present)
> - dump attachments (if any) to some file
> - import all the mess to our backend DMS.
>
> By now, I considered several options (including implementing a
> message-driven bean and "somehow" let it deal with the
> javax.mail.Message object in question), but somehow all of them seem
> more or less flawed.
>
> So, question: How do you folks handle situations like this from an
> architectural point of view?
>
> TIA for any recommendations, best regards.
> Kristian
>
>
--
http://www.xing.com/go/invita/58469