Discussion Locked

ABRC Completes IBM Linux on POWER testing!

0 helpful
4 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Agile Business Rule Components (ABRC) successfully completed testing and validation of it's ABRC Suite Solution on IBM's Linux on POWER eServer platform. As an IBM Business Partner, ABRC utilized a large IBM pSeries located in Dallas, TX running Enterprise RedHat Linux in a dedicated LPAR consisting of (2) CPU's.

ABRC Suite enables business applications to utilize formal business rules to define and execute the desired business policies, behaviors and processing requirements. This solution consists of an Enterprise-class Java Rule Engine and integrated Java components to interpret and execute client's custom XML business rules.

The combination of 64-bit Linux, IBM P5 Servers and a truly revolutionary and optimized application solution produced the performance results we were expecting.

Please find the following links for more information and additional benefits!

IBM Global Solutions Directory Listing:
http://www.developer.ibm.com/solutions/isv/igssg.nsf/list/bycompanyname/86256F65004AEAFF86256F6A0062C961?OpenDocument

TechRepublic Article:
https://www.techrepublic.com.com/5208-6230-0.html?forumID=9&threadID=164296&messageID=1686053

4 replies

by jaqui

why take a performance hit by using interpreted language?
a "mission critical" solution will always need to be the fastest possible solution. java generally is 10-50% slower than c / c++
10% when compiled to bytecode.
50% when straight interpreted.

if I needed this type of solution even a 10% reduction in speed would be un-acceptable.
I would want a system that is operating as fast as is possible, so a solution done in asembly or c / c++ or cobol would be given prefference.

by gskinner

ABRC Suite represents an optimized software infrastructure that most often increases the calling application performance.

Each component in ABRC Suite has been profiled and optimized for maximum enterprise performance. This solution utilizes efficient database connections, very efficient object pooling, and patent pending caching for data and previous results needed downstream.

In addition by design, a rule engine solution often allows multiple process related steps to be combined and manual intervention in the processes to be completely eliminated. Remember, manual intervention is performed by knowledgeable and experienced humans capable of the decisions necessary to complete a process. A significant benefit of the ABRC Suite is this knowledge and experience can be captured in XML business rules, thus eliminating manual intervention and the protection of these most valuable company assets (expert business decisions).

The rule engine approach to application development produces efficiencies not possible in conventional development in any language. So there is never an exact comparison of an isolated block of legacy code being duplicated in the ABRC Suite solution, and no faster way for a calling program to receive back significant results (often times cached).

The performance improvement example of an insurance company 6 hour daily process being reduced to 10 minutes on the same servers was a prime example of efficiency resulting in true "enterprise application performance" improvement. (TechRepublic Article Link Above)

I agree with you that mission-critical applications must be efficient, scalable and high-performance!

For more questions or information, contact us!

by jaqui

while this may speed up existing applications, it is still slower than having coded it in assembly, c or c++ would offer.
the issue is with the language used, not the application or concept behind it.

interpreted languages are slower by nature than compiled languages.

even compiled java is slower than assembly, c, delphi or c++ are.

so, you have an application designed to speed up processes, but using a slower technology than it has to. see the rub, you are slowing it down by using java. it may be fatser than existing model but it isn't as fast as it could be, just by using java.

by gskinner

Modern Java technology JIT compilers now compile at start-up and then have the ability to ?optimize? the compiled code to the chipset the code is running on. For instance, the Itel Itanium 2 processors employ an architecture that allows ?Explicitly Parallel Instruction Computing? (EPIC) technology for executing simultaneously up to 6 instructions per CPU cycle. Other advanced chipset capabilities include 64-bit addressability which allows larger heap sizes and number of execution threads, more efficient management of large datasets, and access to massive memory and register stacks.

Intel link: http://www.intel.com/business/bss/products/server/itanium2/bea_jrockit.pdf

It is important to note that all these capabilities are not achievable using non-Java compilers. The latest C, C++ and Delphi compilers all have a common denominator, which is backward compatibility to the x286 chipset and therefore don?t even look at the modern chipset capabilities the application will be running on. Also, C/C++ and Delphi only run on Windows operating system.

In addition, JIT compilers now recognize that different applications may have different requirements and will therefore choose an appropriate garbage collection algorithm and even determine which methods should be optimized for the current executing application.

This makes it possible for compiled Java code to run faster than ?native? code in some instances on advanced processors. However, ?speed? is not the only factor in modern Enterprise-class solutions for ?mission-critical? applications!

This discussion is closed to new replies.