Communication Abstractions for Distributed Business Processes

Aldred, Lachlan; Aalst, Wil M. P. van der; Dumas, Marlon; Hofstede, Arthur H. M. ter

doi:10.1007/978-3-540-72988-4_29

Search citation statements

Order By: Relevance

Paper Sections

Select...

Overview Of Bpel Through the Yawl Prism1

Citation Types

Supporting

Mentioning

Contrasting

Year Published

2009

2010

Publication Types

Select...

Book4

Article1

Other1

Relationship

Self Cite1

Independent5

Authors

Journals

Cited by 7 publications

(1 citation statement)

References 9 publications

(16 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In the example, either a message containing a modified purchase order is received from the OrdersManagement (lines [30][31][32][33][34], or a message containing a confirmed purchase order is received (lines [35][36][37][38][39] or a set deadline expires. The loop is captured through a while activity surrounding the invocations of the Approve PO and Modify PO operations (lines .…”

Section: Overview Of Bpel Through the Yawl Prismmentioning

confidence: 99%

Modern Business Process Automation

Hofstede¹,

Aalst²,

Adams³

et al. 2010

153

View full text Add to dashboard Cite

Section: Overview Of Bpel Through the Yawl Prismmentioning

confidence: 99%

Modern Business Process Automation

Hofstede¹,

Aalst²,

Adams³

et al. 2010

153

View full text Add to dashboard Cite

Dimensions of coupling in middleware

Aldred

Aalst

Dumas

et al. 2009

Concurrency and Computation

Self Cite

View full text Add to dashboard Cite

Abstract. It is well accepted that different types of distributed architectures require different degrees of coupling. For example, in client-server and three-tier architectures, application components are generally tightly coupled, both with one-another and with the underlying middleware. Meanwhile, in off-line transaction processing, grid computing and mobile applications, the degree of coupling between application components and with the underlying middleware needs to be minimised. Terms such as "synchronous", "asynchronous", "blocking", "non-blocking", "directed", and "non-directed" are often used to refer to the degree of coupling required by an architecture or provided by a middleware. However, these terms are used with various connotations. And while various informal definitions have been provided, there is a lack of an overarching formal framework to unambiguously communicate architectural requirements with respect to (de-)coupling. This article addresses this gap by: (i) formally defining three dimensions of (de-)coupling; (ii) relating these dimensions to existing middleware; and (iii) proposing notational elements to represent various coupling integration patterns. This article also discusses a prototype that demonstrates the feasibility of its implementation.

show abstract