152 posts tagged with "jpos"

Hey, check this out, here is jPOS long time contributor Bharavi!

/by apr/ I though that the 900 TPS jPOS system developed by The Gladiators was a record, but I'm in conversations with a jPOS PEP developer and I was impressed by some of his comments: I got a permission to quote some parts of our chat:

• We made performance tests using jPOS and it scaled very well. We are inserting jPOS in an ATM system for [customer name removed]

• We hope in a few months we gonna have a large number of ATMs using it.

• We made tests and for a complete transaction with data base access, log generation, and state machine control we got 1.050 tps in a central system.

• The goal was to achieve 700 tps with a maximum time of 1,5 seconds. We got 1050 with 0,5 response time for the complete transaction. Including the authorization. We made the tests in three platforms:

  • zOS + Websphere + DB2;
  • Dell x86 + Linux  + JBoss + Postgres;
  • Sparc + Solaris + SjSAS + Oracle;

  The configurations were big, but the best performance we reached in zOs and with Dell+Linux(Debian). Both were very close in the final result.

I'm happily impressed, and you?

/by apr/ If you recall my r1000 post two years ago, it's nice to see that the system has processed over half a billion transactions by this week. It's really nice to see our little jPOS and in particular the transaction manager (which was the key addition to jPOS when we worked on this system) working so well under real world load (around a million transactions a day). Congratulations to the OLS Team!! (make sure you listen to the screencast).

/by apr/ We regularly receive requests from PEP members willing to engage jPOS-savvy consultants. From small consulting gigs to full time on-site and remote positions, there are always great opportunities here and there. You can send your CV to jobs at jPOS dot org (for utmost confidentiality, you can send it to me using PGP).

/by apr on show business/

Andy and Dave from Online Strategies had a great idea, payment systems related podcasts, and here is Episode #1! In this first episode, they describe how they have migrated a big application from a legacy platform to their jPOS based OLS.Switch.

/by apr on this-is-what-I'm-doing-now/

During my long (I wish I could say short) life as a programmer I've been writing the same kind of applications over and over and over.

Every time a given application goes live, I immediately start writing it again under my budget in what I think could be a more efficient, modular and elegant way.

That's how I've written jPOS, previous versions were written in C, then C++, then back in C, then Java.

During the last 10 years or so most of my projects have been mostly either transaction switches or credit/debit/stored-value/gift-card/loyalty system.

We have some pretty impressive production grade systems, from small acquirers and card issuers in small countries to large financial institutions as well as Fortune 500 and Fortune 100 companies processing massive transaction loads.

Almost all the projects enjoy the jPOS-EE modular architecture, but in most situations we end up implementing what the customers have in place in terms of protocols involved.

There are usually inbound protocol specs in place, sometimes outbound specs, customer-specific routing and reporting/extract requirements and business logic, and that's what we have to implement.

In order to reuse code as much as possible, we have the jPOS TransactionManager that is a great general purpose component that fosters the reuse of a lot code (the so called transaction 'participants'), but we still get to implement large chunks of customer-specific code, we still need to read tons of specs. We read specs and we implement those specs, but there's no such a thing as the jPOS specs.

In order to change that and in an attempt to move ourselves to the center of the boxing ring (so to speak), we have now our own specs. And by not reinventing the wheel, our effort has been very small as the new ISO-8583 version 2003 spec is really nice and well thought.

Most things that were previously done using esoteric private fields are now very well specified as part of the standard, so there's not too much to think (no think is good), one just have to follow the experts. But we don't live in a perfect world, so we need to support legacy protocol versions (both inbound and outbound).

Our approach is to use what we call "Stations" that speak the jPOS Transaction Switch (jPTS) internal message format (jPTS IMF) based on ISO-8583 version 2003 and to whatever external protocol is involved.

We currently have five stations types:

• Source Stations (SS) are typically POS/ATM drivers or multi-lane POS servers receiving transactions using ISO-8583 variants or proprietary protocols and converting them to jPTS' Internal Message Format.
• Destination Stations (DS) are used to convert jPTS IMF based transactions into messages suitable for a given destination endpoint. Those can be either a different variant of the ISO-8583 protocol or any other proprietary protocol.
• Monitoring Stations (MS) can be configured to receive copies of messages sent from and to SSs and DSs either as part of the transaction (synchronous mode) or via store and forward (asynchronous mode). MSs can be used to monitor system health, feed in-house reporting/settlement subsystems as well as active and passive fraud prevention subsystems.
• Control Stations (CS) can use jPTS IMF to initiate several system jobs such as setting the current capture date, forcing a cutover, modifying system configuration parameters, reporting a hot card or hot bin range, etc.
• HSM Stations (HSMS) provide an abstraction layer that enables the communication with different hardware-based (and software-based) security modules brands and models.

So we basically have two tightly coupled projects, jPTS (the switch) and jCard (the CMS that implements a native jPTS IMF and can act as a jPTS Destination Station).

Both take advantage of miniGL and we are currently working in the user interface where we have some good news too, we have now the jPOS Presentation Manager (I'll talk about it soon - think dynamic scaffolding to provide CRUDL support for most commonly managed entities).

While we still have a lot of work to do and a lot of features to add before we can release this projects, we believe these applications could be extremely helpful, even as a reference implementation, to teams working on their own jPOS and jPOS-EE projects. In the same way a picture is worth a thousand words, studying a working application (specially a good one) is worth a thousand programmer's guides. We are currently working in a sneak preview program that will allow you to embrace this technology now and use it as part of your projects, either as a reference or as its core engine. Interested parties can register here.

/by apr/ Ditto. See the ChangeLog for details. The new development version is now 1.6.3.

/by apr on kudos/ The jPOS team @ CS has certified the new VISA Business Enhancements April 2008 at one of our jPOS sites today and is working on a second site. This is not a big deal and not worth a blog post, but we got word that this is the second site in Latam to be ready to go. Congratulations!! The CS guys have a solution that works even for non jPOS customers (simple jPOS based bridge between the customer's main system and VISA's VAP to handle the required message format changes). Feel free to contact them if you want further information.

/by apr/ Reading the Payment Systems blog I came accross this other excellent PCI answers blog. After reading Trust but verify your POS system I got to re-read the list of validated payment applications. The PABP requirement #1 clearly says: Do not retain full magnetic stripe, card validation code or value (CAV2, CID, CVC2, CVV2), or PIN block data. I'm working on several jPOS systems that connect to some of the systems listed there and it's nice to see incoming 220s and 420s with lovely data elements 35 and 45 from time to time. Those are SAF-ed messages and I wonder how the hell they manage to not store sensitive data on disk, not even in encrypted form, but they are still able to send it over in store and forward messages that sometimes arrive at our end a couple of days later when our test platform is not active.

I think the PABP list is nice, but it will take a lot of time to get customer sites upgraded to PABP compliant versions of the products mentioned there. The customer have a false sense of security because their provider is listed there, but the version they are running is not that good. Bottom line, Trust but verify your POS system but also verify your acquirer's software version number.

/by apr on recommendations/ My friend and jPOS developer Dave (CISSP, CISA) has a new blog: Payment Systems Blog We are working with him, Andy and the OLS team in some changes to jPOS-EE and their OLS.Switch required for PABP certification (actually they are doing most of the work, which is great, I will just take care of merging the results back to the jPOS-EE codebase). I guess users reading this blog may have tangential interest in it.