Hello guys,
We are building a services layer around a new insurance policy repository.
This is for a new getPolicy service whose responsibility it is to retrieve a specific insurance policy’s detail information (e.g. effective date, company, agency, coverages, exposures, premiums, etc.) and present the data to the consumer in the ACORD XML interface. The consumer’s request for information traverses many layers of services and orchestrations. The Data Access layer will hit the Policy repository many times building objects to ultimately pass back to the ACORD XML message construction process which is responsible for constructing the large and complex XML. This will be a very memory intensive application and very data access intensive. At this point I do not believe it will be very CPU intensive.
Should such an application be built in webMethods?
If you have an opinion, could you include pros and cons.
Thanks everybody.
Gary
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.