Fragmento

As described in the related documents, companies increasingly have to pay attention to compliance. Flexibly reacting to requirements coming from laws, regulations, and internal policies become an essential part of business process management. Compliance refers to the measures that need to be taken in order to adhere to these requirements. In order to comply, companies need to perform profound changes in their organizational structure, processes and their supporting infrastructure. At this, process-awareness is a basic prerequisite for ascertaining to operate in a compliant way.

The Fragmento repository focuses on the application of the emerging concept of process fragments in the field of compliance management in process-based applications. We propose to specify compliance controls as reusable process fragments. We understand a process fragment as a connected, possibly incomplete process graph which may also contain additional artifacts like the fragment context. A process fragment is not necessarily directly executable as some parts may be explicitly stated as opaque in order to mark points of variability.

• David Schumm (Main Contributor)
• Tobias Anstett (XMLO Repository)
• Dimitrios Dentsas (Eclipse Integration)
• Michael Hahn (BPEL Designer Integration)
• Mirko Sonntag (BPEL Designer Integration Lead)

A repository for process artifacts needs to account for persistence, storage, retrieval and version management of all artifacts related to a process. We can distinguish different types of artifacts that are related to a process or to a process fragment in a service-oriented environment.

• A process or process fragment model, either in standard BPEL or in an extended or modified version of BPEL
• An according to WSDL document (for specifying the interface)
• A deployment descriptor according to the process or the process fragment
• Additional information for a process modeling tool for instance to store X and Y coordinates of activities
• A view transformation rule for process view transformations
• Annotation documents (e.g., a policy specified in WS-SecurityPolicy)

The repository assigns a unique identifier to each artifact being stored. The use of unique identifiers allows creating arbitrary relations between artifacts. The above-listed types of artifacts are typically serializable to XML, therefore the repository mainly needs to store XML artifacts. Additional metadata, such as a description, keywords, and a name are also applicable to all of the listed types.