Towards Using Reo for Compliance-Aware Business Process Modeling

Service-Oriented Computing – ICSOC 2007

2008

Self Cite

Abstract. The explosive popularity of mashups has given rise to a plethora of web-based tools for rapidly building mashups with minimal programming effort. In turn, this has spurred interest in using these tools to empower end-users to build situational applications for business. Situational applications based on Reo (SABRE) is a service composition platform that addresses service heterogeneity as a first-class concern by adopting a mashup's data-centric approach. Built atop the Reo coordination language, SABRE provides tools to combine, filter and transform web services and data sources like RSS and ATOM feeds. Whereas other mashup platforms intermingle data transformation logic and I/O concerns, we aim to clearly separate them by formalising coordination logic within a mashup. Reo's well-defined compositional semantics opens up the possibility of constructing a mashup's core logic from a library of prebuilt connectors. Input/output in SABRE is handled by service stubs generated by combining a syntactic service specification such as WSDL with a constraint automaton specifying service behaviour. These stubs insulate services from misbehaving clients while protecting clients against services that do not conform to their contracts. We believe these are compelling features as mashups graduate from curiosities on the Web to situational applications for the enterprise.

Section: Discussionmentioning

confidence: 99%

Building Mashups for the Enterprise with SABRE

Maraikar

Lazovik

Service-Oriented Computing – ICSOC 2007

2008

Self Cite

“…Different syntax alternatives for cas may work equally well or yield perhaps even more user-friendly languages. For instance, we know how to translate Uml sequence/activity diagrams and Bpmn to cas [3,7,15]. Algebras of Bliudze and Sifakis [6], originally developed for Bip [5], also have a straightforward interpretation in terms of cas, thereby offering an interesting alternative possible syntax.…”

Section: Compilersmentioning

confidence: 99%

Can High Throughput Atone for High Latency in Compiler-Generated Protocol Code?

Jongmans

Fundamentals of Software Engineering

2015

Self Cite

Abstract. High-level concurrency constructs and abstractions have several well-known software engineering advantages when it comes to programming concurrency protocols among threads in multicore applications. To also explore their complementary performance advantages, in ongoing work, we are developing compilation technology for a high-level coordination language, Reo, based on this language's formal automaton semantics. By now, as shown in our previous work, our tools are capable of generating code that can compete with carefully hand-crafted code, at least for some protocols. An important prerequisite to further advance this promising technology, now, is to gain a better understanding of how the significantly different compilation approaches that we developed so far, which vary in the amount of parallelism in their generated code, compare against each other. For instance, to better and more reliably tune our compilers, we must learn under which circumstances parallel protocol code, with high throughput but also high latency, outperforms sequential protocol code, with low latency but also low throughput.In this paper, we report on an extensive performance comparison between these approaches for a substantial number of protocols, expressed in Reo. Because we have always formulated our compilation technology in terms of a general kind of communicating automaton (i.e., constraint automata), our findings apply not only to Reo but, in principle, to any language whose semantics can be defined in terms of such automata.

“…The Green producer code (lines [14][15][16][17][18][19][20][21][22] consists of an infinite loop where in each iteration, it performs some computation and assigns the value it wishes to produce to local variable greenText (lines [14][15], and waits for its turn by attempting to acquire greenSsemaphore (line 17). Next, it waits to gain exclusive access to the shared buffer, and while it has this exclusive access, it assigns greenText into buffer (lines [18][19][20].…”

Section: Fig 1 Alternating Producers and Consumermentioning

confidence: 99%

“…Reo has been used for composition of Web services [16,57,65], modeling and analysis of long-running transactions in service-oriented systems [60], coordination of multi-agent systems [10], performance analysis of coordinated compositions [12,13,17,70,71], modeling of business processes and verification of their compliance [14,59,73], and modeling of coordination in biological systems [31].…”

Section: Overview Of Reomentioning

confidence: 99%

Coordinating Multicore Computing

Lecture Notes in Computer Science

Jongmans

2015

Self Cite

Abstract. Traditional models of concurrency resort to peculiarly indirect means to express interaction and study its properties. Formalisms such as process algebras/calculi, concurrent objects, actors, shared memory, message passing, etc., all are primarily action-based models that provide constructs for the direct specification of things that interact, rather than a direct specification of interaction (protocols). Consequently, interaction in these formalisms becomes a derived or secondary concept whose properties can be studied only indirectly, as the sideeffects of the (intended or coincidental) couplings or clashes of the actions whose compositions comprise a model.Treating interaction as an explicit first-class concept, complete with its own composition operators, allows to specify more complex interaction protocols by combining simpler, and eventually primitive, protocols. Reo [4,7,8,15] serves as a premier example of such an interaction-based model of concurrency. In this paper, we describe Reo and its compiler. We show how exogenous coordination in Reo reflects an interaction-centric model of concurrency where an interaction (protocol) consists of nothing but a relational constraint on communication actions. In this setting, interaction protocols become explicit, concrete, tangible (software) constructs that can be specified, verified, composed, and reused, independently of the actors that they may engage in disparate applications.