Event-based Distributed Workflow Execution with EVE

Geppert, Andreas; Tombros, Dimitrios

doi:10.1007/978-1-4471-1283-9_26

Cited by 67 publications

(48 citation statements)

References 5 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Furthermore, completely distributed WfMS, like Exotica/FMQM (Alonso, 1995) and INCAs (Barbará, 1996}, use the machines of the actors as WF servers. Finally, there are approaches for distributed WF management, which do not have a special strategy for distributing the activities to the WF servers; e.g., EVE (Geppert, 1998), METUFlow (Dogac, 1997), MOKASSIN (Gronemann, 1999), WASA 2 (Weske, 1998;Weske, 1999), and the Petri-net based approach presented in (Guth, 1998).…”

Section: Discussionmentioning

confidence: 99%

Flexibility for Distributed Workflows

Reichert

Bauer

Dadam

2013

Enterprise Resource Planning

View full text Add to dashboard Cite

This chapter shows how flexibility can be realized for distributed workflows. The capability to dynamically adapt workflow instances during runtime (e.g., to add, delete or move activities) constitutes a fundamental challenge for any workflow management system (WfMS). While there has been significant research on ad-hoc workflow changes and on related correctness issues, there exists only little work on how to provide respective runtime flexibility in an enterprise-wide context as well. Here, scalability at the presence of high loads constitutes an essential requirement, often necessitating distributed (i.e., piecewise) control of a workflow instance by different workflow servers, which should be as independent from each other as possible. This chapter presents advanced concepts and techniques for enabling ad-hoc workflow changes in a distributed WfMS as well. Our focus is on minimizing the communication costs among workflow servers, while ensuring a correct execution behavior as well as correctness of ad-hoc workflow changes at any time.

show abstract

Section: Discussionmentioning

confidence: 99%

Flexibility for Distributed Workflows

Reichert

Bauer

Dadam

2013

Enterprise Resource Planning

View full text Add to dashboard Cite

show abstract

“…We employ an event-based architecture [5] to define data flow process between ShadowComponents. indicates that when an event InputDataReady happens, if the inputProperty of the corresponding ShadowComponent is TRIGGER, the ShadowComponent will first import data, then set status to TRUE.…”

Section: Eca Rulesmentioning

confidence: 99%

An HTML Fragments Based Approach for Portlet Interoperability

Song

Wei

Wan

2007

Distributed Applications and Interoperable Systems

View full text Add to dashboard Cite

Abstract. Presentation level integration now becomes an important and fast growing trend in enterprise computing and portals are the mainstream to realize it. However, there is not yet a definitive mechanism to achieve interoperability between the basic components of a portal i.e. portlets, whereby HTML data flows smoothly from one portlet to a neighboring one. This paper proposes an HTML fragments based approach to achieve portlet interoperability. Fragments are a block of HTML elements, which are generated by portlets and are used to aggregate a portal page. We first construct a presentation component, which is named as ShadowComponent, for each portlet involved in a portlet interoperation using its fragments, then define a data flow process between ShadowComponents using ECA rules, and finally drive such a process by creating events to fulfill data flow between ShadowComponents. As the fragments of a portlet are synchronized with their corresponding Shadow Component, such a process enables the portlet interoperation. Experimental results show that the proposed approach is effective in achieving portlet interoperability in portals.

show abstract

“…The idea of building a distributed workflow enactment system based on event communication and event-condition-action rules has been also proposed in the EVE project [19]. The exchange of event notifications plays an important role in our approach, however, in our experience, ECA rules are only a useful intermediate representation to bridge the gap between graph based models, which can be more readily understood by the user designing the process, and the corresponding executable code.…”

Section: Related Workmentioning

confidence: 99%