david @ flux

R.I.P. flux.Factory

david — Thu, 26 Jun 2008 21:33:36 GMT

Eight years ago, I wrote the first version of Flux's Factory class. It was the starting point for Flux users. Flux users would first make an instance of Flux's Factory class and then use it to create other objects involved in Flux programming.

Yesterday, I deleted the Factory class from the upcoming Flux 8.0 code base.

Back in 2000, using the factory design pattern was the natural choice for Flux. These days, it's become clear that Flux needs to use simple classes instead of the factory design pattern.

It felt good to simplify.

Lightweight or heavyweight job scheduler?

david — Fri, 20 Jun 2008 00:03:08 GMT

On a fairly regular basis, we're asked how Flux is different than one of the large, enterprise-class job schedulers like AutoSys and CONTROL-M. The short answer is: apples and oranges.

Is someone on your team doing Java development?

Answer Yes: an embeddable Java job scheduler is the lightweight solution I would use.

Answer No: a stand-alone job scheduler server like AutoSys, CONTROL-M, etc is the heavyweight solution I would use.

I've written a short technical article that addresses this topic. I hope you find it useful if you're sorting out whether you should use an embeddable, lightweight Java job scheduler like Flux or a stand-alone, heavyweight job scheduler server like CONTROL-M or AutoSys.

What's your opinion? Leave a comment or call me on skype at flux.david

New in-memory database for Flux: H2

david — Thu, 10 Apr 2008 17:03:51 GMT

Flux has used the HSQL in-memory database since Flux's launch in 2000. It's a nice and easy way to get programming with simple Flux examples in literally five minutes after downloading and installing Flux.

However, as I've talked about before, HSQL has its limitations.

The Derby database is now supported by the forthcoming Flux 8.0. It's a simple, embeddable, well supported database (Apache, Sun) that stores jobs and workflows persistently without using an enterprise class database such as Oracle, DB2, or MySQL.

From a Flux perspective, the only problem with Derby is that it doesn't support an in-memory mode, which can make things fast and simple. Fast, because an in-memory database doesn't hit the disk. Simple, because a fresh in-memory database is created each time a Flux engine is created.

Now enter H2. H2 is the popular successor to HSQL. It overcomes the glaring limitations in HSQL, supports an in-memory mode, and is still fast!

Yesterday I integrated H2 into Flux 8.0. It was easy.

I just ran a simple speed test of loading and firing a simple Java Action job. H2 took about 4.5 seconds. Derby took between 6.5 and 7.5 seconds.

All in all, H2 provides (a) simplicity over Derby since a fresh database is created whenever a Flux engine is created and (b) speed over Derby.

Of course, Derby is still very handy since it provides a robust persistence option. Since Derby is supported by both Apache and Sun, I have more confidence in it for data persistence than H2's persistence mode, which Flux won't be using.

H2 is now the default database in Flux 8.0. Derby is available as an option. Both H2 and Derby will ship embedded with Flux 8.0 so you'll never even have to include their jar files on your class path. Just include flux.jar.

HSQL to Derby

david — Thu, 14 Feb 2008 22:50:49 GMT

By default, Flux stores its information in an HSQL in-memory database. Flux is preconfigured with HSQL by default so that people can download Flux and get started with running simple examples within a few minutes. No need to configure your Oracle, DB2, or MySQL instance.

Over the years, a few problems have arisen from this approach:

1) HSQL's database transaction isolation level is READ_UNCOMMITTED (instead of the usual READ_COMMITTED), which places severe limitations on Flux's ability to run multiple jobs and workflows concurrently. In short, when using HSQL as its database, Flux can run at most one job or workflow at a time.

2) Flux requires up to three database connections for its internal use. Due to this requirement, not all of Flux's features are available when using HSQL. For one, Flux messaging doesn't work when using HSQL.

3) It would be useful if HSQL could store its information persistently. It can, actually, but it performs so poorly with sizable databases that Flux explicitly prevents HSQL from running in a persistent mode. For a Flux user to get a persistent database working with Flux, it would be nice if Flux's built-in database supported it. Not everyone wants to go to a full-fledged database such as Oracle, DB2, or MySQL.

Moving from HSQL to Derby would solve these problems.

Derby is well supported, would allow many jobs and workflows to run concurrently from the get-go, and would allow for an option to persistently store Flux data.

The plan for Flux 8.0 is to move from HSQL to Derby. For nearly all those using HSQL with Flux, the transition will be transparent and seamless.

Flux 8.0 development begins imminently. Flux 7.7 is very nearly ready to be released. Flux 8.0 starts afterwards.

I've already coded a proof-of-concept transition from HSQL to Derby in the Flux 7.7 code base. It was straightforward. I ran Derby-based Flux jobs and workflows.

It was cool.

Towards a Flux POJO programming model

david — Fri, 08 Feb 2008 16:49:17 GMT

I want to introduce the idea of programming in Flux using POJOs (plain old Java objects). In a Flux release later this year, you'll be able to instantiate Flux objects as POJOs in addition to the traditional factory approach that Flux has employed since its inception.

The historical perspective is simple. Back in 2000 when Flux 1.0 was released, J2EE was the most important enterprise Java technology, and J2EE architectures used factories extensively. That concept influenced Flux 1.0. For that reason, Flux uses the factory design pattern to instantiate objects.

Today, the POJO programming model is the modern way. After all, it's simpler. It also makes it easier to integrate with other frameworks, most notably Spring, but Spring is certainly not the only framework that Flux could plug into easier if Flux supported a POJO programming model.

So, what will the new Flux APIs look like? Picture lines of code like this:

new FlowChart();
new TimerTrigger();
FlowChart.add(timerTrigger);
new Configuration();
new Engine(configuration);

I'm working on this task now and will report back once something more substantial is in place. Comments? Questions?

Two Java developer jobs @ Flux

david — Mon, 14 Jan 2008 14:31:14 GMT

We're hiring.

Java developers, we have two openings here at Flux. Flux is a very exciting place to work where the fruits of your efforts are used at many, many financial institutions worldwide and have a positive impact on thousands of people. For me, that's truly both inspiring and sobering.

What's special about the Flux working environment?

Besides the truly casual atmosphere, weekly massages, daily ping pong, and shoe-optional dress code (I'm not wearing shoes as I type this), we have all the usual benefits (healthcare savings accounts, 401(k) with company paid matching, paid time off, holidays, dental, vision, etc).

But here is perhaps the most exciting benefit:

All Expense Paid, 7 Day Vacation for Two, Anywhere in the World

On previous trips, Fluxies have visited Ireland, Mexico, Japan, and, of course, the United States. One ambitious Fluxie hit France, Luxembourg, Belgium, The Netherlands, Germany, and the Czech Republic all in a single trip.

To apply, send your info to careers@fluxcorp.com telling us about your Java development skills.

Read more about our Java developer openings on our Careers page.

UPDATE: TheServerSide.com picked up this blog post and wrote an item on the "all-expenses-paid, seven day trip for two to anywhere in the world" benefit at Flux. TheServerSide.com is pretty much the place to go for enterprise Java news and spirited discussions among fellow practitioners in the enterprise Java community.

What benefit or perquisite excites you about your employer?

Resources to help you learn and use Flux better

david — Mon, 07 Jan 2008 19:46:41 GMT

Here at Flux, we have a lot of resources that are new or updated as of late. They could be useful to you or your team to help you flatten your Flux learning curve or to help you use Flux better.

Here are seven helpful resources updated as of late.

New website: We reworked the content on our website and the visual design to provide more information than before. It's organized better. The goal is to help you find what you need to learn Flux and to use Flux better.
Blogs: We blog. We do it to give you insight into what we're thinking and how we're planning to help our customers succeed. There are truly useful things in our blogs.
New customer portal: We updated the Flux Portal to better organize the info that is available. This includes discussion forums with other Flux users. It all helps you learn and use Flux.
New technical specs page: It lists Flux's technical specifications and is updated regularly.
New performance metrics: Flux engine performance data is online. The link to the performance metrics is near the bottom of the technical specs page.
Comparison to Quartz: This comparison document gives a straightforward, unbiased viewpoint of when it's appropriate to use each.
Technical articles: Short, to-the-point knowledge base articles that present solutions to common Flux situations.

How else can we help you? What else would you like to see?

Aesthetics Matter

david — Mon, 05 Nov 2007 18:23:12 GMT

First impressions are important. When a Java developer starts coding to the Flux API, the very design of the API itself is beyond important. It must be well designed, consistent, easy-to-use, highly functional, and aesthetic. Yes, aesthetic. APIs have aesthetics, as any Java developer knows. Some APIs are good, great, or even beautiful. Some are not. We've all used great and not-so-great Java APIs.

Which brings me to the heart of this blog post: graphic designers and graphic artists at Flux.

First impressions are important. Flux's graphical user interfaces must be aesthetic. They must be, first of all, beautiful to look upon, be very easy to use (usable), and highly functional (do what the users need).

We have staff members who have backgrounds in art and graphic design. Their contributions to Flux's web application as well as our website have been indispensable. They are instrumental in not only the beautiful aspect of your Flux experience but the usability and functional aspects as well.

So when you hit our website or use our web app, remember that there are experienced graphic designers and artists behind them. Your productivity is our only goal. If you have critiques, let us know. Be a tough critic. Your criticisms only make us better. Ultimately, your criticisms will only make you more productive with Flux.

Web Embeddable

david — Fri, 05 Oct 2007 15:36:14 GMT

How important is it to insert (that is, embed) enterprise Web applications within enterprise Web applications?

I'm not talking about special-purpose "widgets", like pop-up calendars and what not, which you embed in Web pages. And I'm not talking about enterprise back-end APIs, which have no visual aspect.

I'm talking about embedding a visual enterprise Web application inside a visual enterprise Web application.

For Flux's OEM customers, the answer to the above question is, Very important.

(An OEM is simply a software company that builds and sells their software application with Flux embedded in it.)

Many of our OEM customers are financial software companies selling their software products to their corporate customers. Other times, our OEMs are different kinds of software companies whose target market is financial institutions.

Financial companies want enterprise functionality, such as payments, accounts, and receivables management. As part of that enterprise functionality, our OEMs want to provide Web-based job, workflow, and business process editing and near-real-time monitoring capabilities. Flux 7.5 and the upcoming Flux 7.6 (available 12 Nov 2007) provide those capabilities.

Take the case of our fictitious friend, Gotham Financial.

Gotham Financial wants its enterprise Web application to be "branded" with their "look" -- their colors, their logo, their style. Hence the Gotham Financial style that you see in the image above.

Gotham Financial also wants its software vendor (a Flux OEM) to embed visual job scheduling, workflow, and business process editing and near-real-time monitoring capabilities in its enterprise Web application. Gotham Financial wants to enable its own staff to design workflows customized to their needs.

All of this is a capsule of why Web Embeddable is so important.

Flux Quality Assurance

david — Fri, 05 Oct 2007 15:34:17 GMT

I've blogged before about how I've found it difficult to hire Java quality assurance engineers. Because our Flux and Flux BPM software products are targeted at Java software development teams, we need Java QA engineers to do lots of programming to the Flux APIs in order to properly test them. We can't hire someone with the standard set of IT skills.

With this experience in mind, this is what I've done.

1. I've folded our existing QA team into the development team.

2. The development team will perform all QA work, from unit testing all the way through to integration testing, load testing, system testing, and so forth.

3. Performance benchmarks will be posted online with the Flux and Flux BPM technical specifications as well as in the Flux software manuals. These benchmarks will be updated with each major and minor software release. In conjunction with this
effort, Eric and the development team have been improving Flux's performance significantly in the last two weeks. Eric will blog about what the development team has done.

4. Known bugs are posted online in the Flux bug list and the Flux BPM bug list. As I write this blog entry today, there are 20 bugs on the Flux bug list and one bug on the Flux BPM list.

###

I take our customers' success very, very seriously. Their success is the only reason I have a job today. I like my job; I want to keep it.

I have never intended for our users to be our QA team. We are our own QA team. Logic bugs, performance bugs, and excessive database deadlocks are unacceptable. They lead to bad feelings all around, starting with our customers' own users. And that's very, very bad.

With these changes, we are redoubling our efforts to find and fix all of these bugs, both with the current Flux and Flux BPM releases and all future releases.