Eric's Blog Posts

SOAnother acronym.. Call it what you want, we're just delivering solutions!

SOA (Service Oriented Architecture) is an acronym that has been gaining in popularity over the past few years:

http://www.google.com/trends?q=soa

We're not a company to jump on the acronym bandwagon. One good reason is that there are simply too many acronyms to support, even if you are only playing in the Java playground. That's usually made quite apparent to me in the morning when I visit TheServerSide.com .

Flux has been the backbone of Service Oriented Architectures. It's nothing new. You won't find a slew of marketing acronyms scattered throughout our website though. Why not?

We focus on solutions rather than technology. This is largely driven by the KISS principle. I believe that adopting and supporting every popular Java acronym would make Flux more complex rather than easier to use.

So, how can Flux be the backbone of a Service Oriented Architecture? It's possible with the current Flux release. A lot of the enhancements coming in future releases build on the ability of the Flux engine to be the glue of a Service Oriented Architecture.

Web services can be easily invoked from a Flux flow chart, or job. The “Web Service Action” is there to meet this need. Simply point the Web Service Action to a WSDL, pass data from the flow chart to the web service, obtain the result from the web service, and store the result in the flow chart.

Being able to invoke web services (whether they are internal to your enterprise or hosted by a business partner) is one piece of the SOA puzzle. The piece is to wait for a web service to be invoked and perform a task. This is somewhat trivial. Just create a web service using your web service framework of choice (I prefer JAX-WS and Apache CXF myself) and call Flux APIs from the web service.

What Flux APIs would you likely call with from the web service? There are usually two options that satisfy most requirements. One is to simply call Engine.put() to schedule a Flux job when the web service is invoked. The other option is to publish a message to a Flux flow chart, which will then process the message from the web service.

Here's the meat of the example. Just wrap this in a web service and start designing your SOA flow charts:

    
    // Get a Flux Factory and Engine Helper
  

    

  Factory factory = Factory.makeInstance();

    

  EngineHelper engineHelper = factory.makeEngineHelper();
 

    
    

  
    

  // Connect to an RMI Flux engine
  

    

  Engine engine = factory.lookupRmiEngine(
    "localhost"
  );
 

    
    

  
    

  // Get a messaging helper and create a new MessageDefinition
  

    

  MessagingHelper messagingHelper = engineHelper.makeMessagingHelper();

    

  MessageDefinition messageDefinition = messagingHelper.makeMessageDefinition();
 

    
    

  
    

  // Add some data to the message
  

    

  Map messageProperties = new HashMap();

    

  messageProperties.put(
    "JOB_NAME"
  , 
    "/orderForecast"
  );

    

  messageProperties.put(
    "CLIENT_ID"
  , 
    "112"
  );

    

  messageProperties.put(
    "USER_ID"
  , 
    "9999"
  );

    

  messageDefinition.setMessageProperties(messageProperties);
 

    
    

  
    

  // Publish the message to the Flux engine
  

    

  MessageAdministrator msgAdmin = engine.getMessageAdministrator();

    

  msgAdmin.publish(messageDefinition, 
    "ws_publisher"
  );

This code snippet simply publishes a message to a Flux engine. A flow chart would be designed to begin with a Flux "Message Trigger" and process the incoming message when the web service is invoked. You would likely obtain data from whoever invoked the web service and put that data into the message before publishing it. I've just used static data for illustration purposes.

This ought to be enough ideas to get you started on your own Flux-based SOA solution. I've started on some development work that could make all of this much easier, without requiring any code. If I am successful, then you will be able to satisfy all of your SOA requirements by using simple a drag-n-drop and fill in the boxes interface.

Let me know if you are interested and I can create a working example to illustrate these concepts. It's simple yet very powerful stuff!

Tech Tip: Contextual Job Properties

Flux jobs are executed in a job tree. The job tree is similar to the concept of a file system where jobs (like files) are stored in namespaces (or folders). Each job has a namespace where it executes. All jobs execute underneath the root namespace and can execute in sub-namespaces.

For example, a Flux job that runs a monthly payroll report for a client may execute under the following namespace:

/client1/reports/payroll/monthly/Report1000

With many clients, you could easily have hundreds of reports to process. Using one job template, or flow chart, for all of the monthly payroll reports would be ideal. There will be some issues that we will need to address in the design of the job template to ensure we have a proper design to serve all of the clients.

Each client will have a different server (FTP, SFTP, etc.) where the report files are to be uploaded. We will need to support this somehow. There may be other variables between the monthly payroll reports for each client as well.

Flux has a built-in mechanism that can really assist us in satisfying the requirement of variable data between our jobs. This feature is called the "runtime configuration". You can store any Java object in the runtime configuration. String properties can be loaded from a standard Java properties or any property can be created using the Flux Java API.

Here's an example of a runtime configuration file:

/payrollReportDir=reports/payroll

/username=reports

/client1/reportServer=reports.client1.com

/client2/reportServer=reports.client2.com

/client3/reportServer=reports.client3.com

/client4/reportServer=reports.client4.com

There are five runtime configuration properties defined in this file. There is one defined at the root level and one property defined for each client (client1-4).

We can easily access these properties from our job using the Flux runtime variable substitution mechanism. For example, we can using ${runtime reportServer} as the server name in any File action or trigger. We can also use ${runtime payrollReportDir}. The runtime configuration tree will be searched for a matching property starting in the namespace where the job is executing. All jobs will upload reports to the “reports/payroll” directory as the reports user on the file server and any job running under /client1 will use the reports.client1.com server.

Runtime configuration properties allow you to have properties whose value changes based on where the job is executed. This feature allows you to build dynamic job templates that can simplify your enterprise jobs.

Flux4People: Customized BPM

It's neat to see users push the envelope of our software. Flux evaluators often test performance and scalability of Flux to determine if it will satisfy their needs. We've watched the needs of users evolve and have changed the functionality of Flux to meet their needs.

Flux BPM was introduced in Flux 6.5 to allow people to play a part in business processes that are managed via Flux. This feature met the needs of many users and still does today. We see a lot of potential with this functionality and have made plans to help it grow and be more useful to our customers.

We field a lot of new feature and improvement requests for Flux BPM and cannot possibly allocate resources to implement all of the wonderful requests we get. So, we have decided to rewrite Flux BPM in a more usable way. The new Flux BPM will not be integrated into Flux itself, but rather will be supplied as an example that can be customized to meet your needs.

I've been working on this new BPM example (I'm calling it Flux4People) off and on the past week or so. I've taken this opportunity to illustrate how to write a Flux-based application. This example will act as a blueprint to illustrate to new Flux developers how to integrate Flux into their application. Maven, Hibernate, JPA, JAAS, and JSP are some of the major technologies I'm using. I originally implemented the services as JAX-RS RESTful web services using Jersey ( https://jersey.dev.java.net/ ) but then migrated to a simple JSP solution for performance and simplicity.

The Flux4People example will illustrate how to embed the Web-based Workflow Designer, integrate with Flux security, and how to implement custom triggers. I'm putting the final touches on the implementation before handing the Flux4People example over to the graphics team to beautify. Keep an eye on my blog to be notified when the example is ready.

How will the Flux4People example work? It's quite simple actually and works much like Flux BPM. Basically, I've implemented a custom Flux trigger that adds a task to the database. I've also implemented services to list tasks by owner and to work tasks. These services can be invoked by the web application to display a task dashboard to the user and allow the user to work through tasks.

I'll be posting the full example in the next week or so. Let me know if you have any questions or comments in the meantime!

Show me how. I want to see examples!

We hear you loud and clear and have added a few new examples to illustrate custom actions and how they integrate with the Web-based Designer. The new examples can be found in our Customer Portal at:

http://my.fluxcorp.com/community/documentation/examples

The first example takes you through the steps necessary to embed the Flux Web-based Designer in a Java web application. Here's an example of what the Web-based Designer looks like when embedded in a third-party application:

The second example illustrates how to call a Spring bean from Flux. This example walks you through creating a custom action that can be used to call any Spring bean:

The third example uses the GData Java API from Google to create a custom action that adds an event to a Google Calendar. This example serves two purposes, as we plan to use this custom action internally to update a shared Google Calendar in our employee Time Off Request business process that we run from Flux.

Here is what the Google Calendar Add Event custom action looks like in the Web-based Designer:

Want more examples? Email us at support@fluxcorp.com and let us know what your looking for!

Embeddable real-time monitor, custom actions, and more!

We've been getting a lot of great feature requests from customers ever since we initially announced the Flux Web-based Designer. These requests have driven development and really improved the Web-based Designer. One of the most common requests that we have received is to support embedding the Web-based Designer, which was added in Flux 7.5. We're building on this feature in the upcoming 7.6 release due out 12 November 2007. Flux 7.6 will support monitoring flow charts in the embeddable Web-based Designer. This will allow you to easily support rich workflow operations for your Java web applications. Embedding the real-time monitor will allow your users to easily export, view, monitor, and change running flow charts without leaving the comfort of your web application.

Support for custom actions and triggers in the Web-based Designer is also coming in Flux 7.6. We're enhancing our support for custom actions to support tweaking the display of custom action properties in the Web-based Designer so you can make your custom actions easier to use. Dependencies for custom actions will be moved to the engine side in Flux 7.6, meaning that you only need to install custom actions on the engine instead of the engine and Operations Console.

The following screen shot illustrates the real-time monitor embedded inside of a Java web application:

The flow chart loaded in the screen shot above illustrates a basic time off request business process. Users of previous versions of Flux will quickly notice the major differences. A control bar has been added to the real-time monitor to allow the user to easily control the flow chart while monitoring. Icons are displayed next to active actions to illustrate their execution status. In this screen shot, the business process is waiting for the supervisor to review the employee's time off request. Once approved, an email goes out and then an event is added to a shared Google Calendar.

Layout of actions are persisted to the Flux repository in Flux 7.6 too. This way, when you position your actions in your flow chart and save to and re-open from the repository, your actions will be displayed just where you left them.

If that isn't enough, we've also added support for our built-in file actions and triggers along with supporting runtime data mapping. This will allow you to create a flow chart that transfers files, involves human interaction, and calls out to custom Java code, all within minutes without leaving your web browser.

I hope these new features will be useful inside your application. Post a comment to this blog entry or contact me directly if you have any questions about the new features coming in Flux 7.6, or if you want a pre-release to experiment with.

We're looking for a Web Designer — Got mad design skills?

We have an opening for a Web Designer and are in search of the right person for the job.

This position will require heavy use of user interface design, HTML, CSS, and JavaScript. We will be breaking out components of our web application into embeddable Ajax widgets.

It is fun and challenging to work here at Flux. We’re very customer focused and take pride in delivering a software product that meets client needs and is a pleasure to look at and use. You could play a big part in that mission. Designing a simple, visually appealing, and highly usable user interface is essential to our mission.

See our careers page for more information about the Web Designer position:
http://fluxcorp.com/company/careers/

Do you have experience designing Web 2.0 web sites with HTML, CSS, and JavaScript? You may be a perfect fit for the position! Email or give me a call to talk about it!

Performance testing.. and more performance testing..

I’ve had the pleasure of doing some performance testing against our supported databases lately. It’s really interesting to see concrete performance metrics to compare the impact that the database has on the performance of Flux.

What did we find? Well, we’ve used MySQL internally with Flux and have been very satisfied with the performance. The metrics show why too, MySQL is the fastest database to use with Flux. Of course, HSQLDB ( http://hsqldb.sourceforge.net/ ) is faster, but an in-memory database does not work for all solutions.

A bit of tweaking is required for DB2 and SQL Server 2005 to avoid deadlocks. Flux is a highly concurrent application that executes many transactions simultaneously. You will most likely encounter deadlocks with the default configuration of DB2 or SQL Server 2005 as the default settings of these databases do not work well with highly concurrent applications.

For DB2, setting the DB2_SKIPINSERTED, DB2_SKIPDELETED, and DB2_EVALUNCOMMITTED system registry options in DB2 will help. Also, regularly executing RUNSTATS on all Flux tables will improve performance.

For SQL Server 2005, the new row versioning feature helps out significantly with deadlocks and performance. This feature makes SQL Server 2005 operate much like Oracle, which allows quick SELECT statements and does not block SELECT statements when waiting for uncommitted transactions. Information about enabling row versioning can be found at: http://msdn2.microsoft.com/en-us/library/ms175095.aspx . SQL Server 2000 is not officially supported, but we did run Flux against it and resolved some deadlocks encountered.

We resolved deadlocks with DB2 and SQL Server 2005 as well while gathering performance metrics. All of the deadlock fixes will be in Flux 7.4.2, due out on Tuesday, and also Flux 7.5, which is due mid-September.

We’ll be posting official performance metrics to our website soon. But to give you a general idea, DB2 is the slowest. In comparison to DB2: Oracle is 66% faster, SQL Server 2005 is 70% faster, MySQL is 79% faster, and HSQLDB is 90% faster. These are not final numbers, and not very specific, but they do give a general idea as to what database perform Flux performs best with.