The "complexity" and "risk", perhaps has more to do with having multiple
language environments, multiple skill sets. The design and architecture are
really very clean.
And that's why I don't understand your recommendation to Rob. He stated
his language of choice is PHP and then you lambast him for not responding
to your RPG approach with database triggers. That's where my "more than
one way to skin a cat" comment came into play.
I understand the need for triggers/queues/etc. But in his case a better
approach (or at least what I'd recommend) is to queue a request back into
his PHP app via REST webservice that determines whether an email should be
sent. This approach serves multiple things:
1 - It keeps him entirely in PHP.
2 - It allows the PHP UI to immediately respond to the user without waiting
for the email to be sent.
3 - It keeps from starting another PHP runtime by invoking the PHP
webservice.
On a similar note: Something I came across recently was an AWS (Amazon Web
Services) interview** where they determined to make all of their
interoperation decoupled API calls (which I read to mean some form of web
service, though I am not certain). This type of architecture could afford
a multi-language environment to work better. In some ways this is what
XMLSERVICE affords us with simple calls to RPG from
PHP/Ruby/Node.js/.NET/etc.
**
http://www.crn.com/news/cloud/300077657/andy-jassy-amazons-6-billion-man.htm
Do you plan for the future, or not?
After the fifth child, yes, I got a vasectomy. Nothing like going deep in
relationships on WEB400. ;-)
Aaron Bartell
litmis.com - Services for open source on IBM i
midrange.com
