People sometimes use jPOS as a library and do the wiring using Java code, something that Q2 already does in a clean and easy to maintain way. In r2735 we've introduced a couple of changes to Q2 in order to simplify the way you can embed it in your application in order to get the best of both worlds. You basically need to instantiate a Q2 object and call its start() method. That's it. At shutdown time, you call stop() on that instance. There's no reason not to use Q2 now, you just need to:

import org.jpos.q2.Q2;
...
...
  Q2 q2 = new Q2("path/to/your/deploy/directory");
  q2.start();
...
...

At stop time, you simply call:

  q2.stop();

Ditto, jPOS 1.6.4 has been released. Here is the ChangeLog. We are moving development to 1.6.5 now. jPOS-EE modules/jpos/lib has been updated with a pre-compiled version of 1.6.4. Please report problems to jpos-dev mailing list (see Resources).

/by apr/ This has nothing to do with jPOS, but since I don't have a personal blog I thought it would be a good idea to share this funny finding. I think I've "invented" a very easy way to add a some level of security to my regular credit cards, I'm testing it and works great on my MasterCard. It's very simple. I've memorized the CVC on the back of the card and then erased it with my little swiss army knife (you've got one, right? otherwise you wouldn't be reading this blog). This won't protect you against a problem like this but it's good if your card gets robbed or you lost your wallet. The procedure to use the "protected" card is very simple, you need to stay close to the operator and when you see a weird expression in her/his face when [s]he turns around the card to read the CVC, you just say "it's kind of erased, the number is NNN". So far it has worked all the time, I just need to refine the method for restaurants with no wireless POS where my wife bugs me to use an "unprotected" card in order to avoid all the fuzz (she ends up using hers most of the time, which is not bad either)

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.