A Formalization of Social Requirements for Human Interactions with Service Protocols

Collaboration models and tools aim at improving the efficiency and effectiveness of human interactions. Although social relations among collaborators have been identified as having a strong influence on collaboration, they are still insufficiently taken into account in current collaboration models and tools. In this paper, the concept of service protocols is proposed as a model for human interactions supporting social requirements, i.e., sets of constraints on the relations among interacting humans. Service protocols have been proposed as an answer to the need for models for human interactions in which not only the potential sequences of activities are specified-as in process models-but also the constraints on the relations among collaborators. Service protocols are based on two main ideas: first, service protocols are rooted in the service-oriented architecture (SOA): each service protocol contains a service-oriented summary which provides a representation of the activities of an associated process model in SOA terms. Second, a class-based graph-referred to as a service network schema-restricts the set of potential service elements that may participate in the service protocol by defining constraints on nodes and constraints on arcs, i.e., social requirements. Another major contribution to the modelling of human interactions is a unified approach organized around the concept of service, understood in a broad sense with services being not only Web services, but also provided by humans.

💡 Research Summary

The paper addresses a notable gap in current collaboration and business‑process modeling: the insufficient treatment of social relationships among human participants. While Service‑Oriented Architecture (SOA) and Business Process Management (BPM) have successfully abstracted technical services and orchestrated them, they largely ignore the social fabric that governs real‑world human‑to‑human interactions. To fill this void, the authors propose service protocols, a formal model that extends a conventional process model with a set of social requirements—constraints on the relations among interacting actors.

A service protocol consists of two tightly coupled components. First, a service‑oriented summary translates the activities of an underlying process model (e.g., BPMN or BPEL) into SOA‑style service invocations, thereby treating human tasks as services. Second, a service network schema is a class‑based directed graph that restricts which service elements may participate. Nodes represent service classes (e.g., “Bank”, “Architect”, “ConstructionCompany”) and arcs represent relationship classes (e.g., “has‑previous‑loan‑with”, “trusts”, “shares‑supplier”). Both nodes and arcs carry constraints: node constraints describe properties of individual actors (investment count, licensing status, current workload), while arc constraints capture relational properties (past collaboration count, current loan status, common supplier). By formalizing these constraints, the model can express obligations that go beyond traditional role‑based access control.

The authors motivate the need for such a model with a detailed construction‑sector example. A real‑estate developer (DevHouse) must select a bank, an architect, and a site‑preparation company while respecting multiple social criteria: the bank must be one with an existing account, no current loan, and an interest rate ≤ 5.5 %; the architect must have performed at least five past projects for DevHouse but fewer than two ongoing projects; the site‑preparation firms must be known and trusted by the architect and must be able to collaborate efficiently. Traditional BPM would capture the sequence of “negotiate loan → design → clear site”, but would have no means to enforce the above relational constraints. The service protocol, however, can validate a candidate collaboration network against the schema before execution, ensuring compliance with the organization’s social norms and risk policies.

Key contributions and insights include:

1. Multiple Service Consumers – Unlike classic BPEL where a single engine consumes all services, service protocols recognize that several actors may act as consumers simultaneously (e.g., the developer, the architect, and the site‑preparation company). This more accurately reflects real collaborative settings.

2. Actor‑Centric Constraints – The model distinguishes between role‑based permissions and obligations derived from actor attributes (investment history, certifications, physical traits). This enables fine‑grained eligibility checks that are impossible with pure role definitions.

3. Relational Constraints – By modeling arcs with constraints, the approach captures the “social context” of each actor, such as trust, past cooperation, and shared supply chains. This is a novel formalization that bridges process modeling and social‑network analysis.

4. Formal Foundations – The service network schema is grounded in graph theory and class‑based modeling, allowing verification of structural validity, reachability, liveness, and boundedness. Consequently, designers can mathematically prove that a protocol will not deadlock or violate its social requirements.

5. Reusability and Decoupling – A service protocol is reusable across different collaboration groups, analogous to a class in object‑oriented programming. The service‑oriented summary separates the “what” (activity flow) from the “how” (implementation technology), supporting heterogeneous execution environments.

6. Support for Social Aspects – The fourth requirement explicitly stresses that social constraints must be integral to the model, not an afterthought. This addresses ethical and legal concerns (e.g., privacy violations on social platforms) by ensuring that system‑enforced interactions respect societal norms.

The paper also outlines a set of four requirements for any SOA‑based human‑interaction model: reusability, separation of implementation, strong mathematical foundations, and explicit support for social aspects. Service protocols satisfy all four, positioning them as a comprehensive framework for next‑generation collaborative information systems.

In conclusion, the authors demonstrate that by augmenting traditional process models with a formally defined service network schema, it becomes possible to model, validate, and enforce complex social requirements inherent in human collaborations. This contribution opens avenues for more trustworthy, ethically aware, and socially aware workflow systems, and suggests future work on tool support, automated verification, and integration with existing BPM suites.