Login | Register
My pages Projects Community openCollabNet

Project home

2020-03-13: This site is going to be decommissioned and shut down very soon. Please copy and archive any data you wish to keep ASAP

If you were registered and logged in, you could join this project.

Summary Framework for XML-defined workflows and work-routing
Category construction
License Other OSI-certified license
Owner(s) abworx, prydin, thhal
Imhotep - a Frameworx project

Imhotep is a set of fully implemented frameworks for defining and executing a wide range of process-flow patterns, ranging from lightweight in-memory processes to complex and long-running persistent business process-flows.

What is there to know about Imhotep?


What is Imhotep?
Why does Imhotep exist?
What is the history of the Imhotep Project?
What is the scope and ambition of the Imhotep Project?
How does Imhotep relate to the Frameworx Project?

Functionality Scope

What exactly does Imhotep do?
What products or technologies are most comparable to Imhotep?


What functional units does Imhotep comprise?
What are the key technologies on which Imhotep depends?
What external components or systems does Imhotep require?


What are Imhotep's key benefits?

Legal and Stuff

How is Imhotep licensed?
Why is the Project called "Imhotep"?
Contact Project Owner

What is Imhotep?

Imhotep is a declarative process framework useful for construction of "workflow" scenarios ranging from lightweight state-event-response logic (for example, the typical process logic behind a wizard dialog), to long-running persistent and failsafe workflows.

Imhotep supports visual definition of both process and routing of work to be performed by processing agents.

Imhotep comprises process execution, work-router, and persistent timer frameworks, each of which can be used independently for a wide variety of tasks.

Why does Imhotep exist?

"Workflow" is a heavily overloaded term that has been used to describe everthing from back-office document management to rules-based real-time routing. Our experience is that "workflow" is a generic or "horizontal" process pattern(s) useful in a wide range of process scenarios. The goal of the Imhotep Project is to provide a flexible, extensible set of capabilities that software developers, and in particular ISVs, can use to address this "process-flow" pattern-space.

Imhotep implements a separation of architectural concern that is typically missing in workflow packages. Most workflow systems have no separation between the ordering or sequencing of work, and the distribution/routing of work to a work-processing resource (for example, a live person or software process). This lack of separation makes it difficult to reuse process descriptions, as they typically contain organization-specific routing and handling logic.

Imhotep also differs from classic workflow engines in that it consists of regular Java code that can be included in lightweight regular J2SE applications, or used in a transactional J2EE environment. There is no need to talk to a remote server for execution of long-running persistent processes. However, if a separate server is called for, it can be easily composed using the building blocks of Imhotep.

Imhotep comes with ready to use classes for execution of both simple short lived 'in-memory' processes, as well as persistent processes with full transaction handling under J2EE.

Workflow-type process support is useful in a broad range of scenarios, so Imhotep is architected to be highly extensible and flexible. Elements of the provided packaging generally can be easily replaced. For example, it is possible to use a different timer service, process store, process definition loader, process invoker, faulty message handler, asynchronous work handler, etc. Imhotep's routing engine allows you to plug in new schdulers in addition to the already existing round-robin and score based schedulers.

Imhotep is based on a structured state-event-response model, but also adds multi-threading to the state model for easily controlled parallell flows of execution. Imhotep has the notion of "super-states," which allows a structured breakdown of a process in which higher levels can be abstract and lower levels be dynamically linked-in.

What is the history of the Imhotep Project?

Imhotep results from over a decade spent in developing successive generations of application development frameworks, during the course of which we developed a formulation of "workflow" (or "process-flow") that would be reusable and extensible across functional domains, and able to support declarative definition of the dynamic aspects of business logic.

We found that systems developed as off-the shelf products often lacked the ability to be easily extended or customized. The standard solution is to provide settable parameters and properties that are read by hard-coded logic. Applicability of the system often depends on whether a settable parameter exists. A more powerful customization tecnique is to provide APIs where logic can be plugged in, but we found that most systems still have hard-coded processes.

For Imhotep, we wanted declarative process definitions, and we wanted the possibility of structuring them using regular structured and object-oriented programming techniques - for instance, to be able to inherit a process, or to detail an abstract process with concrete behavior.

What is the scope and ambition of the Imhotep Project?

As a standalone project, the mission of the Imhotep Project is to create the most capable package for declarative development of process-flows.

How does Imhotep relate to the Frameworx Project?

Imhotep is a "common facility" available to applications within the six-layer Frameworx model, and may also be used for flow-processes within the Buckminster (build, assemble, deploy) domain. Imhotep is particularly associated with "layer 4" of the six-layer architecture, where it serves as a visual and declarative way to define "use-case control" logic.

On its own Imhotep, provides a declarative approach to developing a wide variety of process-flow solutions. In conjunction with Louis or Mies, Imhotep provides a foundation for developing mission-critical service-oriented applications.

What exactly does Imhotep do?

Key functionality provided by the Imhotep component includes the following:

  • Declarative, visual composition of process-flows and process-router networks.

  • Long-running processes that can be activated at any future point.

  • Transaction-safe consumation and processing of events.

  • Transaction-safe XML message-routing for distribution of "work items".

  • Persistent or 'in-memory' processes.

  • Streamlined deployment using JMX bean properties.

What products or technologies are most comparable to Imhotep?

Imhotep's differentiation is its performance, flexibility and extensibility, which is the intended result of its architecture and scope.

Functionality provided by Imhotep is typically provided by the more advanced workflow engines, but without the separation of concern between data "control flow" and "work routing" implemented by Imhotep. This typically results in loss of reuse, architectural inflexibility and performance limitations.

Parallel functionality is also provided by implementation of the BPEL4WS standard. However, these solutions are typically tied to the use of Web services oriented protocols, and can be overkill in many Java-based applications. (Imhotep does not conflict with BPEL4WS per se, and can actually be used as an execution engine "underneath" the standard.)

A number of other open source initiatives support the notion of workflows or state-event-response. However, these initiatives do not typically address the full problem-domain addressed by Imhotep.

What functional units does Imhotep comprise?

Imhotep comprises a standard J2SE runtime (for in-memory-only execution), or J2EE runtime component (for long running persistent processes), and a visual editor for graphical process and routing definition.

The editors are used to define processes and routing networks as well as the integrated Java logic performing actions, tests for conditional flows, etc.

The runtime is built on JMX technology, and event queues and other lower level services are configured using Java Management Bean properties. The run-time uses metadata created with the visual editor and exposes the corresponding classes through a standard class-loader initialized with a JMX Bean.

What are the key technologies on which Imhotep depends?

  • J2SE (version 1.4 or above)

  • Java Management eXtensions (JMX)

  • Java Transaction API (JTA)

  • XML

What external components or systems does Imhotep require?

Imhotep is designed to run in any J2EE application server environment. However, Imhotep can also run as a standalone component.

What are Imhotep's key benefits?

Flexibility and performance
The architectural separation of concern Imhotep implements within the larger frameworx family of packages offers significantly improved efficiency compared to traditional hand-crafting of process logic.

The ability to create abstract processes makes it possible for a system provider to ship well-defined and tested processes that can easily be customized by a user.

Abstraction and composition
Imhotep's fully declarative process and routing definitions allows the creation of easily modifiable/extensible business logic for the dynamic behavior of the system.

Imhotep's support for process definitions and routing fully integrated in regular Java enables the creation of complex system logic.

Separation of development concerns
Imhotep implements a number of separations of concern in the application development process.

Processes can be created and reused without knowing the runtime technology used for persistence, event delivery, work distribution etc. This makes it possible to focus on the business logic rather than the technical aspects of its implementation. Some processes should perhaps run as fast as possible on a 'Web-tier', while others need transactions and run in a back-end cluster.

Processes can be created in abstract fashion and used with default implementations of what will later be replaced with real-life concrete details.

In large or distributed development organizations, the ability to separate the definition of business use-case's dynamic behavior from its information modeland data views allows teams to focus on specific aspects of system development or those requiring specialized skills, while preserving architectural coherence in the overall effort.

Also, since process flows and routing are defined declaratively using graphical tools, most actual coding is eliminated and definitions can be easily understood by non-developers.

How is Imhotep licensed?

Imhotep, like other software initiated within The Frameworx Project, is available under "Apache-style" (BSD-based) licensing.

Why is the Project called "Imhotep"?

Like other projects originated by the Frameworx Project, Imhotep is named after a "famous dead architect". In Imhotep's case, this is the ancient Egyptian Imhotep (2635-2595 B.C.), who is considered the earliest known architect and is credited with a large number of ancient sites. Imhotep was believed to be a mythological figure until the late 19th century.


Go Here!


Status & Roadmap


Design Overview

Developer Guide

Developer FAQ

Use Cases

White Papers


Try it!

Founding Team

Pontus Rydin
Founding Architect & Developer

Henrik Lindberg
Architect & Developer

Peter Back
Architect & Developer

Related Topics

Coming soon