ISO-8583 made easy Implementing a jPOS based application usually requires some major development effort. If Java is your platform of choice and you already have a knowledgeable ISO-8583-savvy Java development team then jPOS, or better yet, jPOS-EE is certainly the way to go. But if you are not a Java shop, or even if you are, but you just want to focus on your business logic without having to deal with low level ISO-8583 communications details, then ISO/Bridge is probably an alternative you ought to evaluate. Read the rest here.

jPOS Training / Montevideo

For sometime we have been conducting ad-hoc training sessions to jPOS developers from several financial institutions in our region. We are now getting ready to host developers from locations far away from here, so we’ve structured 3 intense sessions that cover jPOS, Q2 and jPOS-EE in great detail. This is a nice oportunity to get up to speed with jPOS development, meet other jPOS developers and get to know what are they using jPOS for. Read the training schedule here.

jPOS Performance

/by apr/ I recently came across a java based commercial ISO-8583 encoder/decoder kind of application that claimed to perform as much as 2000 encode/decode operations per second on an average machine. Wow! that’s fast! They even described their benchmark, they were talking about average messages with a 16 field set and a secondary bitmap present. It was not clear to me if they were doing both operations (encode/decode) in each cycle, or just one. I decided to give jPOS a try on an average machine [], I created a message with said number of fields, including a secondary bitmap, and a little loop including a pack and an unpack operation. I was pleased with the result: in excess 20000 pack/unpack operations per second. Then I decided to compare this same test against another commercial product, our own High performance, ISO-8583 C lightweight library. It was fast, but not as fast as I would expect, we get 40000+ pack/unpack operations per second, 2x compared to jPOS, but hey, that’s C, I was expecting a 5x or 10x ratio there… The conclusions are pretty obvious to me… if you are up to, you can make Java perform slow like a turtle, and you can still charge people for it. [] Pentium 4, 1.6 Ghz, aprox 3k bogomips

New jPOS project - miniGL

Many jPOS based applications have to deal with accounts and have to accurately and efficiently keep track of its transactions and balances.

I found myself writing ad-hoc transaction logging software using custom database schemas and balance calculation strategies over and over, and I think this may have happened to many of you as well.

While writting custom logic is certainly a feasible option and may seem like the simplest approach, code that looks okay in a test environment may degrade once you load it with hundreds of millions of transactions.

Code that passes all tests in a development environment may encounter nasty problems under heavy load, caused by race conditions, poor performance, etc. And then you need a myriad of supporting applications for extracts, analysis, reporting, data-entry, UI, etc. that have to be customized to your unique data model.

miniGL attempts to address this problem by providing a minimalistic solution to the recurring task of safely and efficiently keeping track of accounts.

While doing so, miniGL explores the possibility of leveraging double-entry accounting methods in situations were one would tend to use just single-entry.

Read the rest here.