Dimensions of coupling in middleware

Abstract

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.

Patterns and tools for business process monitoring customization

“…Generally, communication between the monitoring infrastructure and the client is a distributed systems communication issue and its customization may require the definition of additional dimensions, such as space and time decoupling options [1,17]. However, since those aspects are not monitoring specific, we do not further discuss them here.…”

“…For business process modeling purposes, we use colored Petri nets (CPNs) [1,26]. CPNs have been chosen because they have a graphical representation, they have mature and freely available tool support, e.g., CPN Tools, and they have a precise semantic that can be translated to or directly implemented in other languages, e.g., Event-driven Process Chains [38] or YAWL [42], used by commercial and noncommercial workflow engines.…”

“…2, as this pattern also involves the two interfaces acquireReq and bpeAcquireReq. [1]. < int >/mcTrg.acquireReq → TriAp.acquireReq, ap [2].…”

Patterns to Enable Mass-Customized Business Process Monitoring

“…The option push models cases in which MI pushes monitoring values to MC, whereas pull models cases in which MI sends values of MV only after having received a request from MC. Generally, communication between MI and MC is a distributed systems communication issue and its customization may require the definition of additional dimensions, such as space and time decoupling option [9,10]. However, since those aspects are not monitoring-specific, we do not further discuss them here.…”

“…For business process modeling purposes, we use Colored Petri Nets (CPNs) [10][11]. CPNs have been chosen because they have a graphical representation, they have mature and freely available tool support, e.g.…”