jPOS.org

/by apr/

jPOS High Availability Service can be used to create a cluster of nodes where one of the nodes is used as a MASTER and the other(s) as SLAVE(S).

A typical setup involves jPOS HA taking responsibility for standing-in with a virtual IP address in the cluster.

In addition to providing peace of mind to your jPOS-EE installation, the HA Service has proven to be extremely useful when rolling out new software versions in a production environment, you roll it on a slave, then just disconnect the master, the slave becomes the new master running the new software. Should something go wrong, you re-connect the old master and disconnect the new one, that’s something you can even do at the RJ45 patchbox level, which may be faster than typing commands under high pressure.

jPOS-EE documentation has been updated and the jPOS-HA module is available for download .

We have to thank Dave for his work in this module and for deploying it in several mission critical systems under his control. Dave is now enjoying a well deserved vacation in Europe, certainly confident that should something goes wrong with a master node, the slave will pick up the load …

he may be also crossing his fingers … just in case …

/by apr/

We’ve made some minor changes to miniGL in order to integrate it as a jPOS-EE module.

GLSession now have a few new constructors that accept a DB object, so we can reuse DB’s Hibernate session.

In addition miniGL’s configuration has been adapted to jPOS-EE-SDK naming convention (see modules/minigl/cfg).

This module depends on the following modules:

• hibernate
• hibernate_xxx
• eecore

/by apr/

We have a couple of new modules in jPOS-EE that integrates Q2 with the excellent Java Service Wrapper.

We provide implementations for Windows as well as Linux.

/by apr/

There’s a new QBean in eecore called org.jpos.ee.status.Monitor. It has an easy to extend interface:

 public interface MonitorTask {
    public String checkService ();
}

that can be used to monitor different kind of services.

We just have a pseudo-Ping implementation so far, but we plan to add monitoring capabilities for other services, both external (http, ftp, smtp, etc.) as well as internals (channels, muxes, servers).

The configuration is very simple too:

<monitor class='org.jpos.ee.status.Monitor' logger='Q2'>
  <monitor id='webserver jPOS.org Web server' delay='15000' period='180000'>
   <class>org.jpos.ee.status.Ping</class>
   <property name='host' value='www.jpos.org' />
   <property name='port' value='80' />
  </monitor>

 <monitor id="secureserver jPOS.org Secure Web server"
   delay='20000' period='180000'>
  <class>org.jpos.ee.status.Ping</class>
  <property name='host' value='www.jpos.org' />
  <property name='port' value='443' />
 </monitor>
 ...
 ...
</monitor>

Here is a live demo (login with user ‘guest’, password ‘guest’).

Several modules have been updated, so you may want to call

  ant update
  ant setup

In addition, the documentation has been updated, you may want to fetch a new copy.

If you find this useful and you plan to use it, please consider contributing some MonitorTask implementations.

/by apr/

There’s a new experimental jPOS-EE module called QCluster that can be used to manage Q2 farms.

Although this is just an alpha version, stuff like this will enable the creation of web based configuration wizards usable by average operators for common tasks such as creating new servers, restarting channels and the like.

There’s a new section in the experimental chapter of jPOS-EE-SDK document.

The module source can be found in the usual place.

/by apr/

The jPOS-EE-SDK reference guide have been updated to document more entities available in the eecore module.

We are currently working in customized versions of the eeweb module with some end-user institutions and VARS and we expect to release a generic community edition asap. Some components of the CE have been installed in the jPOS-EE Demo Site (login with user ‘guest’ and password ‘guest’) and are available for a sneak preview.

If you’re currently working with jPOS and you want to jump the jPOS-EE wagon, do not hesitate to contact the EE team.

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.

We’ve updated our wiki software and migrated all pages from the old one (which will remain available for a while).

If you see something wrong, feel free to edit.

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.

/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