Software Engineering: Service Choreography (Definitions)

"A way of aggregating services to business processes. In contrast to orchestration, choreography does not compose services to a new service that has central control over the whole process. Instead, it defines rules and policies that enable different services to collaborate to form a business process. Each service involved in the process sees and contributes only a part of it." (Nicolai M Josuttis, "SOA in Practice", 2007)

"An a priori global and public model meant to capture all the interactions taking place for a given purpose among a number of participants." (Giorgio Bruno & Marcello La Rosa, "Collaboration Based on Web Services", 2008)

"Choreography is the message exchange behavior that a business exposes in order to participate in a business relationship based on electronic message exchanges." (Christoph Bussler, "Business-to-Business (B2B) Integration", 2009)

"It is a service composition paradigm where no centralized entity is responsible for coordinating the execution of the subordinate services. It is often seen as an abstract service composition since it defines cooperation (e.g., message exchanging) rules but no actual execution flow." (Carlos Kamienski et al, "Managing the Future Internet: Services, Policies and Peers", 2010)

[Web Service Choreography:] "A particular web service composition where several peer web services collaborate in a distributed environment. In a choreography there is not a services acting as a leader and synchronizing the work of the other services, as happen in case of orchestration. This makes choreography more difficult to realize in real settings." (Liliana Ardissono et al, "An Event-Based Middleware for the Management of Choreographed Services", 2012)

"Contract between two or more systems, which establishes how they cooperate to achieve some common goal." (José C Delgado, "Frameworks for Distributed Interoperability", Encyclopedia of Information Science and Technology, 2015)

"Global behavior is called choreography. Choreography is specified using UML activity diagrams. We have used two levels of choreography models: flow-global and flow-localized." (Surya B Kathayat, "Collaboration-Based Model-Driven Approach for Business Service Composition", 2012)

"Define the service collaboration at service-computing level." (Laura C Rodriguez-Martinez et al, "Service-Oriented Computing Applications (SOCA) Development Methodologies: A Review of Agility-Rigor Balance", 2021)

"Defines the requirements and sequences through which multiple Web services interact." (NIST SP 800-95)

Peter Coad - Collected Quotes

"More effective analysis requires the use of problem domain constructs, both for present reuse and for future reuse." (Peter Coad & Edward Yourdon, "Object-Oriented Analysis" 2nd Ed., 1991)

"One of the biggest problems faced by analysts is studying the problem domain and making discoveries about it. [...] OOA is the challenge of understanding the problem domain, and then the system's responsibilities in that light." (Peter Coad & Edward Yourdon, "Object-Oriented Analysis" 2nd Ed., 1991)

"One of the critical success factors for any method and its application is its ability to facilitate communication, avoiding information  overload. So for larger models, the question is how to guide the reader into different parts of the model." (Peter Coad & Edward Yourdon, "Object-Oriented Analysis" 2nd Ed., 1991)

"The transition from analysis to design has been a constant source of frustration. [...] no matter how many cute cartoons are drawn to depict the transition, the radical change in underlying representation causes a major chasm between analysis and design models." (Peter Coad & Edward Yourdon, "Object-Oriented Analysis" 2nd Ed., 1991)

"A pattern is a fully realized form original, or model accepted or proposed for imitation. With patterns, small piecework is standardized into a larger chunk or unit. Patterns become the building blocks for design and construction. Finding and applying patterns indicates progress in a field of human endeavor." (Peter Coad, "Object-oriented patterns", 1992)

"Object-oriented methods tend to focus on the lowest-level building block: the class and its objects." (Peter Coad, "Object-oriented patterns", 1992)

"With each pattern, small piecework is standardized into a larger chunk or unit. Patterns become the building blocks for design and construction. Finding and applying patterns indicates progress in a field of human endeavor." (Peter Coad, "Object-oriented patterns", 1992)

"We think most process initiatives are silly. Well-intentioned managers and teams get so wrapped up in executing processes that they forget that they are being paid for results, not process execution. (Peter Coad et al, "Java Modeling in Color with UML", 1999)

Stephen J Mellor - Collected Quotes

"When partitioning a domain, we divide the information model so that the clusters remain intact. [...] Each section of the information model then becomes a separate subsystem. Note that when the information model is partitioned into subsystems, each object is assigned to exactly one subsystem." (Stephen J Mellor, "Object-Oriented Systems Analysis: Modeling the World In Data", 1988) 

"While a small domain (consisting of fifty or fewer objects) can generally be analyzed as a unit, large domains must be partitioned to make the analysis a manageable task. To make such a partitioning, we take advantage of the fact that objects on an information model tend to fall into clusters: groups of objects that are interconnected with one another by many relationships. By contrast, relatively few relationships connect objects in different clusters." (Stephen J Mellor, "Object-Oriented Systems Analysis: Modeling the World In Data", 1988)

"Executable UML is at the next higher layer of abstraction, abstracting away both specific programming languages and decisions about the organization of the software so that a specification built in Executable UML can be deployed in various software environments without change." (Stephen J Mellor, "Executable UML: A Foundation for Model-Driven Architecture", 2002)

"Executable UML is designed to produce a comprehensive and comprehensible model of a solution without making decisions about the organization of the software implementation. It is a highly abstract thinking tool to aid in the formalization of knowledge, a way of thinking about and describing the concepts that make up an abstract solution to a client problem." (Stephen J Mellor, "Executable UML: A Foundation for Model-Driven Architecture", 2002)

"In the bad old days before MDA, (conceptual) models served only to facilitate communication between customers and developers and act as blueprints for construction. Nowadays, MDA establishes the infrastructure for defining and executing transformations between models of various kinds." (Stephen J Mellor, "Executable UML: A Foundation for Model-Driven Architecture", 2002)

"We build models to increase productivity, under the justified assumption that it's cheaper to manipulate the model than the real thing. Models then enable cheaper exploration and reasoning about some universe of discourse. One important application of models is to understand a real, abstract, or hypothetical problem domain that a computer system will reflect. This is done by abstraction, classification, and generalization of subject-matter entities into an appropriate set of classes and their behavior." (Stephen J Mellor, "Executable UML: A Foundation for Model-Driven Architecture", 2002)

"What's the point of having metamodels, and why should you care? Because models must be stated in a way that yields a common understanding among all involved parties, we need a way to specify exactly what a model means. Metamodels allow you to do just that: They specify the concepts of the language you're using to specify a model." (Stephen J Mellor, "MDA Distilled. Principles of Model-Driven Architecture", 2003)