Friday, April 17, 2009

 

Modeling a Workflow in Software

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

Related Articles

Labels:


Sunday, March 22, 2009

 

Form Maker debut

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.

Labels:


 

Supporting Quality Processes

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.

Labels:


 

Writing programs for the workflow domain

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.

public workflow MyFlow
{

    // 'Start' state

    Start()

    {

        // place code to be executed when the state is entered.

    }

    // constructor

    public MyFlow()

    {

        // put the workflow into the Start state

        enterstate Start()

    }

}

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.

private ArrayList dataList = new ArrayList();

// method 'AddData' has a dynamic access modifier

public void AddData(string data) : states(Start)

{

    this.dataList.Add(data);

}

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.

public void DoSomething() : access("Approver")
{
    ...
}

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

Labels:


Tuesday, March 17, 2009

 

Why a Domain Specific Language is better than a Framework!

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

Labels: ,


Wednesday, November 12, 2008

 

Policy based Management with Jetfire

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.

Labels:


Saturday, July 26, 2008

 

Quiz made easy

I just finished integrating the Jetfire Quiz into the system. The quiz that I wrote using the Jetfire scripting language was quite simple:

  • What is your name? __________
  • Are you over 18? (yes/no)
  • Select an age category: 18 to 25, 26-35, 36 – 45, over 45
  • How often do you go dancing in a year? ___

From a code perspective, the Quiz is a set of Questions and Answers. Answers may be text, numeric, yes/no, a selection from a list, date and time, and duration.

A new Web Control is provided (in the website) to iterate over the list of Questions and Answers, providing the user with the ability to input answers. The quiz can be viewed using this custom control.

The real reason for this blog is to brag about just how simple it is to write your own Quiz. My friend, Mo, wrote a quiz in 30 minutes this morning. Mo owns a Print shop in Ottawa, has a Computer Science degree from over 20 years ago and hasn't programmed in a whole lot of years. Mo is a smart guy, but not a programmer. He needed a little bit of help with syntax, but since he uses Excel extensively, he was a natural to write his first Jetfire workflow.

Since I hit him cold with "you are designing a quiz right now", most of the time was spent formulating the questions and answers about the travel quiz that he wanted to write. His travel quiz includes the following questions:

  • What was your favorite destination? ________
  • Select your Sex: Male, Female
  • Select a destination: North America, Europe
  • Select an age category: Under 18, 18 – 35, 36- 50, over 50
  • How often do you travel in a year? ____

Less than five minutes later, I had the privilege of being the first to fill in his quiz.

Sound like fiction? With Jetfire, you upload the Jetfire code and start using it immediately. This is possible because Jetfire is a scripting language and re-uses the Question and Answer Web Control described above.

Labels:


Thursday, June 12, 2008

 

Hello World with Jetfire

It has become a tradition the first program to introduce a user to a programming language is "Hello World". We thought it would be appropriate to have a "Hello World" program for Jetfire (download site) as well; however we were concerned that it didn't really show how Jetfire is different from everything else. Well that is the point. Jetfire it is not different when it comes to writting code to solve a problem, but it is radically different, in that it is a whole lot simpler, when you try to solve real world problems with Jetfire.

Well what do we mean by a lot simpler. Well lets look at "Hello World".

namespace test
{
workflow HelloWorld
{
DateTime creationTime = DateTime.Now;
public string Hello
{
get{return "This workflow was created at:" + creationTime.ToString();}
}
}
}

On the surface it looks almost like C#. The only significant difference is that 'class' has been replaced by 'workflow'. Other than that it is valid C# code.

So what is the difference? Why bother with Jetfire? Well the big difference is that Jetfire really starts where C# ends. For example, once a Jetfire instance of the HelloWorld object is created it is persistent until it is deleted. That is why there is a time stamp in this example so you could see when each instance was created. Try it for yourself.

In C# to make an object persistent you need to write code to save it to database or a file. Yes, you can serialize the object; however then serialization breaks if you change the code, and so on. With Jetfire there is nothing more to do. The objects and code are persitent. When the code changes a new version is automatically created.

This is part of goal of having the programmer focus on the problem, not the programming infrastructure. Hopefully the "HelloWorld" example gives some introductory insight to the features of Jetfire.

Labels: ,


Wednesday, September 26, 2007

 

Jetfire is born

Blogging has taken a back seat over the past few months while we have been working on Jetfire - a new approach to designing workflows. Well, Jetfire has arrived and blogs should start coming.

Labels:


 

Jetfire debut at Ottawa Demo Camp

Monday, Sep 24, 2007
John and Charlie present Jetfire Workflows to an Ottawa developer audience. (See FAQ at http://Jetfire.ca/pages/JetfireFAQ.aspx for more info.)

The demo showed a DVD Tracking application. DVD's are added to Jetfire and tracked by Home, On Loan, Lost and Dead states. Commands, e.g. Lost, Found, Died) and Properties (On Loan To, Loan Timestamp, Returned Timestamp, and Lost Timestamp) are displayed on a general Web Demo available to ALL Jetfire workflows.

The Jetfire code, written in a C#,Java-like language was developed by John and Charlie at TrackerRealm. The language is workflow specific and makes it quick and easy to write workflows.

Demo key figures include:

Bottom line: Comments like "Is that all the code there is?" tells me that we are on the right track.

Test Drive Jetfire yourself at http://jetfire.ca/Pages/JetfireDownload.aspx

The DVD workflow (100 lines of code) is shown at http://jetfire.ca/Code/Apps/DVDInventory.txt.

Labels:


Friday, March 16, 2007

 

What is Workflow EcoSystem?

Workflows have recently gained a lot attention since Microsoft introduced a workflow engine as part of .Net release 3.0 and have workflows integrated with Office 2007 and SharePoint. Workflows as mechanism to automate applications have been around for while. We have had a Workflow engine for several years.
What is clear is that to use workflows as sucessful automation tool a complete ecosystem is required. Our view is that a complete workflow ecosystem consists of 5 key components.
5 Key Components of a Workflow Ecosystem
  1. Workflow Designer
  2. User Interface
  3. Data Persistence Layer
  4. Data Report Generator
  5. Workflow Engine

A white paper, Attributes of a Complete Workflow Eco-System, has been put together that describes what attributes are required of each of the key components.

Labels: ,


This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]