As the packing and final testing of jBilling 2 is under way, I thought I would take a few minutes to give you a peek into jBilling 2.

The most important change is where jBilling runs. In the 1.x world you had to use JBoss 3. Most of you know that this is quite an old version of JBoss, while others would rather use other application servers. JBilling 2 runs in any application server: Websphere, Weblogic, jBoss 5 and even those that do not implement the whole Java EE stack: Tomcat or Jetty for example.

The default download will come with Tomcat, but deploying on other application servers will be easy. The application will be bundled as a single war file (which you would be able to download independently too).

For the casual user this makes little difference, but for the enterprise user this is big: there is the need of a consistent platform in the data center, plus scalability and integration issues too.

The API gets a big boost too: more methods and more protocols. There are new methods to ease the retrieval of data, check if a use is subscribed, process an isolated (invoice-less) payment, run a 'mini billing process' for a single user (to force invoice generation for that user) and wide support for prepaid customers and real-time rating.

And then there are the protocols. For SOAP web services we (finally) replace Axis with Apache CXF. Even better, using other SOAP implementations will be a matter of changing configuration files, rather than changing code. Beyond SOAP, there will other interesting options. One of them is Hessian, which in our testing is proving to be even faster than RMI.

How about new features? Yes, we have that too. I think that the most interesting one is the new options for balances: prepaid and credit limit. For prepaid, the customer increases her balance by submitting a payment, and the balance decreases with every purchase (usage). For a customer with a credit limit, every purchase increases the balance which should not exceed the preset credit limit.

There are high-performance API methods that let you validate a purchase before it happens. The typical scenario is prepaid cellphones: every time you make a call the system needs to check if you have enough money in your account. This is not an uncommon case for telecoms, I am very happy that jBilling will be am option for them now.

Another common request that we are able to deliver is paper invoices with a detail record appendix. For telecom invoices, it is common to have a first page 'summary' of the charges, and then several pages with a list of all the calls, and how much each costs. This is something that you could do with jBilling 1.1.4, but not before some heavy tweaking of design files and plug-ins. Now you will have a ready to use example.

There is more, like unlimited depth of customer hierarchies, automatic payment-invoicing linking, etc... I'll comment on those when the release is done.

Cheers,

Emiliano Conde
Lead Developer