<snip>
Applications even if they are running on the same box will communicate via
web services.
Very interesting; WHY would you introduce so much complexity for a simple
program call simply for the sake of generic interface? This is flat out
Kool-Aid drinking (btw, I have partaken of this Kool-Aid when I first
started with XML 8 years ago - it is so sweet on the tongue but so bitter in
the stomach). Now on the flip side I FULLY promote modular programming for
re-use for a variety of purposes (i.e. develop an RPG *SRVPGM so it can be
called from SQL, from an XML web service, from JT400, from PHP, etc). But
that is a lot different that using web services to make calls from one
module to another on the *same* machine. Maybe you can expound on this to
correct any generalizations I am making.
</snip>
We have an application written in house that does this (app and web services live in the same boxes). It has proven to be a pretty bad idea. It works okay most of the time but when the app is busy or more than a few people ask for large amounts of data at the same time, the extra load kills performance. The last problem we had was caused by having to authenticate each time you call one of the web services.
We have an enterprise wide single sign on web service which had some performance problems (caused by another user of the service). Once we starting having problems authenticating, people started getting kicked out of the app and getting their accounts locked. Amazingly enough, the PHB that insisted it be coded this way has since discovered that this was stupid and wants to change it.
Once you understand what exactly has to happen for a web service call, it's pretty obvious that it isn't going to perform well (especially for chatty applications like the above mentioned app). First, you have the CPU and memory usage to build up a pretty bloated XML document and then you have to open a connection to an HTTP server that has to pass all that data to another application (more memory and CPU). That application has to then translate that XML file into what ever type of data structure it needs to deal with (yet more memory and CPU), do what ever it has to do (memory, CPU, other I/O), build up another XML document with its response (more memory and CPU), and send that back to the caller which will most likely then convert it into its own data structures. What about that process sounds like it's good for doing inter process communications?
Matt
As an Amazon Associate we earn from qualifying purchases.