We stand as a good testament as to the portability, flexbility and adaptability of jPOS. Our financial switch product is based on the jPOS transaction processing framework and surely one of the great advantages of this choice is the flexibility it gives you in terms of Operating System and database selections. Yes, of course, for those of you steeped in the world of Java, the 'write once, run many' concept and its ramifications are taken for granted. But for those of us who have long tenures in the "legacy" payments systems world, the thought that you can test locally on Linux/MySQL and deploy on Windows/MS SQL Server (just as an example) is a truly amazing and liberating concept. I say this because so many of us have spent so many years tied to 'deeply locked-in' operating platform decisions like Stratus' VOS or Tandem's Guardian. You'd read these articles and there was just an enormous gulf (like the size of the Atlantic Ocean) between the ideals of what Java would do for you vs. the reality of running your Stratus Continuum with its payment systems application that ran squarely and solely on VOS.
So, from that mindset, it's quite a liberating feeling to be jPOS-fueled and offer the flexibility of OS and DB choice to our customers. And that example from above isn't just a 'pie in the sky' thing...it's reality. We have a local development environment where we run an Acquirer-side jPOS implementation on a Gentoo Linux platform and MySQL. Then, we deliver a version to our client's test platform, where they run Windows Advanced Server 2003 and MS SQL Server 2005. [This client has a deep bench of experience in those two arenas, and that's a very important factor in jPOS-based implementations: taking advantage of your client's strengths.]
In order to make the transition, there's a MS SQL-based build of the deliverable that needs to take place so that you can create the appropriate executable for the client's target platform. Most importantly, that build makes use of the jTDS JDBC driver (the latest version of which is compliant with MS SQL Server 2005). Additionally, we use Hibernate to create an MS SQL schema (although I'll advise you here not to accept Hibernate's MS SQL-oriented output verbatim...it seems to leave out some on the non-primary indices). Of course, you'll have tests to run to ensure you're getting the same results on the new target OS/DB set-up. But, again, for those us with histories tied to legacy payment systems applications, this flexbility is a thrilling concept.
HOWEVER, please note that just because you have Java portability doesn't mean you're immune to the impacts of Windows OS-level changes. Applications running inside the JVM 'sandbox' may still be impacted by changes you make at the Windows OS level. So, for example, when Microsoft releases security patches (a.k.a., 'hotfixes'), you simply have to test-drive those first on a development platform before committing to production. Otherwise, you could be in for a nasty production surprise.
For example, recently the SysAdmin at one of our client sites was confronted with the need to implement eight simultaneous hotfixes on Windows. Thankfully, he had the good sense to test drive the process on a development server first. Lo and behold, after he implemented the items, the jPOS application would no longer start! We use Tanuki Software's Java Service Wrapper there to implement our jPOS application as a Windows NT service. We turned on debugging on the wrapper to see what was going on. In the wrapper.conf file, where it says this:
# Java Application...we changed it to say this:
# turn on debugging
# Java Application
As a result, the wrapper.log file gave us some better info about why the service would no longer start:
DEBUG | wrapper | 2006/08/10 13:28:44 | Working directory set to: ../
STATUS | wrapper | 2006/08/10 13:28:44 | --> Wrapper Started as Service
DEBUG | wrapper | 2006/08/10 13:28:44 | Using system timer.
DEBUG | wrapperp | 2006/08/10 13:28:44 | server listening on port 32000.
STATUS | wrapper | 2006/08/10 13:28:45 | Launching a JVM...
DEBUG | wrapper | 2006/08/10 13:28:45 | command: "C:\WINDOWS\system32\java.exe" -Xmx1024m -Djava.library.path="lib;/company/secure" -classpath "jpos-ee.jar;lib/wrapper.jar;lib/JPublish.jar;lib/bsf-2.3.0.jar;lib/bsh-2.0b4.jar;lib/c3p0-0.9.1-pre6.jar;lib/cglib-full-2.0.2.jar;lib/commons-cli-1.0.jar;lib/commons-collections-2.1.1.jar;lib/commons-fileupload-1.0.jar;lib/commons-lang-2.0.jar;lib/commons-logging-1.0.4.jar;lib/commons-vfs-1.0-dev.jar;lib/commons-vfs-providers.jar;lib/crimson-1.1.3.jar;lib/dom4j-1.5.jar;lib/edenlib.jar;lib/ehcache-0.9.jar;lib/hibernate-2.1.8.jar;lib/hibernate-tools.jar;lib/jasper-compiler-4.2.20RC0.jar;lib/jasper-runtime-4.2.20RC0.jar;lib/jdbm-0.20-dev.jar;lib/jdom-1.0.jar;lib/org.mortbay.jetty.jar;lib/jpos-1.5.1.jar;lib/jsp-api-5.0.16.jar;lib/jta.jar;lib/log4j-1.2.8.jar;lib/mx4j-2.0.1.jar;lib/jtds-1.2.jar;lib/odmg-3.0.jar;lib/q2-1.5.1.jar;lib/q2mod_jpos.jar;lib/javax.servlet.jar;lib/velocity-1.4-dev.jar;lib/xercesImpl-2.6.2.jar;lib/xwork-1.0.5.jar;lib/org.mortbay.jmx.jar;lib/ra-crypto.jar" -Dwrapper.key="xxxxxxxxxxxxxxxx" -Dwrapper.port=32000 -Dwrapper.debug="TRUE" -Dwrapper.use_system_time="TRUE" -Dwrapper.version="3.1.2" -Dwrapper.native_library="wrapper" -Dwrapper.service="TRUE" -Dwrapper.cpu.timeout="10" -Dwrapper.jvmid=1 org.tanukisoftware.wrapper.WrapperSimpleApp org.jpos.q2.Q2
DEBUG | wrapper | 2006/08/10 13:28:45 | JVM started (PID=4640)
INFO | jvm 1 | 2006/08/10 13:28:45 | Error occurred during initialization of VM
INFO | jvm 1 | 2006/08/10 13:28:45 | Could not reserve enough space for object heap
DEBUG | wrapper | 2006/08/10 13:28:45 | JVM process exited with a code of 1, setting the wrapper exit code to 1.
ERROR | wrapper | 2006/08/10 13:28:45 | JVM exited while loading the application.
DEBUG | wrapper | 2006/08/10 13:28:45 | JVM was only running for 0 seconds leading to a failed restart count of 1.
You can see that the service failed because we could no longer "reserve enough space for object heap." The wrapper.conf had these lines in them:
# Maximum Java Heap Size (in MB)
What we needed to do from here was:
Experiment (iteratively) with that setting to determine the value that would allow us to start the service (for the records, it was 768 in this instance).
Put the setting back to 1024, back out all the hotfixes, and then re-apply them one by one to determine if one hotfix in particular was the culprit. [In this case, we discovered that is was Hotfix 921883, which is described in Microsoft Security Bulletin MS06-040.]
Contact Microsoft to see if others were experiencing this problem. In this case, the answer was 'yes.' We heard this news: "MS06-040 is an update to netapi32.dll which causes some Java applications to fail to start on Windows 2003 SP1 servers. There is a hotfix to address this issue." As of this writing (to my knowledge), there's a 'hotfix to the hotfix' that is in pending status.