Service Oriented Framework For Analysis

The following list of 41 are common (detected by us) in the different service-oriented domains, including: REST (REpresentatinal State Transfer) service APIs, SCA (Service Component Architecture) systems, SOAP Web services, and service-oriented BPEL business processes.
We apply our different approaches to specify these antipatterns and to generate their detection algorithms.

SOA Antipatterns

REST linguistic antipatterns ---

  1. Contextualised vs. Contextless Resource Names
  2. Hierarchical vs. Non-hierarchical Nodes
  3. Tidy vs. Amorphous URIs
  4. Verbless vs. CRUDy URIs
  5. Singularised vs. Pluralised Nodes
  6. Pertinent vs. Non-pertinent Documentation

REST antipatterns ---

  1. Breaking Self-descriptiveness
  2. Forgetting Hypermedia
  3. Ignoring Caching
  4. Ignoring MIME Types
  5. Ignoring Status Code
  6. Misusing Cookies
  7. Tunneling Everything Through GET
  8. Tunneling Everything Through POST

SCA antipatterns ---

  1. Multi Service
  2. Tiny Service
  3. Sand Pile
  4. Chatty Service
  5. The Knot
  6. Nobody Home
  7. Duplicated Service
  8. Bottleneck Service
  9. Service Chain
  10. Data Service
  11. God Component
  12. Bloated Service
  13. Stovepipe Service

Web services antipatterns ---

  1. God Object Web Service
  2. Fine Grained Web Service
  3. Ambiguous Name
  4. Duplicated Web Service
  5. Chatty Web Service
  6. Low Cohesive Operations in the Same Port-Type
  7. Redundant Port-types
  8. Maybe It is Not RPC
  9. Data Web Service
  10. CRUDy Interface

Business process antipatterns ---

  1. Lack of Synchronisation Through Fork-Merge Pair
  2. Dangling Inputs and Outputs
  3. Deadlock Through Decision-Join Pair
  4. Cyclic Deadlock Through Join-Fork and Join-Decision Pair
  5. Cyclic Lack of Synchronisation Through Merge-Fork Pair
  6. The Stop Node in Parallel Execution Branches
  7. Multiple Connections Between Activities
  8. Passing Shared Data along Several Branches
  9. Data Output upon Termination
  10. Missing Data

Contextualised vs. Contextless Resource Names

Description: URIs should be contextual, i.e., nodes in URIs should belong to semantically-related context. Thus, the Contextless Resource Names antipattern appears when URIs are composed of nodes that do not belong to the same semantic context.

Example:
https://www.example.com/newspapers/players?id=123 is a Contextless Resource Names antipattern because 'newspapers' and 'players' do not belong to same semantic context.
https://www.example.com/soccer/team/players?id=123 is a Contextual Resource Names pattern because 'soccer', 'team', and 'players' belong to same semantic context.

Consequences: Contextless Resource Names do not provide a clear context for a request, which may mislead the APIs clients by decreasing the understandability of the APIs.

results

[top]

Hierarchical vs. Non-hierarchical Nodes

Description: Each node forming a URI should be hierarchically related to its neighbor nodes. In contrast, Non-hierarchical Nodes is an antipattern that appears when at least one node in a URI is not hierarchically related to its neighbor nodes.

Example:
https://www.example.com/professors/faculty/university/ is a Non-hierarchical Nodes antipattern since 'professors', 'faculty', and 'university' are not in a hierarchical relationship.
https://www.example.com/university/faculty/professors/ is a Hierarchical Nodes pattern since 'university', 'faculty', and 'professors' are in a hierarchical relationship.

Consequences: Using non-hierarchical names may confuse users on the real purpose of the API and hinders their understandability and, therefore, the API's usability.

results

[top]

Tidy vs. Amorphous URIs

Description: REST resource URIs should be tidy and easy to read. A Tidy URI is a URI with appropriate lower-case resource naming, no extensions, underscores, or trailing slashes. Amorphous URI antipatterns appear when URIs contain symbols or capital letters that make them difficult to read and use. As opposed to good practices, a URI is amorphous if it contains: (1) upper-case letter (except for Camel Cases), (2) file extensions, (3) underscores, and, (4) a final trailing-slash.

Example:
https://www.example.com/NEW Customer/ photo01.jpg/ is a Amorphous URI antipattern since it includes a file extension, upper-case resource names, and underscores.
https://www.example.com/customers/1234 is a Tidy URI pattern since it only contains lower-case resource naming, without extensions, underscores, or trailing slashes.

Consequences: (1) Upper/lower-case names may refer to different resources, RFC 3986. (2) File extensions in URIs violate RFC 3986 and affect service evolution. (3) Underscores are hidden when highlighting URIs, decreasing readability. (4) Trailing-slash mislead users to provide more resources.

results

[top]

Verbless vs. CRUDy URIs

Description: Appropriate HTTP methods, e.g., GET, POST, PUT, or DELETE, should be used in Verbless URIs instead of using CRUDy terms (e.g., create, read, update, delete, or their synonyms). The use of such terms as resource names or requested actions is highly discouraged.

Example:
POST https://www.example.com/update/players/age?id=123 is a CRUDy URIs antipattern since it contains a CRUDy term 'update' while updating the user's profile color relying on an HTTP POST method.
POST https://www.example.com/players/age?id=123 is a Verbless URIs pattern since is an HTTP POST request without any verb.

Consequences: Using CRUDy terms in URIs can be confusing for API clients, i.e., in the best cases they overload the HTTP methods and in the worst cases they go against HTTP methods. CRUDy terms in a URI confuse and prohibit users to use proper HTTP methods in a certain context and may introduce another REST antipattern, Tunnelling through GET/POST.

results

[top]

Singularised vs. Pluralised Nodes

Description: URIs should use singular/plural nouns consistently for resources naming across the API. When clients send PUT/DELETE requests, the last node of the request URI should be singular. In contrast, for POST requests, the last node should be plural. Therefore, the Pluralised Nodes antipattern appears when plural names are used for PUT/DELETE requests or singular names are used for POST requests. However, GET requests are not affected by this antipattern.

Example:
The first example URI is a POST method that does not use a pluralised resource, thus leading to Pluralised Nodes antipattern.
DELETE https://www.example.com/team/players or POST https://www.example.com/team/player
On the other hand, for the Singularised Nodes pattern, the DELETE request acts on a single resource for deleting it.
DELETE https://www.example.com/team/player or POST https://www.example.com/team/players

Consequences: If a plural node for the PUT (or DELETE) request is used at the end of a URI, the API clients cannot create (or delete) a collection of resources, which may result in, for example, a 403 Forbidden server response. In addition, even if the resources can be filtered through query-like parameters, it may confuse the user whether one or multiple resources are being accessed/deleted.

results

[top]

Pertinent vs. Non-pertinent Documentation

Description: The Non-pertinent Documentation linguistic antipattern occurs when the documentation of a REST resource URI is in contradiction with its structure (e.g., nodes separated by slashes in URIs). This antipattern applies to both a resource URI and its corresponding documentation. In contrast, a well-documented URI should properly and clearly describe its purpose using semantically related terms.

Example:
https://api.twitter.com/1.1/favorites/list -- Returns the 20 most recent Tweets liked by the authenticating or specified user. Note: the like action was known as favorite before November 3, 2015; the historical naming remains in API methods and object properties.
This URI-documentation pair from Twitter shows no semantic similarity between them and, thus, appears as $Non-pertinent Documentation antipattern.
https://instagram.com/media/media-id/comments -- Gets a list of recent comments on a media object. The public content permission scope is required to get comments for a media that does not belong to the owner of the access token.
In contrast to the previous example, this URI-documentation pair shows a high relatedness and is a Pertinent Documentation pattern.

Consequences: Developers can make wrong assumptions on resource URIs, which may hinder their understandability and reusability. Overall, this is misleading because the client developer might be unsure whether to follow the documentation or the URI structure when trying to understand its purpose. Moreover, for the API providers, it might cause comprehension difficulties during the maintenance and evolution of APIs.

[top]

Breaking Self-descriptiveness

Description: REST developers tend to ignore the standardised headers, formats, or protocols and use their own customised ones. This practice shatter the self-descriptiveness or containment of a message header. Breaking the self-descriptiveness also limits the reusability and adaptability of REST resources.

results

[top]

Forgetting Hypermedia

Description: The lack of hypermedia, i.e., not linking resources, hinders the state transition for REST applications. One possible indication of this antipattern is the absence of URL links in the resource representation, which typically restricts clients to follow the links, i.e., limits the dynamic communication between clients and servers.

results

[top]

Ignoring Caching

Description: REST clients and server-side developers tend to avoid the caching capability due to its complexity to implement. However, caching capability is one of the principle REST constraints. The developers ignore caching by setting Cache-Control: no-cache or no-store and by not providing an ETag in the response header.

results

[top]

Ignoring MIME Types

Description: The server should represent resources in various formats e.g., xml, json, pdf, etc., which may allow clients, developed in diverse languages, a more flexible service consumption. However, the server side developers often intend to have a single representation of resources or rely on their own formats, which limits the resource (or service) accessibility and reusability.

results

[top]

Ignoring Status Code

Description: Despite of a rich set of defined application-level status codes suitable for various contexts, REST developers tend to avoid them, i.e., rely only on common ones, namely 200, 404, and 500, or even use the wrong or no status codes. The correct use of status codes from the classes 2xx, 3xx, 4xx, and 5xx helps clients and servers to communicate in a more semantic manner.

results

[top]

Misusing Cookies

Description: Statelessness is another REST principle to adhere, session state in the server side is disallowed and any cookies violate RESTfulness. Sending keys or tokens in the Set-Cookie or Cookie header field to server-side session is an example of misusing cookies, which concerns both security and privacy.

results

[top]

Tunneling Everything Through GET

Description: Being the most fundamental HTTP method in REST, the GET method retrieves a resource identified by a URI. However, very often the developers rely only on GET method to perform any kind of actions or operations including creating, deleting, or even for updating a resource. Nevertheless, HTTP GET is an inappropriate method for any actions other than accessing a resource, and does not match its semantic purpose, if improperly used.

results

[top]

Tunneling Everything Through POST

Description: This anti-pattern is very similar to the previous one, except that in addition to the URI the body of the HTTP POST request may embody operations and parameters to apply on the resource. The developers tend to depend only on HTTP POST method for sending any types of requests to the server including accessing, updating, or deleting a resource. In general, the proper use of HTTP POST is to create a server-side resource.

results

[top]

Multi Service

Description: Multi Service also known as God Object corresponds to a service that implements a multitude of methods related to different business and technical abstractions. This aggregates too much into a single service, such a service is not easily reusable because of the low cohesion of its methods and is often unavailable to end-users because of its overload, which may induce a high response time.

RULE CARD: MultiService {
  RULE: MultiService { INTER MultiMethod HighResponse LowAvailability LowCohesiong };
  RULE: MultiMethod { NMD VERY HIGH };
  RULE: HighResponse { RT VERY HIGH };
  RULE: LowAvailability { A LOW };
  RULE: LowCohesion { COH LOW };
};

[top]

Tiny Service

Description: Tiny Service is a small service with few methods, which only implements part of an abstraction. Such service often requires several coupled services to be used together, resulting in higher development complexity and reduced usability. In the extreme case, a Tiny Service will be limited to one method, resulting in many services that implement an overall set of requirements.

RULE CARD: TinyService {
  RULE: TinyService { INTER FewMethod HighCoupling };
  RULE: FewMethod { NMD VERY LOW };
  RULE: HighCoupling { CPL HIGH };
};

[top]

Sand Pile

Description: Sand Pile is also known as `Fine-Grained Services'. It appears when a service is composed by multiple smaller services sharing common data. It thus has a high data cohesion. The common data shared may be located in a Data Service antipattern.

RULE CARD: SandPile {
  RULE: SandPile { COMPOS FROM ParentService ONE TO ChildService MANY };
  RULE: ChildService { ASSOC FROM ContainedService MANY TO DataSource ONE };
  RULE: ParentService { COH HIGH };
  RULE: DataSource { RULE CARD: DataService };
  RULE: ContainedService { NRO > 1 };
};

[top]

Chatty Service

Description: Chatty Service corresponds to a set of services that exchange a lot of small data of primitive types, usually with a Data Service antipattern. The Chatty Service is also characterized by a high number of method invocations. Chatty Service chats a lot with each other.

RULE CARD: ChattyService {
  RULE: ChattyService { INTER TotalInvocation DSRuleCard };
  RULE: DSRuleCard { RULE CARD: DataService };
  RULE: TotalInvocation { NMI VERY HIGH };
};

[top]

The Knot

Description: The Knot is a set of very low cohesive services, which are tightly coupled. These services are thus less reusable. Due to this complex architecture, the availability of these services can be low, and their response time high.

RULE CARD: TheKnot {
  RULE: TheKnot { INTER HighCoupling LowCohesion LowAvailability HighResponse };
  RULE: HighCoupling { CPL VERY HIGH };
  RULE: LowCohesion { COH VERY LOW };
  RULE: LowAvailability { A LOW };
  RULE: HighResponse { RT HIGH };
};

[top]

Nobody Home

Description: Nobody Home corresponds to a service, defined but actually never used by clients. Thus, the methods from this service are never invoked, even though it may be coupled to other services. But still they require deployment and management, despite of their no usage.

RULE CARD: NobodyHome {
  RULE: NobodyHome { INTER IncomingReference MethodInvocation };
  RULE: IncomingReference { NIR GREATER 0 };
  RULE: MethodInvocation { NMI EQUAL 0 };
};

[top]

Duplicated Service

Description: Duplicated Service a.k.a. The Silo Approach introduced by IBM corresponds to a set of highly similar services. Since services are implemented multiple times as a result of the silo approach, there may have common or identical methods with the same names and,or parameters.

RULE CARD: DuplicatedService {
  RULE: DuplicatedService { ANIM HIGH };
};

[top]

Bottleneck Service

Description: Bottleneck Service is a service that is highly used by other services or clients. It has a high incoming and outgoing coupling. Its response time can be high because it may be used by too many external clients, for which clients may need to wait to get access to the service. Moreover, its availability may also be low due to the traffic.

RULE CARD: BottleneckService {
  RULE: BottleneckService { INTER LowPerformance HighCoupling };
  RULE: LowPerformance {INTER LowAvailability HighResponse };
  RULE: HighResponse { RT HIGH };
  RULE: LowAvailability { A LOW };
  RULE: HighCoupling { CPL VERY HIGH };
};

[top]

Service Chain

Description: Service Chain a.k.a. Message Chain in OO systems corresponds to a chain of services. The Service Chain appears when clients request consecutive service invocations to fulfill their goals. This kind of dependency chain reflects the action of invocation in a transitive manner.

RULE CARD: ServiceChain {
  RULE: ServiceChain { INTER TransitiveInvocation LowAvailability };
  RULE: TransitiveInvocation { NTMI VERY HIGH };
  RULE: LowAvailability { A LOW };
};

[top]

Data Service

Description: Data Service a.k.a. Data Class in OO systems corresponds to a service that contains mainly accessor methods, i.e., getters and setters. In the distributed applications, there can be some services that may only perform some simple information retrieval or data access to such services. Data Services contain usually accessor methods with small parameters of primitive types. Such service has a high data cohesion.

RULE CARD: DataService {
  RULE: DataService { INTER HighDataAccessor SmallParameter PrimitiveParameter HighCohesion };
  RULE: SmallParameter { ANP LOW };
  RULE: PrimitiveParameter { ANPT HIGH };
  RULE: HighDataAccessor { ANAM VERY HIGH };
  RULE: HighCohesion { COH HIGH };
};

[top]

God Component

Description: God Component in SCA technology corresponds to a component that encapsulates a multitude of services. This component represents high responsibility enclosed by many methods with many different types of parameters to exchange. It may have a high coupling with the communicating services. Being at the component-level, God Component is at a higher level of abstraction than Multi Service, which is at the service-level, and usually aggregates a set of services.

RULE CARD: GodComponent {
  RULE: GodComponent { INTER HighEncapsulatedService MultiMethod HighParameter };
  RULE: HighEncapsulatedService { NOSE HIGH };
  RULE: MultiMethod { NMD VERY HIGH };
  RULE: HighParameter { TNP VERY HIGH };
};

[top]

Bloated Service

Description: Bloated Service is an antipattern related to service implementation where services in SOA become 'blobs' with one large interface and lots of parameters. Bloated Service performs heterogeneous operations with low cohesion among them. It results in a system with less maintainability, testability, and reusability within other business processes. It requires the consumers to be aware of many details (i.e., parameters) to invoke or customize them.

RULE CARD: BloatedService {
  RULE: BloatedService { INTER SingleInterface MultiMethod HighParameter LowCohesion };
  RULE: SingleInterface { NOI EQUAL 1 };
  RULE: MultiMethod { NMD VERY HIGH };
  RULE: HighParameter { TNP VERY HIGH };
  RULE: LowCohesion { COH LOW };
};

[top]

Stovepipe Service

Description: Stovepipe Service is an antipattern with large number of private or protected methods that primarily focus on performing infrastructure and utility functions (i.e., logging, data validation, notifications, etc.) and few business processes (i.e., data type conversion), rather than focusing on main operational goals (i.e., very few public methods). This may result in services with duplicated code, longer development time, inconsistent functioning, and poor extensibility.

RULE CARD: StovepipeService {
  RULE: StovepipeService { INTER HighUtilMethod FewMethod DuplicatedCode };
  RULE: HighUtilMethod { NUM VERY HIGH };
  RULE: FewMethod { NMD VERY LOW };
  RULE: DuplicatedCode { ANIM HIGH };
};

[top]

God Object Web Service

Description: God Object Web Service corresponds to a Web service that contains a large number of operations related to different business abstractions. Often the client interactions break due to frequent changes in the Web service definition, hence cause low availability. This antipattern affects the reusability because the operations are very low cohesive. Moreover, being overloaded with a multitude of operations, this antipattern may also result in high response time.

results

RULE CARD: GodObjectWebService {
  RULE: GodObjectWebService { INTER MultiOperation HighResponse LowAvailability LowCohesion };
   RULE: LowCohesion {COH VERY LOW};
   RULE: MultiOperation {NOD HIGH};
   RULE: HighRT {RT VERY HIGH};
   RULE: LowA {A LOW};
};

[top]

Fine Grained Web Service

Description: Fine Grained Web Service is a small Web service with few operations implementing only a part of an abstraction. Such a Web service often requires several coupled Web services to complete an abstraction, resulting in higher development complexity, reduced usability. Moreover, since the related operations for an abstraction spread across services, individual services are less cohesive.

results

RULE CARD: FineGrainedWebService {
   RULE: FineGrainedWebService {INTER FewOperation HighCoupling HighCohesion};
   RULE: FewOperation {NOD LOW};
   RULE: HighCoupling {CPL VERY HIGH};
   RULE: HighCohesion {COH LOW};
};

[top]

Ambiguous Name

Description: Ambiguous Name is an antipattern where the developers use the names of interface elements (e.g., portTypes, operations, and messages) that are very short or long, include too general terms, or even show the improper use of verbs, etc. Ambiguous names are not semantically and syntactically sound and impact the discoverability and the reusability of a Web service.

results

RULE CARD: AmbiguousName {
   RULE: AmbiguousName {INTER GeneralTerm ShortORLongSignature VerbedMessage MultiVerbedOperation};
   RULE: ShortORLongSignature {UNION ShortSignature LongSignature};
   RULE: LongSignature {ALS VERY HIGH};
   RULE: ShortSignature {ALS VERY LOW};
   RULE: GeneralTerm {RGTS HIGH};
   RULE: VerbedMessage {NVMS > 0};
   RULE: MultiVerbedOperation {NVOS > 1};
};

[top]

Duplicated Web Service

Description: Duplicated Web Service, corresponds to a set of highly similar Web services. Because Web services are implemented multiple times as a result of the silo approach, there might exist common or identical operations with the same names and{or message parameters.

results

RULE CARD: DuplicatedService {
   RULE: DuplicatedWebService {INTER IdenticalPortType IdenticalOperation};
   RULE: IdenticalPortType {ARIP HIGH};
   RULE: IdenticalOperation {ARIO HIGH};
};

[top]

Chatty Web Service

Description: Chatty Web Service is an antipattern where a high number of operations are required to complete one abstraction where the operations are typically attribute-level setters or getters. A chatty Web service may have many fine grained operations for which: (i) maintenance becomes harder since inferring the order of invocation is difficult and (ii) many interactions are required, which degrades the overall performance with higher response time.

results

RULE CARD: ChattyWebService {
     RULE: ChattyWebService {INTER LowCohesion HighDataAccessor MultiOperation LowPerformance};
   RULE: LowCohesion {COH LOW};
   RULE: HighDataAccessor {ANAO VERY HIGH};
   RULE: MultiOperation {NOD HIGH};
   RULE: LowPerformance {INTER HighRT LowA};
   RULE: HighRT {RT HIGH};
   RULE: LowA {A LOW};
};

[top]

Low Cohesive Operations in the Same Port-Type

Description: Low Cohesive Operations in the Same PortType is an antipattern where developers place low cohesive operations in a single prototype. From the Web services perspective, if the operations belonging to the same prototype do not provide a set of semantically related operations, the prototype becomes less cohesive.

results

RULE CARD: LowCohesiveOperations {
   RULE: LowCohesiveOperations {INTER MultiOperation LowCohesivePT};
   RULE: MultiOperation {NOD HIGH};
   RULE: LowCohesivePT {ARIO LOW};
};

[top]

Redundant PortTypes

Description: Redundant PortTypes is an antipattern where multiple portTypes are duplicated with the similar set of operations. Very often, such portTypes deal with the same messages. Redundant PortType antipattern may negatively impact the ranking of the Web Services.

results

RULE CARD: RedundantPortType {
   RULE: RedundantPortType {INTER MultiPortType HighCohesivePT};
   RULE: MultiPortType {NPT > 1};
   RULE: MultiOperations {NOPT > 1};
   RULE: HighCohesivePT {ARIP VERY HIGH};
};

[top]

Maybe It is Not RPC

Description: Maybe It's Not RPC is an antipattern where the Web service mainly provides CRUD operations with a large number of parameters. This antipattern causes poor system performance because the clients often wait for the synchronous responses.

results

RULE CARD: MaybeItsNotRPC {
   RULE: MaybeItsNotRPC {INTER HighRT HighCRUDOperation HighParameter};
   RULE: HighRT {RT HIGH};
   RULE: HighCRUDOperation {NCO VERY HIGH};
   RULE: HighParameter {ANP HIGH};
};

[top]

Data Web Service

Description: Data Web Service typically contains accessor operations, i.e., getters and setters. In a distributed environment, some Web services that may only perform some simple information retrieval or data access operations. A Data Web Service usually deals with very small messages of primitive types and may have high data cohesion.

results

RULE CARD: DataWebService {
   RULE: DataWebService {INTER HighCohesion PrimitiveParameter HighAccessor LowParameter};
   RULE: HighCohesion {COH HIGH};
   RULE: PrimitiveParameter {ANPT HIGH};
   RULE: HighAccessor {ANAO HIGH};
   RULE: LowParameter {ANP LOW};
};

[top]

CRUDy Interface

Description: CRUDy Interface is an antipattern where the design encourages services the RPC-like behavior by creating CRUD-type operations, e.g., createX(), readY(), etc. Interfaces designed in that way might be chatty because multiple operations need to be invoked to achieve one goal. In general, CRUD operations should not be exposed via interfaces.

results

RULE CARD: CRUDyInterface {
   RULE: CRUDyInterface {INTER ChattyInterface HighCRUDOperation};
   RULE: ChattyInterface {   RULE CARD: ChattyWebService};
   RULE: HighCRUDOperation {NCO > 1};
};

[top]

Lack of Synchronisation Through Fork-Merge Pair

Description: In Lack of Synchronisation through Fork-Merge Pair antipattern, usually the fork-merge pair appears. The fork triggers output on all of its outgoing branches, while the merge always wait for input on only one of its incoming connections. Further later in the process, another final merge may cause synchronisation problem because the latter merge requires all the inputs, which are not available yet. Thus, the users will obtain several executions of the process fragments for each input value arrived at different times in the final merge.

approach

[top]

Dangling Inputs and Outputs

Description: Dangling Inputs and Outputs is an antipattern where the inputs and outputs of an activity or gateway remain unconnected or unused. Dangling outputs are produced by a task or sub-process, but never used anywhere in the process. In contrast, dangling inputs might cause deadlocks if the data input ofľ a gateway or an activity is never provided, which is required by the process.

approach

[top]

Deadlock Through Decision-Join Pair

Description: Deadlock Through Decision-Join Pair is an antipattern where the decision node appears before a join gateway. This structure leads to a deadlock: the decision triggers a single output, while the join waits for input on all of its branches, but single input is supplied. Alternatively, as the variant of this antipattern, if a task produces two alternative outputs, i.e., behaves like an exclusive decision, and the following task requires both the outputs as its input, then there is also a deadlock as both the required inputs might never be produced.

approach

[top]

Cyclic Deadlock Through Join-Fork and Join-Decision Pair

Description: Cyclic Deadlock through Join-Fork and Join-Decision Pair is an antipattern where a backward connection exists from an exclusive decision to a join. The join waits for input on all of its branches. However, one of its incoming branches can only receive the input after the join has been executed in the first cycle, because its input is initiated from another modeling element, i.e., an exclusive decision, later in the process. This cyclic dependency between the join and the decision (or fork), where the join must be executed before the decision (or fork) may cause a cyclic deadlock.

approach

[top]

Cyclic Lack of Synchronisation Through Merge-Fork Pair

Description: Cyclic Lack of Synchronisation through Merge-Fork Pair occurs in the cyclic models when backward connections appear in branches that are executed in parallel, which are not synchronised by a join before the backward connection is added to the process. In such case, each of the backward connections results from the same fork and ends in a merge located earlier in the model. This antipattern may result in an infinite iterations of the process.

approach

[top]

The Stop Node in Parallel Execution Branches

Description: The Stop Node in Parallel Execution Branches occurs when the modelers are not aware of the global effect of a stop node and use it to terminate each individual branch of a fork or an inclusive decision. This may result in for the process an unexpected shutdown: branches ending with stop nodes may terminate the whole process, even though the goal is to end a single execution branch.

approach

[top]

Multiple Connections Between Activities

Description: Multiple Connections between Activities is an antipattern where the redundant control-flow andľor data-flow connections exist between tasks. This antipattern has two variants in its simplest form: (i) multiple control-flows between tasks that increase the process structural complexity, and (ii) multiple data-flow connections of the same type from a task where only a single data-flow of each type is enough for most processes.

approach

[top]

Passing Shared Data along Several Branches

Description: Passing Shared Data along Several Branches is a data-flow antipattern where shared inputs or outputs are duplicated along several branches. Typically, the duplication of outputs or inputs of a task hinders the reusability of a process fragment. The best practice is to use a fork for distributing single input among branches and a join for aggregating unique outputs into a single flow.

approach

[top]

Data Output upon Termination

Description: Data Output upon Termination of a Process is an antipattern where an output may be produced in the process interface even the process termination is done at an earlier stage of the process by an activity. As a result, other activities may have data as the output that is not a part of the main process output. Such outputs may remain unconnected and become a dangling output.

approach

[top]

Missing Data

Description: Missing Data is a common data-flow antipattern where certain data elements are required but were not created or have been deleted. This may cause deadlock for a certain activity, or even for the whole process depending on the execution context and the design of the process.

approach

[top]

[top]



Logo Logo