148 posts tagged with "jpos"

We've migrated our issue tracking system to YouTrack. I have reviewed old issues and migrated outstanding ones to the new system. The old system will remain online for a while, but will be decommissioned at some point during 2010. Some of the issues there are kind of trivial to fix, I hope some of you --specially new jPOS developers-- could contribute some time to provide patches. Implementing features and bug fixes is the best way to learn jPOS (or any other OpenSource project), so PLEASE HELP!

jPOS 1.6.6 is out, the new development version is 1.6.7. See ChangeLog for details. jPOS-EE has been updated to the latest version.

As of jPOS 1.6.5 r2845, we added a new input-space property to the TransactionManager. With this minor addition, you can easily distribute the load among multiple Q2 instances running in the same or different machines. I'm a true believer in long-lived lightweight Q2 based components. Now thanks to our very simple Space interface and Bela Ban's awesome JGroups that allowed us to implement the ReplicatedSpace, creating this kind of jPOS clustered setup is now feasible.

In addition to the must-have buy-it-now jPOS Programmer's Guide, I've been working in a new document, the jPOS Project Guide. I thought it would be a good idea to share the source code of that document, which uses DITA, so may be we can learn DITA together by editing this document. You can find it in the new 'jpos6/doc' directory (r2834) This is an experiment, the document will be there for a couple of months, if there are no significant contributions from the community, I will remove it and continue working alone which gives me more flexibility. If that happens, the PDF version will continue to be available, though. Patches and additions are welcome!

When we started to log messages using a very simple XML format a long time ago, and then created the XMLPackager to support that message format, we never thought that this was going to be so heavily used, we frequently find ISO-8583 interchanges based on this format, implemented in different languages by different vendors in different countries. I've recently been involved in the deployment of an ISO/Bridge system at a financial institution in one African country connected to another institution at another African country. When I asked for the ISO-8583 specs in order to configure ISO/Bridge, I was surprised to see that the specs where XML based, and basically our spec. I hope we start seeing this with the jPOS CMF soon. The existing format looks like this:

Starting in jPOS 1.6.5 r2817, you can optionally use:

   0800
   000001
   301

Or any combination, i.e:

   301  

This is particularly useful in some implementations that use XML content as part of the ISO-8583 payload, in the past, we had to expand it using XML entities such as < and > that where not nice looking in the logs. With the new addition, we can:

  301
  < ?xml version='1.0' encoding='UTF-8' ?>
     29110001
        I love XML tags  

(you have to add a CDATA block around your inner XML) At response time, we wanted to make it as backward compatible as possible, so we only use this mode if we detect that the field content is XML.

Quick cross-post just to tell that I can assert this is quite true:

"Alejandro has told me the same thing – that when he does projects not related to OLS, he misses our documentation and attention to detail."

Andy's "Master Project Workbook" is a time saver, everything is there. Everything. Original post here.

About a year ago I've blogged about jCard and jPTS (the jPOS-EE based Card Management System / Stored Value Engine and the jPOS Transaction Switch). As part of the project, we defined what we called our IMF (internal message format) based on the ISO-8583 v2003 standard. After several deployments and mapping exercises to different source (SS) and destination stations (DS), we believe that this extra message normalization layer was a good thing to do. We get to see jPOS based systems connected to other jPOS based systems all the time, which is a good thing and makes things easier (when the connecting parties don't see their channel and packager configurations as some kind of secret sauce and get to kindly exchange them), but the packager/channel is just the low level plumbing, a lot of effort has to be done on the higher levels in order to get them to play nicely with each other. Our jCard system already has a quite complete set of self tests that use this format, same goes for jPTS. As part of this message normalization effort we plan to morph our internal tests into a TCK. Andy and Dave from Online Strategies are already using a similar format and are keen to work together into merging the differences. Mark is also #noded for this effort :) We are releasing this work under a Creative Commons Attribution-Share Alike 3.0 License and everybody is welcome to participate. You can get the PDF version here and you are very welcome to actively collaborate with the DocBook version (http://github/ar/jPOS-CMF). This is by no means a perfect spec, there's a lot of work to be done, but instead of reinventing a new spec, or coding to someone else's proprietary spec, we encourage you to take this one as yours. You can even change the cover page (as long as you retain some due credit). Every new project will require some tweaks and addition to the spec and TCK, and we are here to make that happen fast. Feel free to contact us or send us a tweet.

/by apr on why-oh-why/

What's wrong with Payment gateways?

I've seen this problem coming a long time ago; in my country there's a local credit card association called POS2000. After a long long time they've settled on a single ISO-8583 v1987 based protocol that is a mix of several POS and host based protocols where every acquirer managed to bastardize the standard a little bit in order to make the POS implementor's life a little bit worse.

They did a pretty good job (at bastardizing us) and made jPOS quite better (we have now support for esoteric stuff such as the dynamic packagers that change the way we deal with a message for different message types, etc.).

But that's nothing compared to web based payment gateways.

The first craptastic work I've got to see was presented by a local credit card acquirer/issuer.

You know, the regular redirect-to-the-acquirer-site thing with OK and DECLINE URLs which were available in hidden fields, as if a malicious user couldn't read the page source code and hand-craft the OK-url to continue shopping. Come on! More acquirers followed the trend and provided similar pathetic implementations that very few merchants and less users actually use; but things get worst, thanks to the mouse and some visual tools, there's a whole new group of people writing SOAP based services. OMG!!

We are dealing with quite a few now, to support credit card transactions, prepaid top up applications, etc.

Decades of hard work by large financial institutions working on good standards go down the toilet, it's easier to "invent" an API than read an ISO spec and do the right thing. We are working now with a pre-paid phone company and you get to see things like no reversals, and one-second time-window for voids (come on!), and the results code are usually SQL syntax errors displayed to the client.

A similar thing happens with language-specific APIs, vendors think that developers are stupid and not capable enough to deal with a well specified protocol, so they create an API that is usually a bad and closed source implementation of a bad proprietary wire protocol.

Serenity now!

As a follow-up to the previous post about vdmspace, I've implemented a simple SpaceWriter TransactionParticipant that can be used to log all transaction contexts to the highly reliable VoldemortSpace (vdm:space). It can be added to your transaction flow like this:

The code looks like this:

package org.jpos.transaction;

import java.io.Serializable;
import org.jpos.space.Space;
import org.jpos.space.SpaceFactory;
import org.jpos.core.Configurable;
import org.jpos.core.Configuration;
import org.jpos.core.ConfigurationException;

public class SpaceWriter implements AbortParticipant, Configurable {
    Space sp;
    String prefix;
    Configuration cfg;
    public int prepare (long id, Serializable o) {
        return PREPARED | READONLY;
    }
    public int prepareForAbort (long id, Serializable o) { 
        return PREPARED | READONLY;
    }
    public void commit (long id, Serializable o) { 
        outContext (id, (Context) o);
    }
    public void abort  (long id, Serializable o) { 
        outContext (id, (Context) o);
    }
    private void outContext (long id, Context ctx) {
        if (sp == null)
            sp = SpaceFactory.getSpace (cfg.get ("space", null));
        sp.out (prefix + Long.toString (id), ctx);
    }
    public void setConfiguration (Configuration cfg) {
        this.cfg = cfg;
        prefix = cfg.get ("prefix", "");
    }
}

You can add this participant to the very end of your transaction flow. All persistent entries in your Context would get stored.

As a follow-up to the VoldemortSpace post and after one month of development and testing we are not proud (see caveats below) to announce the vdmspace module and its supporting voldemort module. I've added two modules to jposee/opt, 'voldemort' and 'vdmspace' (r153). I splitted them in two different modules because I think there might be situations where accessing a Voldemort store directly could be desirable, without the Space implementation layer. During the last month playing with this exciting technology I faced many problems and tried different implementations. I tried not to use a coordinator, but Voldemort provides no easy locking mechanism in its StoreClient interface other than optimistic locking, making some space operations difficult to implement. So here are the caveats:

• Using the vdmspace for high concurrency input / output (in space terms, in/out) over the same keys will work, but could eventually fail.
• An out with timeout works as expected, but requires an extra write in order to register the entry for later review by the garbage collector.
• You want to make sure that you run just one garbage collector in the cluster (this is a temporary limitation that can be easily solved).

Having said the cons, I believe the vdmspace is good for:

• Storing massive number of transactions, provided each transaction is stored under its own unique key (i.e. could be used to implement a SOR).
• Implementing a second level cache for configuration data that doesn't change too often.

In order to test this, you need to enable opt/commons, opt/voldemort and opt/vdmspace, then you can use simple code like this:

import org.jpos.space.*; Space sp = SpaceFactory.getSpace ("vdm:space"); ... ...

This needs a lot of test, so feedback is Welcome!