Hi Igor,
What you exactly mean when you mention by “very memory intensive application and very data access intensive”?
MEMORY: I’ve worked with integrations using webMethods handling 10-30MB of data, and did not experience any hiccup. I don’t have the host machine details (on which the IS ran) but I knew that it ran HP-UX and the IS’s underlying JVM was configured to have 4GB of memory. I believe that the IS can handle large loads without a problem.
But the size of the memory eaten by a single thread is only one side of the history. What about the estimate number of concurrent transactions? Is this server being shared among other integrations as well? And the list of question goes on.
DATA ACCESS: you know, this might depend on hardware and software as well. Is the network hardware doesn’t support the load, no matter how good software you have, you won’t go over “the roof”. And yes, I know that a badly designed software can make data crawl like a snarl, but this kind of situation is easily found and mitigated. When comes to hardware, no matter how you squeeze the code to have the best optimization, it won’t go over the limits dictated by the hardware.
Additionally, the overall architecture design can make the whole difference.
Having all this said, the real criteria behind choosing webMethods, .NET or Java or whatever other language is not whether it is memory, data access or CPU intensive.
#webMethods#Integration-Server-and-ESB