Implementing business rules and business processes in an SOA

One of the big drivers of using service-oriented architecture (SOA) is to increase the agility of the enterprise and minimize the impact of the inevitable changes. This is generally done by separating the often changing and fairly stable implementation artifacts. Common methods to support this separation are decomposition (decomposition) and encapsulation (encapsulation). The decomposition of SOA causes service definitions to represent more stable artifacts, while business processes represent more frequently changing artifacts 1. In a typical SOA implementation, services do not change frequently, but are often combined and reorganized to build/modify enterprise solutions.

This decomposition does not directly identify the location of the business rule--another frequently changing component in the overall IT implementation. Because of the fact that business rules can change quite often, one of the widely adopted practices is to associate them with business processes--more frequently changing SOA components. The popularity of this approach has also been supported by the fact that many practitioners use business rules as part of broader business process management (BMP), often tying business rules and business processes together. As a result, many people treat the business rules engine and business process engine as two competing technologies that business process/business rules implement. This is due to several general misconceptions:

Business rules and business processes have the same design model and implementation model

Business rules and business processes provide the same artifacts and can be used in the same way

In this article, we will summarize the similarities and differences between business rules and business processes, and introduce some guidelines for configuring business rules in an SOA implementation, as well as the appropriate use of each technique.

Business Rules

"Business rules describe the actions, definitions, and constraints that are applied to implementing an organization's goals." These rules are used to help organizations to better achieve their goals, better communication between the client and the agent, as well as better communication between the Organization and interested third parties, better demonstrate the fulfillment of the statutory obligations, operate more efficiently, operate better and automate, perform the analysis better in current practice, etc. "2. Business rules can be seen as a set of business practices that define the actual implementation-business logic. The implementation of this logic can often be simplified by using specialized tools-the business rules language and the business rules engine.

A rule language is a domain-specific language that contains constructs that define business rules. These constructs can vary widely according to business requirements. From a text description (using a rule-specific language or Simple English), it is possible to use a decision table or decision tree. In some cases, the order of execution of those business rules that use the rule flow may also be graphically determined. The last one is often the cause of confusion between business processes and business rules. Although they look similar, business process flows define the order in which services can be executed across many different and heterogeneous systems. On the other hand, the business rule flow is limited by the order in which the rules are executed (orchestration).

Domain-specific programming languages

The domain-specific programming language (DSL) is a programming language that is particularly useful for specific task groups. This is 3 relative to the General programming language (GPL) such as C, Java, C #, and so on. DSL is typically tailored specifically to specific problem areas. Thus it captures the semantics of the domain precisely. To further simplify their usage, DSLs are generally highly declarative and describe what needs to happen rather than how to do it (the latter is the responsibility of the language implementation). Because of this, DSL is often treated as a (executable) specification, not a programming language.

The main advantages of a particular DSL are domain-specific abstractions and symbols, as well as limited (or rather centralized) expressive capabilities. For some classes of the application, there are several 4 reasons why DSLs are more appealing than the GPL:

More easily programmed

Because it uses a higher level of abstraction, closely combined with the problem domain, defining what to implement, rather than how to implement it, the DSL program is generally more precise (because it is closely associated with the domain) and easier to implement and understand than the GPL implementation (not only for developers, The same is true for field experts. This generally leads to shorter development time and less costly maintenance costs. In addition, DSL has advanced data processing (debagging) support that allows you to analyze and debug code directly at the domain conceptual level.

Reuse of systems

Reuse is always one of the ways to improve the implementation of new applications and shorten the development cycle. Although the GPL facilitates reuse by using standard and domain-specific libraries, their actual usage depends on the developer. On the other hand, the DSL enforces the reuse of libraries that are used by DSL implementations. In addition, because DSLs are defined for particular problem areas, they capture and therefore reuse specific domain knowledge.

More easily validated

With the development of software engineering, formal code verification plays an important role in the successful development. For the GPL, this validation only ensures that the code executes, and for DSLs, because of their simplicity and domain alignment, validation can often ensure that the code produces the correct results.

Enhance cooperation

The use of the same business-related semantics across organizations facilitates the sharing of information and reduces the risk that the actual implementation of business logic does not match the expectations of business users.

The business rules engine supports the evaluation of rules expressed in the corresponding rule language. Their primary function is to manage a set of facts and to evaluate a rule group consisting of one of several assertions. Dealing with a large number of facts and effectively evaluating assertions is one of the major challenges of rule evaluation. The business rules engine generally provides a mapping mechanism to generate lower-level execution code, typically a common language class, based on business rule definitions, expressed in the language of business rules. Those classes can be used as a partial implementation of a larger business component. A direct consequence of this approach is that the implementation lifecycle of business rules is tightly integrated with the lifecycle of the business components to which they belong.

The flexibility and scalability of the implementation of business rules is achieved by activating dynamically changing rule maintenance support (using the initial rule language). This capability provides a way to dynamically modify business rules and quickly adapt to a changed business environment without rebuilding and redeploying implementations.

Declarative programming, such as what is specified, represents a selection model of a rule: if a rule evaluates to TRUE or false, something can be triggered (such as an action). Control flows, such as the order of these calls, are implicit and appear when the rule is triggered.