We were joking around the other day trying to describe Jetfire when we hit upon DC#, for dynamic C#. Now to be fair C# does have dynamic attributes (especially C# 4.0); however most of C# functionality is determined at compile time. Generally to be considered a dynamic language such as IronRuby, or IronPython, most of a language's functionality should be determined at run time. Dynamic languages do sacrifice some performance for increased application flexibility, although some would argue that in real applications there is no sacrifice in performance.

We say Jetfire, at least in jest, should be called DC# because its syntax comes directly from C# and it is a dynamic language. Jetfire has the following dynamic attributes

• Dynamic typing
  
• Dynamic Access Modifiers
  
• Code can be created and executed 'on the fly'
  

Jetfire Links

• Jetfire Site
  
• Download Jetfire
  
• Jetfire Technical wiki
  

Related Articles

• Modeling a Workflow in Software
  
• Writing Jetfire programs
  
• Why use a Language vs a Framework
  
• Workflow Ecosystem
  
• Displaying Workflows
  

On the surface modeling a workflow in software might seem like a very straight forward task.

After all according to wikipedia "A workflow is a depiction of a sequence of operations…". This sounds like a great match for a computer program modeling the workflow.

You could then use the software workflow to

1. Guide you through the workflow process.
   
2. Perform actions through the software such as send email, operate equipment or perform a computational process such as adjust a photograph.
   
3. Facilitate approvals
   
4. Record activity especially when actions were taken.
   
5. Roll up the results and status in other documents
   

However there are issues (you didn't think it could be quite this simple). All of these issues are resolvable, but add an extra layer complexity to modeling a workflow in software.

1. Workflow programs must be able to operate for days, weeks or even years. The implication is that the workflow program must automatically preserve its status. The status must be automatically restored if the computer is restarted.
   
2. Workflows go through states when the operations occur. Operations, or commands, need to work only in the appropriate state. For example a "Complete" command may only valid once the workflow is 'started'.
   
3. Workflows are performed by more than one person. This means that the workflow must be able to support simultaneous users working on different computers or devices.
   
4. Workflows need to be shared, but also be protected from incorrect usage. For an expense workflow the user may need to be a manager to approve it. The workflow program needs support different roles for different users.
   
5. Not everyone who uses a workflow sees the same data. For example an approver's comments may need to be hidden from the applicant.
   
6. Workflows change over time. For example an 'approval' process may change while there are requests in the system. The workflow software must be able to handle 'grandfathering' the process for requests already in the system or optionally support upgrading them.
   
7. Workflow programs need to be simple to design and build.
   

This is rational behind the dynamic language
Jetfire. Jetfire is domain specific language that handles all these issues with ease. Applications can be built quickly. Application code isn't obscured by reams of infrastructure code. With Jetfire the designer of workflow software can concentrate on the application, not the infrastructure. All this makes the workflow program more reliable and much easier to maintain.

Links

• Jetfire Site
  
• Download Jetfire
  
• Jetfire Technical wiki
  

Related Articles

• Writing Jetfire programs
  
• Why use a Language vs a Framework
  
• Workflow Ecosystem
  
• Displaying Workflows

We have been asked a number of times "where is the Jetfire visual designer"? Our attention was aimed at getting the programmatic model correct. We are now starting to deliver purpose-built visual designers. Why multiple designers?

The objective of Jetfire visual designers is to:

• Provide simple GUI's for building applications
  
• Take the 'programming' out of 'application programming'
  
• Easily deploy applications
  
• Provide a one-step process to writing and deploying applications
  

Figure 1: Form Maker in design mode

Our first release for purpose-built visual designers includes Form Maker. It is a simple first step, but designed to be practical. The key features of Form Maker include:

• Add one or more properties
  
• Reorder properties
  
• Identify the property type (text, date, duration, integer, and more)
  
• Build applications based on previous programs
  
• Form validation
  
• One-click deployment
  

Figure 2: Form Maker in layout mode

Click the 'Show Form Layout' link and Form Maker displays how the Form is displayed to a user.

The differentiator of Form Maker is one-click deployment. The user creates an application and with one click adds the application to the Jetfire ecosystem – ready for use.

Figure 3: Property types

Figure 3 shows the types of properties that can be added to a form in Release 1.

'UnknownType is displayed when reviewing an existing program and the property type is unknown, e.g. an enumeration.

In a previous blog, we stated that the "objective of Jetfire is to simplify the workflow creation/modification process so that Power Users can build workflows and upgrade them".

In the early 90's, I worked for a large corporation that implemented ISO-9001. To be compliant with ISO-9001, each department has to show that they followed their processes. The easiest process to show compliance was the software submission process, because it was tooled. Tracking the paper processes required continuous manual intervention.

Continuous Improvement is the name of the game to improve product quality. Software that naturally reinforces the rules is required to support quality processes. Tooling with the ability to easily upgrade is required. With this back-drop, let's look at Jetfire.

1. New Jetfire workflows are easily added, without upgrading system software.
   
2. Jetfire workflows should easily up-version.
   
3. Light-weight workflow ecosystem
   

Jetfire programs are built on an object oriented ecosystem that executes Jetfire code interpretively. This approach allows Jetfire workflows to be easily uploaded, without the need to upgrade the system software.

To up-version code, version is included in every object in the system. New code creates a new version of a Workflow Class, which are related to previous versions of the named workflow class. New and previous versions of the Workflow Class are accessible with the preferred class to be instantiated being the current version.

Finally, the small size of the Jetfire ecosystem provides a compact environment that is targeted at building applications.

Jetfire is a DSL (domain specific language). So what domain are we talking about?

When we started Jetfire, the goal was to create a language that makes workflows easy to write. I can say without reservation that we have achieved that goal. Let's review the differences between Jetfire and C#.

1. Jetfire is based on C#, so that programmers can easily write it.
   
2. The keyword 'workflow' replaces 'class'. 'workflow' is used to activate first class support for workflow constructs.
   
3. Dynamic Access Modifiers are used to make class members public/private depending on who is using the class.
   

The Jetfire domain specific language incorporates first class support for workflow constructs.    

Let's review some examples of how Jetfire simplifies writing workflows.

Example 1: States – Some workflows are state driven. Jetfire Methods include a new type of method: the state method. 'enterstate' is a keyword used to promote the workflow into the specified state.

Example 2: Dynamic Access Modifier example using states – the AddData method is public when the workflow is in the Start state. Otherwise, the AddData method is private.

Example 3: Dynamic Access Modifier example using access – the DoSomething method is public if the logged in user has the Role 'Approver'. Otherwise, the DoSomething method is private.

These are some powerful examples how a domain specific language can simplify writing workflows.

If you are a programmer you use frameworks. Some frameworks such as a collection framework are almost indistinguishable from the language. I know in my C# code I find almost all my classes contain either 'List' or 'Dictionary'.

Other frameworks such as ADO .net are very large and require quite a bit of time learn. They provide an indispensible service to your application but are very difficult to learn and use. The application code that employs the framework is almost unintelligible. Adding more comments or the more judicious use of variable names seems to have no effect on making the code look better. The problem is that most frameworks need to expose details of internal concepts to application as numerous tunable parameters and properties. This is required since a typical framework has no other mechanism of inferring intent.

The need for the framework to have numerous tunable parameters and properties (lazy loading, concurrency issues, etc) compounds usage problems. This is because in order to be used correctly they need to be understood. Subtle errors in understanding a concept of a framework produces either subtle errors in the application or causes the application not to run a peak performance.

Using a domain specific language addresses a number of these problems.

1. A domain specific language after all is just another language. Most languages can be learned in a few hours to a few days. When we wrote Jetfire we started with C# syntax adding few specific features. A programmer's investment in understanding languages could be reused. The additional features in Jetfire, for example, are consistent with the C# programming paradigm.
   
2. The code in a DSL is designed to be understandable and compact. Unlike working with a framework where hundreds of lines of code are required just to provide initialization, working with a DSL typically requires very little code.
   
3. When you write code in a DSL the language is able to understand the programmer's intent and therefore is able to hide most of the complexity. For example Jetfire understands that variables should be saved to persistent storage. Therefore Jetfire does this automatically without the application programmer writing extra code. Jetfire also knows if a variable is used inside a method that it doesn't need to be saved because that variable is only valid as long the method is executing.
   

Further reading:

Why The Next Five Years Will Be About Languages

We have started an exciting new phase of Jetfire development. Our next release is planned to support both a rules engine and transparent access to .net objects.

Using Jetfire source code a rule will look like the following:

It needs to be mentioned that Jetfire code is not what the rule writer or rule user would see. They would, in all likelihood, see some sort of form based interface. Using Jetfire it extremely easy to write such an interface since it supports programmatically accessing the code for the rule. The Jetfire code is presented here for understandability.

How the rule code operates is that when an event occurs, in the above example when a 'property' is changed in any 'MailStats' object, parameters are generated for the rule. In the example above the 'mailStats' and 'user' parameters are extracted from the event parameters. Think of this as automatic method overloading. These parameters provide a context for the rule and naturally if a parameter was requested that didn't exist in the event object it would cause a coding error.

Any legitimate code is allowed within the 'condition', including calling other rules. Calling methods within a 'condition' is not allowed unless the method is deemed to be 'rule safe'. In other words helper methods are allowed such as converting from a string to integer. This allows the compiler to check the integrity of the rule 'condition' and insure that the 'when' events are sufficient.

Jetfire Policy Based Management Advantages

1. Jetfire rules are easy to code and understand. The built-in integrity features makes the rules very robust.
   
2. The ability to access .net objects means that Jetfire Rules can operate with existing data. That is there is no need to convert data. The data required for a Rule is in a database it can be easily accessed using a .net Framework such as ADO.
   
3. Since Jetfire is interpreted rules can be changed without recompilation or binding.
   
4. Code changes will not impact existing working rules since Jetfire includes automatic code version control.
   
5. Since Jetfire is a highly reflective language it is easy to present the user with friendly forms based rule system.