Its been ages since my last entry. I’ve been busy lately starting a new development company, adopting a similar philosophy as Joel Spolsky at Fog Creek Software. I want to incorporate the same focus on design and quality as companies such as Apple has achieved. This means finding smart people with the right attitude and then giving them the respect and space to get things done, collaborating with like-minded companies and individuals to develop a deep understanding of the business domain of our customers and target markets, working with a mature team who understand how to build customer relationships and earn trust, and participating in the development community to stay close to the best thinking on design and practices.

One of the user groups in which I am involved is the local Flex Users Group in Wellington. I was planning to present on reflection, annotations, and the dynamic qualities of AS3. I thought code related to ORM would provide the best example material. As happens, this evolved into a full project, and the first release has been published to RIAForge. I’m interested in any feedback or collaborators to improve the level of testing and features.

Oracle has finally managed to acquire BEA today. This is not surprising given the amount of consolidation that has been happening in the industry. BEA has a very good product set, however the company has had a narrow focus for a company of its size. With the commoditisation of the application server market, BEA would have been looking to the SOA server market for new revenue, which is still young and during a time of cautious spending.

It will be interesting to see how the product sets merge. BEA has had the superior and more popular Java application server. Oracle’s product set has improved with 11G, resulting in an impressive stack for building web-based applications from a rich user interface component set through to a solid EJB3 data persistence implementation with Toplink.

My guess is that the products will standalone for a time (years?) with the real focus on the SOA product set. BEA has the stronger solution with the Aqualogic suite of products. Oracle may lead with Aqualogic in the SOA server market while also focusing on its own Fusion suite of business applications.

So now IBM and Oracle are the two main Java Enterprise rivals that should be evenly matched in capability and market share. Sun sits in third place with a more credible open source strategy.

The other interesting news is that Sun will acquire MySQL AB. MySQL has been one of the most popular open source databases in use. Sun’s open source strategy has made many of its products easily and freely accessible to developers. Organisations are able to buy subscription services to ensure support.

Perhaps Open Source may gain as the market consolidates as a viable alternative that is usually first to innovate. For example, the EJB3 data persistence specification was heavily influenced (pretty well based) on the Hibernate open source project.

It will be interesting to see what this level of consolidation means for Java. Has Java reached a point of maturity where it will tend towards stability with a lessening in the pace of change (which is correlated with innovation)? Or will consolidation of control drive innovation such the development of business applications with workflow and service composition at their core? I am seeing both trends at present. There is plenty of room for Java to evolve, particularly in integrating functions (services) across a business processes, both within and outside the organisation.

There has also been plenty of innovation at the grass roots of building web-based applications outside of Java and .NET, in languages such as Ruby and AS3; creating user interfaces that would be familiar to users of social networking sites and other Web 2.0 applications.

Interesting times.

Java and C# have become the predominant mainstream languages for software development. Both are derived from C and are classified as Object Oriented (OO) languages. OO was meant to help cross the user-technician divide by organising software based on real-world concepts (or objects). However, I think the hardest aspect of learning something new is to let go of what you knew before. For myself, it took some time to not treat an Object Model as simply a Data Model; in part because they looked similar, and because I had found data modelling to be so useful in my work. Therefore many users and analysts have never really transitioned from flowcharts and procedural thinking.

OO still proved useful in development because it facilitated writing less redundant code - organising code as a relational database organises data to avoid repetition.

Now that there is interest in alternative languages such as Ruby and Groovy, and alternative architectural styles such as from SOAP to REST, Server side web applications back to rich user interfaces utilising the client machine, etc. I find myself wondering about what comes after OO?

I believe a new generation of software may have the following characteristics (with the caveat that history tells us we typically underestimate the impact of what is under our noses at the time and our visions of the future are never complete).

Goal driven

The prediction of Agent Oriented systems is not new. These are components that in addition to having behaviour and state also have purpose. Goals are declared, and the component actively reconfigures its relationships and behaviour in an attempt to fulfill its goal in a darwinian manner. The Genetic Algorithm is an example of a present day implementation of code with goal driven behaviour.

Foreign

If we are able to create programs that can act autonomously, we may need to let go of understanding how they arrived at a specific outcome. We might know the mechanism that causes a program to adapt but not the precise sequence of steps that enabled a program to reach an outcome.

We are used to spelling out every specific instruction that tells a program how to move. We have developed layers to enable a higher level instruction to save time, but fundamentally a program is like a train set; we must first lay the tracks before the engine can get anywhere. A program shows no initiative or imagination. Yet we are sometimes left with the impression of a “ghost in the machine” since even though all the tracks have been laid by a human, the tracks can become so interconnected that it is impossible to predict the precise path that a program will take. Hence why a good majority of programming is finding and fixing bugs.

For a new generation of software the tracks may be laid and changed by the program itself. Alan Turing envisioned that a human able to listen in on a conversation between programs would not be able to translate what is said. Computers would become an unknowable mind, visible only by its outputs and actions.

Declarative

If we must let go of understanding the inner workings of a program, programmers must be able to declare what they want instead of specifying in excruciating detail how they would derive an outcome for the machine to emulate.

Jaron Lanier uses the term phenotropic computing to describe a model of software which replaces “protocol adherence” with “pattern recognition” as a way of connecting components of software systems.

A new set of problems

The type of problems handled by a computer are likely to be different. The name “computer” derived from the human computers used to decipher enemy code (enciphered messages) during the second world war. Computers were later applied to the world of business to perform mundane tasks and in particular were applied to problems that required precise answers such as general ledger accounting. It was perceived that the strength of automated computers was in their precision therefore they were set tasks that required precision.

Perhaps the new generation of software wont be realised until the widespread need to pose a new set of problems: pattern recognition, autonomous decision making, virtual environments, etc.

Teaching computers to think appears to be the only long term solution to the mountains of brittle computer code that exists today. Today we struggle with getting companies to communicate electronically over mundane transactions such as purchase orders and authentication requests. How would today’s software technology and methods cope with machines that must act autonomously on other planets with human lives in their care.

Big questions for a new generation of programmers.

Most people in IT are familiar with the “iron triangle” of project management, whereby attempts to fix each dimension of scope, schedule, and cost results in a project that is extremely brittle to change. Since for most projects, change is inevitable, an experienced project manager will proactively manage the variability of one of the dimensions to hold the other dimensions in check. I’ve long held the view that holding schedule fixed and scope as variable provides the best control over projects. Cost follows schedule (as the majority of cost in software development is services).

 Holding schedule constant has a number of benefits:

• The project team is focused on producing the simplest solution that will work opposed to engineering for “just in case” scenarios.
• Project momentum is maintained, which is an important psychological factor in project success.
• Dependencies outside the immediate project team are not impacted, such as business plans, time committed from the business, and external testing.
• The project has more options in response to a change.

It is tempting to delay a project milestone when a choice is unclear or input has not been received from every stakeholder. Even small delays have a significant cost. To put this into perspective, let’s assume a small project of 5 full-time people over 120 days (around 6 months) with a daily per person cost of $800 and these are the only costs that are accounted for. A delay of only 3 weeks represents 12.5% the cost of the project, and if the supplier of the resources is a vendor who expects a 10% profit, then the project has become loss making. The customer may seek a fixed price to mitigate this risk, so the vendor add 20% contingency to the price. This gives the vendor less than 5 weeks of leeway but now there is less incentive for the customer to keep within the deadlines. Change management can protect the vendor but creates overhead costs for both parties.

 The question should be whether the delay in this case is justified based on material impact to more than 10% of the scope of the system, and that the issues cannot be resolved in a subsequent release (a benefit of an iterative release plan).

 My point is not that all delays are avoidable, rather that schedule requires intentional management and successful projects are more likely to have sponsors who manage the schedule ruthlessly. Invariably, the death of a software project is from a thousand cuts, not a decisive blow.

 The reason it is harder to develop simpler software is because it requires management of people not of technology. Other creative industries such as advertising are more likely to see the truth of this - where the value of less is worth more.

This is actually a follow up article to my last post on Methodology. If you have seen my other posts then you will realise that this site is not so much a blog as a holding pen for articles so that a) I can find them again when the same topic comes up, and b) they might be of value to someone else.

I’ve been reading a good book with the title ‘Dreaming in Code’ about the adventures of Mitch Kapor’s (of Lotus 1-2-3 fame) Open Source Applications Foundation (and before you think geek reflect on why it is that if a lawyer reads books related to her profession then it is assumed as professional but reading about IT and exploring new technologies is regarded as geekish). The book digresses into many recurring issues in the IT industry such as software time (the opposite of Internet time), requirements, and whether software development is an art or a science. This ambiguous state may be regarded as a sign of immaturity. Do you think software development is regarded as a profession by other professions? The reasoning follows that if only we knew more, then the art (uncertainty) can be removed leaving measurable and repeatable processes. If engaging a lawyer are your first thoughts about their process or their ability and track record to win a case (an art)?

I think we should accept that software development is both an art and a science as quantum theory forced the scientific community to reconcile themselves with the wave-particle duality of matter, which really grated against the scientific mind. This raises other characteristics that software development shares with quantum theory such as uncertainty.

I thought of all this when thinking about why so many methodologies have not stemmed the rate of software project disappointment. A focus on form and process alone cannot guarantee success. Software management must grapple with the content. I think I mentioned in my last post that software development is the process (or art) of evolving a model of the system from abstract forms to implementation. A useful methodology provides guidance for enacting this transformation.

It is less important to me whether specifications are called Use Cases, User Stories, Features, etc. than that the right information is defined at the right level of granularity. If done right, a Use Case defines a method on a Domain Object. The Domain Model captures both the behaviour (methods) and structure (object relationships) of the system. Domain object methods are aggregated into Service interfaces for use by the presentation layer. The transition from analysis to design can be traced.

 

For example, by asking what goal a user is trying to achieve in using the system, a Use Case can be defined at the right level of granularity (a complete business transaction relevant at a human level) and that focuses on the requirement not the implementation (in case there are simpler and more elegant ways to satisfy the requirement). 

While work breakdown structures and role descriptions are useful (some idea of schedule and cost is better than no idea), guidance about the type of questions to ask is helpful to the hapless soul assigned with completing the task. The precise use of words and grammer is also important to facilitate the correct transmission of meaning. Donald Knuth coined the phrase literate programming in a 1984 paper.

Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.

This topic deserves further follow up for another day.

The topic of Methodology is a recurring topic with current debate focusing on Agile versus traditional approaches. Firstly, what is a methodology?

A definition from Wikipedia is “the analysis of the principles of methods, rules, and postulates employed by a discipline”. What does this mean?

In common use within IT, the concept usually means the set of activities, roles, artefacts, and techniques associated with the Software Development Lifecycle (SDLC). Emphasis is usually placed on the Work Breakdown Structure (WBS) – the set of tasks and assignment of tasks to roles, required to deliver a set of outcomes. The debate on Agile versus traditional approaches often focuses on the degree of formalism of the WBS and controls required to deliver the best outcomes. Agile approaches favour individuals and interactions over process and tools. (See the Agile Manifesto.) Overly prescriptive Work Breakdown Structures in a given project context can add significant time and expense to a project without necessarily helping experienced professionals. As a consequence, some development organisations prefer the use of checklists as an aid to professionals to ensure that tasks and dependencies are not forgotten. A pragmatic approach tailors the level of formalism for a given project context including factors such as contractual requirements, team experience and distribution, project size, etc.

This is all good; however, a dimension of methodology that is often glossed over is the content. Systems development is primarily concerned with progressive refinement of a model. The process starts with a model of the business - strategies, objectives, processes, roles, and requirements, which is refined to a model of the system – use cases, data, objects, workflow, etc. The system model is refined to increasing levels of granularity until code is produced, which is still an abstraction above the machine processing instructions.

The efficiency and effectiveness of the Software Development Lifecycle is driven by how quickly the model can be refined with a minimum amount of activity that is not directly related to model refinement, and while still maintaining a high degree of fidelity with the business environment and its needs. Yet how the model is exactly refined from analysis to design to implementation is a mystery to many developers, let alone project managers. This is where a methodology can play a key role in explaining how the models are refined and the linkages between project artefacts to ensure the right information is being captured and produced at each stage of the lifecycle.

A failing that I see with large methodologies such as the Rational Unified Process (RUP) is that because it attempts to support a wide range of project types, it describes a large set of artefacts, but doesn’t describe well how the artefacts support each other; e.g. how does a set of use cases transition to a set of service interface designs.

A useful methodology which supports both novice and experienced developers alike is one that describe the linkages and transitions between the minimum set of artefacts for a given project type. Novice developers benefit from explanations of how to produce a required artefact instead of a table of contents. Experienced developers benefit from agreeing how they will interface with each other to ensure convergence on a common solution without being told “how to suck eggs.”

In later articles I will describe an approach I use to transition analysis models to design models.

As I was hiking on my recent holiday trying to give my mind a rest, it occurred to me how easy it is to become fixated; trying to improve within a narrow band but lose the plot. I think this happens within the IT industry frequently. For example, Usability becomes fixated on user interfaces (screens). It seems as if most analysts automatically assume to convert paper form shuffling to electronic form shuffling. Isn’t a system more usable if there is less of it to have to use.

Can the forms be removed altogether? Customers enter their details on-line once. Systems are integrated to remove data re-entry. Rules engines are used to process information. Perhaps the system simply notifies someone by email if there is an exception with pre-meditated choices of action. An Information Architect should first attempt to remove all visible traces of the system before starting to design any user interface.

Secondly, the WIMP (Windows, Icons, Mouse, Pull-down menus) style dominates current user interface design. Xerox first developed the familiar user interface adopted first by Macs and then Microsoft with Windows. However, the design was developed with reviewing documents on-line in mind. Xerox wanted a more intuitive user interface for users to reviews documents WYSIWYG (What You See Is What You Get) before printing to paper. However, we already know that use of a mouse and pull-down menus slows down data entry. Perhaps some other user interface using email or SMS is appropriate for action orientated systems. If you can reduce the number of data entry clerks and people behind a desk then systems can be designed that better support people engaged in face to face interaction.

In the words of Antoinè De Saint-Exupéry, “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”

I’ve recently moved the build tool of a large multi-project system from Ant to Maven. I liked the concept of Maven, in particular, the ability to declare dependencies on third-party libraries and load them from a shared repository, the ability to work with a hierarchical project structure, and in general, a tool that makes common build tasks simple.

In the end, I’m not sure if a complex build environment can be neatly abstracted from lower level coding or whether Maven is just poorly implemented in parts.

Firstly, the dependency management feature has introduced as many problems as it has saved. I end up downloading more JAR files than I expected since the third party libraries I use have their dependencies which have their dependencies and so on. Some of the libraries in the public repositories don’t seem to do a good job of keeping dependencies to a minimum required set. In addition, the same library will be downloaded multiple times as each dependent library specifies a difference version. So the reality is a great deal of time is required to specify exclusions and research the dependency trees of various libraries. Therefore, little time is saved compared with manually downloading only the necessary libraries.

Secondly, doing anything out of the ordinary quickly gets difficult and complex. For example, copying an artifact to a non-default location requires adding and configuring a plugin. Many complex tasks must resort to using the Maven Antrun plugin to run ant tasks (which defeats the purpose of moving from ant) or to writing your own plugin.

Thirdly, many of the plugins are poorly documented and implemented. For example, the Maven Archetype plugin used to create a project template uses Velocity to perform variable substitution in template files. However, if you want to use Velocity template files as part of the project template you can’t.

The verdict is I’m sorry I spent a great deal of time moving to Maven. Maven is faster for straightforward projects with a standard compile, test, package and deploy lifecycle. But once you need to automate other tasks, such as generating Hibernate mapping files, or manage a large number of dependencies, Maven quickly starts to become an obstacle rather than an enabler.

Development of the Bootstrap Framework started in December 2003 while I had a long wait at an airport. It was born out of frustration that getting applications started took too long and distracted from concentrating on the core business functionality. It also became a personal tool to integrate new technologies, such as Hibernate, to quickly create working applications to better understand how to use the new technologies. The core domain model of an application remains fairly consistent while infrastructure technologies - to persist state to a database, create the user interface, etc, change frequently.

While earlier versions of the framework generated applications using Struts and EJB2, its has evolved to integrate technologies such as the Spring Framework and Hibernate. This first published release uses Spring, Hibernate, and Flex as the front-end in response to a recent presentation I gave at a Flex Users Group and my recent learning to better understand Flex 2 and its integration with Java.

Publishing this first release was also dependent on migrating from Ant to Maven to improve the build of generated applications and management of third-party library dependencies. This was a much bigger task than I had expected.

I am releasing the code under the LGPL license. The intent is to ensure that any improvements to the generator and templates is made available back to the community, while generated applications may be used for commercial applications.

I welcome feedback.

Introduction

Business Process Management (BPM) is topical but can be a confusing subject since it covers a broad context.

The purpose of this paper is to discuss some of the Use Cases to which BPM is applied, the applicable standards, various architectures, and candidate technologies, to help with a deeper understanding of the subject.

Benefits of BPM

This paper does not focus on the benefits of BPM. At a high level though, a key benefit of BPM is as a tool to help build more adaptable applications that can evolve as business demands change, and to be able to monitor the performance of business processes in real time.

Use Cases

Business Process Management (BPM) appears to be applied to two primary use cases:

• Enterprise Application Integration (EAI)
• Workflow

Workflow, in turn, is often applied at two levels:

• Long running business transaction, often involving more than one system/service;
• Page flow within an application.

EAI is about orchestrating two or more systems/services into a broader process context. (Processes may encompass human input or review, which gets into workflow territory.)

Workflow is about externalising the business processing rules within an application into (typically) a generic state machine representation, so that the rules can be reconfigured over time with minimal disruption to the application. (Workflows may encompass more than one existing application, which gets into EAI territory, or be embedded within an application. The application may be a node in a process orchestration.)

The responsibility for managing workflow typically resides in the Services Tier since this is where transactions are usually managed, interacting with one or more resources including a database.

Page flow is concerned with the logic flow from one screen to the next; as classic example being an on-line purchase “wizard”: review shopping basket, checkout, enter billing details, enter shipping details, enter credit card details, and finally confirm order before processing. The responsibility for managing page flow typically resides in the Presentation Tier.

In each use case, however, there if a ‘flowchart-like’ sequence of activities with if-then-else branches, loops, and exceptions. BPM is in essence defining and managing this flow in such as way that it is not deeply embedded in code and cannot be easily changed. BPM and a Rules Engine often go hand-in-hand since rules govern routing decision within the process flow. (A Rules Engine can also manage other types of business rules and therefore is useful apart from BPM.)

The choice of appropriate standard and tools depend on which use case is primary.

The confusion arises from the fact that the use cases, and associated standards such as BPEL and XPDL, are complementary, and partially overlapping. For a given situation, one or other standard and associated tools may be more appropriate, or both may coexist within an implementation.

Architectural Models

Modern applications have a generic conceptual structure, divided into tiers.

A “workflow” tool can be useful within the following contexts: The protocols used to invoke process components vary depending on context.Web Services has become a de facto standard for invoking services in an enterprise process context due to their interoperability and tool support. Web Services encompass standards for message exchange (SOAP), contract (WSDL), and binding (HTTP/S).

The temptation is to use Web Services for all service invocations, even within an application workflow context. Web Services are remote calls in nature, and involve marshalling data into XML; both of which add performance overhead.

Indeed, even within an enterprise process context, within an homogenous network environment, the benefits of using Web Services: standards based, common infrastructure; must be weighed against simplicity, performance, and guaranteed delivery of alternative messaging mechanisms, which are proprietary in nature.

For business-to-business (B2B) integration, Web Services usually makes perfect sense since an organisation usually has little control over the IT environment of a customer/partner organisation.

Page flows operate at the Application Programming Interface (API) level and are specific to the presentation technology and framework used, such as Java Server Faces vs. Struts.

The standardisation efforts have been focused on the enterprise process and application workflow contexts. It is within these two contexts that context boundaries can become confused: a primary application invoking external application services as part of its workflow, versus an enterprise hub which controls the process.

An architectural model sometimes raised in the context of BPM is where the “workflow is the application.”

Web Forms submit an XML message directly to the process engine to be processed. (The form controller code may be within the form as in AJAX (Asynchronous Javascript And XML) or handled by a Forms Presentation Server.)

This architectural model may work for simple human inputs. Larger applications have more complex screen navigation (page flow) and transaction management requirements that are best handled within the more typical application structures on the previous page.

Not every application problem is addressed by a workflow solution. However, workflow solutions, pragmatically applied, can create more adaptable applications.

Standards

The two main standards discussed below are BPEL and XPDL. The two standards are not necessarily competing but apply to different contexts.

BPEL

Business Process Execution Language (or BPEL, pronounced ‘bipple’, or ‘bee-pell’), is a business process modelling language that is executable. It is serialized in XML as an orchestration language over a component set of web services.

BPEL provides a standard for orchestrating nodes in an EAI scenario, assuming that every node has a Web Service interface. Traditional EAI products made no such assumption and provided various adaptors for messaging, database, and packaged nodes. The downside was that the process language was tool-specific.

The problem with BPEL 1.1 within the BPM environment is that, as a standard, it was written with the orchestration of web services in mind. This means that there are some major limitations in the specification when it comes to handling human intensive interactions with the process (workflow tasks and sub-processes to name two). What this means is that the vendors who are relying only upon BPEL as a standard for their BPM tools are coding extensive (and proprietary) modifications to the standard to simply make their processes work. If those extensions are going to be supported in the future (and their potential impact upon interoperability and reusability) should be questions for all companies looking to go down that path. Their extensions certainly mean that you lock yourself in with them as a vendor.

As a language for Service Orchestration BPEL is good and thus is well suited for use within an Enterprise Service Bus (enterprise process context).

XPDL

XPDL is another standard developed by the Workflow Management Coalition (WfMC), which has been designed to support human intensive interactions, sub-processes, task management and all of the other things that the BPEL only vendors have to write extensions for. It was specifically designed to interchange Business Process definitions between different workflow products like modelling tools and workflow engines.

XPDL defines a XML schema for specifying the declarative part of workflow.

XPDL is designed to exchange the process design, both the graphics and the semantics of a workflow business process.

BPEL vs. XPDL (Executional processes versus a Workflow Management System (WFMS))

* taken from Tom Baeyens

A recent trend in the BPM community is the convergence of specifications about executional business processes. The approach promoted by XLANG, WSFL and BPML converged into BPEL. BPEL is based on interactions (message exchanges). BPEL is defined in the context of a service-oriented architecture. One of the prerequisites is that the services to be addressed are described in a WSDL declaration. BPEL then specifies an XML grammar that can be seen as a programming language to combine control flow with calls to the services defined in WSDL.

I see three main differences between the approach taken in executional business processes and state based workflow management systems:

• State based versus message oriented: state based WFMSs are centred on the notion of state (or activity). The workflow engine maintains the state and calculates the transitions from one state to the next. On the other hand, executional business processes as BPEL are centred on the definition of reactions upon incoming message. A set of those reactions, along with some other bells and whistles, can be seen as a business process. That explains why BPEL is somewhat complementary to state based WFMSs. A BPEL onMessage event handler, which is a reaction upon an incoming message, could be executed e.g. on transitions between states.
• Process instance id versus message correlation: One of the complexities that are introduced with executional business processes is message correlation. Part of the process description must specify how the BPEL engine can detect the process instance identification from the incoming message. It has to be based on a data item in the message. On the other hand, state based WFMSs generate ids for each process instance that is created. The client can use this id in subsequent calls to the engine API.
• Central workflow engine API versus an abstract service endpoint: state based WFMSs have a central API, meaning that the client talks to one central API to manage executions of all process instances. In executional business processes, each process is exposed as a service. This means a different access point for every process definition.

Workflow is a subject from which you get easily distracted. The distraction occurs when workflow related concepts get mixed up with complementary technologies or concepts. To give a very concrete example: workflow is completely complementary to web-services. You could expose the interface to access a WFMS as a web-service, but it’s definitely a bad idea to presume that a WFMS *always* has to be accessed through a web-service interface. Some specifications make this presumption. Apart from web-services, other often occurring distractions include email, inter-business communication, web-applications & organisational structure.

The first standardisation effort in workflow was the Workflow Management Coalition (WfMC). The WfMC started in 1993. A very interesting publication of the WfMC is the reference model. It defines the interfaces between a workflow management system and other actors. Another piece of work is the XPDL specification. XPDL defines an XML schema for specifying the declarative part of a workflow. In my opinion, the reference model and XPDL are the best specifications.

BPEL is orientated around service orchestration, and expects every service to be exposed as a Web Service. Forms are supported; basically as XML inputs to a Web Service. These are more easily supported as trigger points to a process, but since there is no overarching state machine, defining conditional input, timed events, task allocation, etc. is not possible or must be embedded within a service (which begs the question of how to define these embedded interactions in a reconfigurable way).

XPDL is orientated around human workflow and includes features such as role-based task assignments, which BPEL 1.1 does not support. Service end points do not need to be a Web Service. XPDL or similar WFMS specification has a convenient mechanism for creating forms for tasks.

Process Context	Primary Standard
Enterprise Process (Enterprise Service Bus)	BPEL
Workflow	XPDL or similar WFMS language
Page flow	Currently proprietary format

Target Use Case	Primary Standard
Enterprise Application Integration (EAI)	BPEL
B2B Process Integration	BPEL
Service Orchestration	BPEL
Management of people-related tasks	XPDL or similar WFMS language

The standards are seen as complementary:

• XPDL as a standard used to represent the process within a visual design tool – a design-time language;
• BPEL as an output of the design tool – a run-time execution language.

Since there is no notation in BPEL to describe timers, roles, etc.

This view is consistent with the following explanation.

BPEL and XPDL are entirely different yet complimentary standards. BPEL is an “execution language” designed to provide a definition of web services orchestration, specifically the underlying sequence of interactions, the flow of data from point-to-point. For this reason, it is best suited for straight-through processing or data-flows vis-à-vis application integration.

The goal of XPDL is to store and exchange the process diagram, to allow one tool to model a process diagram, and another to read the diagram and edit, another to “run” the process model on an XPDL-compliant BPM engine, and so on. For this reason, XPDL is described not an executable programming language like BPEL, but specifically a process design format that literally represents the “drawing” of the process definition. To wit, it has ‘XY’ or vector coordinates, including lines and points that define process flows. This allows an XPDL to store a one-to-one representation of a BPM process diagram. For this reason, XPDL is effectively the file format or “serialization” of BPM, as well as any non-BPM design method or process model which use in their underlying definition the XPDL meta-model (there are presently about 50 tools which use XPDL for storing process models.)

Business Process Modelling Language (BPML)

BPML is the workflow modelling language adopted by Microsoft, and .NET based products such as K2. It is superseded XLANG – an earlier workflow modelling language pioneered by Microsoft. It is from another standards body – “Business Process Management Initiative”, which is part of the Object Management Group (OMG).

BPML is a superset of BPEL; adding syntax for the workflow context.

BPML vs. XPDL

BPML focuses on issues important in defining web services. This is reflected in several ways:

• Activity types specifically for message interchange, event handling, compensation (in case of failure), and delay.
• Attributes to support instance correlation, extraction of parts of messages, locating service instances.
• Support for transactions, utilizing the block structure context, exception handling and compensation.

XPDL focuses on issues relevant to the distribution of work.

• Activity attribute specifies the resource(s) required to perform an activity. This is an expression, evaluated at execution time, which determines the resource required.
• Activity attribute specifies the application(s) required to implement an activity.
• These concepts together support the notion of a resource (e.g. participant), in conjunction with an application, performing the activity. The implementation of work list handlers to achieve this lies outside the domain of the process definitions.

Other Process Languages

Workflow specifications have been in a state of development. Some tools have implemented their own language in order to provide a pragmatic feature set. For example, JBoss BPM uses jPDL. jPDL is a process language with a clean interface to Java and very sophisticated task management capabilities. JBoss apparently has plans to support XPDL.

Approach

Regardless of the specific standard or implementation deemed appropriate, process definition starts with a description of the business process. An Activity Diagram, perhaps supplemented with a State Diagram, is a useful means of expressing the business process.

It is useful to have a conceptual understanding of the process before layering on the existing systems that participate in the physical view of that process.

The nature of the key business processes in terms of human involvement, existing systems, and events will provide input to tool selection. Other IT input then includes features, support, vendor “lock in”, price, etc.

Technologies

* These are my high-level observations; not a detailed assessment.

All major vendors now have (mostly through acquisition) a Business Process Management (BPM) Product. BPM is typically at the high-end of their product range. The more progressive vendors are working out how BPM fits into a broader Service Orientated Architecture (SOA) suite. Alas, SOA marketing hype is creating more confusion than clarity.

Technology	Perceived Pros	Perceived Cons
JBoss BPM	Good integration to the presentation layer through JBoss Seam Framework and Java Server Faces (JSF). Good business rules integration. No upfront license costs.	More appropriate to the Workflow Use Case than the EAI Use Case. Uses its own workflow definition language jPDL.
Oracle BPEL	Oracle as the Number 3 Commercial Application Server Vendor, behind IBM WebSphere and BEA WebLogic, has been working hard to add support for the latest standards as a competitive tactic. There is a perception that the Oracle development environment is productive and that Oracle has learned from past mistakes in keeping its latest tools standards compliant.	The ability to build Workflow style applications needs more investigation. Oracle has in the past gone its own way leading to some dead-end technologies. Price.
TIBCO	Acquisition of the Staffware product provides a good Workflow product. BusinessWorks product has BPEL support and targeted more at EAI. Application Server agnostic.	Price.
BEA AquaLogic BPM	Sophisticated Business Modelling Tool (acquired from Feugo) targeted at business analysts and including simulation capabilities. Supports both BPEL (to import) and XPDL (preferred “from scratch” language).	Price.
IBM WebSphere BPM Suite	Comprehensive suite. A similar sophisticated modelling tool as BEA.	IBM can lag in support of the latest standards. A combination of products, which can make installation a pain. Price.
K2.NET	Suitable for Microsoft.NET environment. New version leverages Microsoft Windows Workflow Foundation. Business-friendly visual designer. Good reporting.	Not necessarily a con depending on the customer’s environment, but K2 is necessarily restricted to a Windows Server environment. Less suitable for EAI Use Cases; lacking integration patterns such as ‘Publish-Subscribe’.
Active Endpoints (Active BPEL Open Source Engine)	Open source – low upfront licence costs.
Spring Webflow (A Page Flow technology)	Works with various web application frameworks. Naturally integrated with the rest of the Spring Framework.
JBoss Seam (A Page Flow technology)	Great integration with JSF. Integrates with JBoss BPM and JBoss Rules to enable a consistent technology and representation for both page flow and workflow concerns.	Limited to Java Server Faces (JSF).
Others: Sun, Intalio, etc.