According to Bezivin (ASE'01) ”A model is a simplification of a system built with an intended goal in mind. The model should be able to answer questions in place of the actual system”.

The goal of the ADORE activity metamodel is:

• to provide a way to represent business processes as orchestrations of services,
• and to support designers when they want to enhance their processes.

ADORE allows users to define Processes. We use a graph–based method to describe processes. As a consequence, a named Process is defined as a set of Activity(ies) and a set of Relations between these activities. Processes also define Variables to share data between Activity(ies).

An Activity represents a a step in the business process. It process a set of input variables into a set of output variables. An activity defines a Kind, to specify its behaviour. Available activity kinds are service invocation (Invoke), message reception (Receive), response sending (Reply), activity synchronization (Nop), …

A Variable is defined by a name, and a type. We make the difference between scalar and set variable using a specific isSet boolean attribute. As variable type can be complex structure instead of atomic (string, int, …), we use a VariableAccess mechanism to explore the content of a given complex structure.

Activities are scheduled in a given process according to a partial order. This order is defined by expressing Relation between activities. We have identified 4 types of relations between activities:

• a WaitFor b: the a activity wait for the end of b before starting its own execution.
• a WeakWait b, a WeakWait c : the a activity wait for the end of b OR c before starting its own execution.
• a Guard(var, value) b: this relation allows the representation of conditional execution. The a activity will start if (and only if) the activity b ends its execution by assigning value into var.
• a OnFailure(error) b: this relation allows to catch errors. The a activity will start if b ends its execution in a given error state.

Adore intensively relies on unique identifiers. Each identified concept (i.e., which defines an id attribute) assumes that its identifier is unique over the global system.

To support evolution of processes, Adore let a designer express fragments of processes. The Adore meta-model allows one to define fragments and orchestraion (i.e., process) using the same main concepts: activities, relations and variables.

Designers will use composition mechanism to compose fragment of processes with orchestration of services.

Constraint: A fragment of process is designed to be integrated into an existing process. As a consequence, it defines 3 special activities, referring the existing process:

• Hook: it represents the activities (or set of activities) where the fragment will be integrated in the existing orchestration
• Predecessors: it represents the activities preceding the hook in the existing orchestration.
• Successors: it represents the activities following the 'hook' in the existing orchestration.

• Activity Metamodel:

• Available kind of activities:

• We've defined an associated DSL to allows interaction with the Adore meta-model.
• To make designed process more understandable, we've defined a graphical representation.