Strategies For Building: Inrule Technology 651 W. Washington Suite 500 Chicago, Il 60661 312.648.1800

Strategies for Building
Dynamic .NET Applications
InRule Technology
651 W. Washington
Suite 500
Chicago, IL 60661
312.648.1800
inrule.com
© 2013 InRule Technology, Inc. All rights reserved. InRule, InRule Technology, irAuthor, irSDK
and irServer are registered trademarks of InRule Technology, Inc. All other trademarks
referenced herein belong to their respective companies.
Strategies for Building Dynamic .NET Applications
Table of Contents Topic Page
Objectives 3
Section 1: Strategies for Dynamic Business Applications

Strategies for Supporting a Dynamic Business 4
Strategy 1: Understand Dynamic Business
Applications and Dynamic Decisioning 5
Strategy 2: Determine Project Suitability for a
Dynamic Application Approach 6
Strategy 3: Encourage the Joint Participation of IT
and Business 6
Strategy 4: Isolate Rapidly Changing Logic with a
BRMS 7
Strategy 5: Choose the Right Integration Approach
for Your Needs 9
Section 2: Overview of Business Rule Technology for .NET

Components of a BRMS 15
Leveraging Investments in Key Microsoft
Technologies 16
Exploiting the Power of .NET 17
Summary 18
About InRule Technology 19
2|P a ge inrule.com
© 2013 InRule Technology, Inc. All rights reserved.
Objectives of this A business must be decisive, based on decisions that are accurate, timely,
consistent and easy to change. And businesses rely on IT to build systems that
White Paper enable and automate decisive results. For organizations implementing
applications on the .NET platform, IT has the opportunity to leverage their
investments in key Microsoft technologies including Visual Studio and Word.
Section 1 of this paper provides .NET architects and development and project
managers with a basis for understanding dynamic business applications and
dynamic decisioning. It outlines five practical strategies for implementing
dynamic applications on the .NET platform, including diagrams depicting several
possible integration approaches.
Section 2 is intended for architects, development and project managers,

business analysts and subject matter experts (SMEs) as an introduction to the
capabilities of a Business Rule Management System (BRMS).
In addition Section 2 offers several important considerations for leveraging

investments in key Microsoft technologies.
3|P a ge inrule.com
Strategies for Enabling What happens when your business changes and your applications don’t
change to support it?
a Decisive Business Typically, existing applications must be updated or completely rewritten, and
cobbled together to try to keep up with the new (and always changing)
demands of the business. Decision logic is based on multiple inputs that are
changing more and more frequently due to internal policies and external forces,
such as legislation, regulations, and changing competition.
Consider essential Simply rewriting applications is no longer good enough.

everyday decision making It is costly, time consuming, and often takes IT professionals away from more
activities as candidates for strategic work to focus on small and frequent changes to business logic.
dynamic decision services Companies are increasingly using business rule technology to improve the
delivered via business rule means of building and maintaining applications.
technology. These five
strategies will help you get What are the key strategies to consider when creating these Dynamic Business
started. Applications – applications that change to reflect the changing demands of
business?
Following are five key strategies to consider:
KEY STRATEGIES SUMMARY
1. Understand Dynamic Business Applications &

Dynamic Decisioning
2. Determine project suitability for a Dynamic Business
Application approach
3. Encourage the joint participation of IT and Business
4. Isolate rapidly changing logic with a Business Rule
Management System (BRMS)
5. Choose the right integration approach for your
needs
4|P a ge inrule.com
Understand Dynamic Business Applications & Dynamic Decisioning

Strategy 1 Historically, application development has successfully focused on values such as
improving data access, transactional throughput and scalability. Now the focus
has turned to building applications that change quickly to accommodate the
changing needs of a business. These are called Dynamic Business Applications.
Dynamic Business Applications are built to support a rapidly changing business

world. Rather than traditional applications that support requirements at a point
in time (i.e. not built for change), Dynamic Business Applications anticipate and
easily accommodate change. One characteristic of Dynamic Business
Applications is that, in contrast to monolithic applications, they are comprised
of application components that improve time to value and encourage reuse.
Automating the operational decisions that drive the business is a major benefit
of Dynamic Business Applications. The logic and input behind these decisions
change frequently and is understood best by business users (analysts, risk
managers, etc.). For purposes of this Section 2 we will refer to both the
business analyst and SME roles as SMEs. When an application is built with
Dynamic decisioning in mind, SMEs control the rules, logic, and calculations that
are at the heart of every day operations. Dynamic decisioning frees IT staff from
the burden of frequent updates to business logic, yet keeps them in control.
Combine dynamic decisioning with Web services or a web-service like approach,

and you have Dynamic Decision Services. Web services are self contained
components that allow applications to share logic or data across a network, with
one of the methods using a Service Oriented Architecture (SOA) approach. They
can be anything from a call to a FedEx tracking service or a complex process.
Decision Service: The term decision service refers to a Web service that provides decision logic;
A Web service that
decision services are created to be shared and reused as needed by multiple
provides decision logic.
applications. Web services and decision services are nothing new. But when
you isolate and expose the logic used for a decision service and make it easily
maintainable, even by non-technical SMEs, then you are using dynamic decision
services and you are on your way to exploiting the power of a services
approach.
5|P a ge inrule.com
Determine project suitability for a Dynamic Rule Application

Strategy 2
Approach
Not all business applications need to be dynamic, and not all logic needs to be,
or is appropriate for, implementing as a decision service or using a BRMS.
Before beginning a project, determine the suitability of the project for rules-
based development and decision services. Some of these criteria have been
covered in the Introduction and Section 1 and will help in your determination:
 Business logic changes frequently
 Changes are time sensitive
 Business logic is shared across systems
 Rules affect customer interaction or other core business operations
 Non-technical SMEs have the best understanding of the underlying logic
that drives a decision
 Developers need to focus on strategic development efforts rather than
the minutia of logic changes
 Any of the following apply:
- Versioning
- Approval
- Regulation Requirements
- Compliance
Strategy 3 Encourage the Joint Participation of IT and Business

The internal and external policies that drive decisions change too frequently and
require too much input from SMEs for IT to handle alone. There has to be active
involvement by business people, and some aspects of creating and changing
decision logic will be outside of IT control. This is a disturbing thought for many
long-time IT professionals as they are being directed to change not just the
development process, but ownership and accountability.
Yielding some control over business logic is not something to be taken lightly,
but it should be viewed by IT as an opportunity to support the business without
getting mired in the minutia of changing business policies. In reality, non-
technical people have been involved in automating decision logic for years. But
Yielding some control over the tools they use – typically spreadsheets – are not built to be scalable or
business logic is not shareable. Worse, they are completely outside of the control of IT and as such
something to be taken lightly, may pose a security risk.
but it should be viewed by IT
as an opportunity to support It is important to recognize that the future of application development is not
“business as usual,” nor is it “IT as usual.” Application development has become
the business without getting
a partnership using technology that enables IT professionals and SMEs to create
mired in the minutia of
components supporting their domain of expertise, which will be assembled (and
changing business policies. reused and reassembled) by IT into Dynamic Business Applications. The next
strategy explores technology that enables collaboration and empowers SMEs,
while allowing IT to maintain control.
6|P a ge inrule.com
Strategy 4 Isolate Rapidly Changing Logic with a Business Rule Management

System (BRMS)
Automating decisions is at the core of Dynamic Business Applications, and
business rules are where it starts. A technical architecture is required to build
Dynamic Business Applications, and this is where BRMS comes in.
A BRMS isolates, externalizes and exposes decision logic in the form of rules and
calculations, making it easier to find and share decision logic across the
enterprise. The BRMS provides a window into the logic of every day decisions
(see figure 1). Much like what a DBMS did for data a BRMS does for business
rules -- making logic a corporate asset to be shared across the organization.
The Essense of a BRMS
Consider a BRMS when

decision logic:
 Is Volatile
 Is Complex
 Needs to be Visible A BRMS plays an important role in helping IT manage the shift in accountability
and ownership for Dynamic Business Applications with features that enable IT
and SMEs to collaborate. Using a BRMS, business professionals can translate
their knowledge into decision logic, in the form of business rules. IT however
retains control over the development environment; for example by setting up
the parameters within which business users will create and manage rules.
As stated earlier, not all logic needs to be implemented using a BRMS. A good
rule of thumb is to think of this in three terms:
 Volatility - Decision logic that changes frequently should be externalized
to a rule engine where it is easier to find and update
 Complexity - Complex rules and calculations are better expressed in a
rule engine, where it’s easier to see if all possible conditions are covered
 Visibility - Externalizing rules with a business rule engines can make logic
more easily visible to others in the organization for risk or compliance
reasons
7|P a ge inrule.com
Once you have identified logic that is volatile, complex and/or needs to be
visible to others, delegate responsibility for that logic to SMEs who make
decisions based on this logic and who have a thorough understanding of the
underlying business requirements. This doesn’t mean turning SMEs into
programmers, but giving them the ability to author and update rules and
calculations that they understand.
By putting business decision logic in the hands of subject matter experts, IT can
reduce or remove the bottleneck created by constantly changing business
policies.
We’ll cover this more exhaustively in Section 3, but some of the enabling
features to look for in a BRMS include:
 An interface for authoring decision logic that allows an expression of
logic in English-like language, intuitive enough for non-technical users
yet robust enough for technical developers to author complex logic. This
allows SMEs from across the business to contribute to a business
solution without the need to translate business terms to programming
syntax.
 Easy integration with data sources, typically set up by IT so that SMEs
can write rules in terms they with which they are familiar (e.g. loan
amount, interest rate, etc.), without needing to understand the data
source, its structure, and how to access it.
 An integrated testing environment, allowing rule authors to verify the
behavior and results of rules as they author them.
 Administration and management capabilities that allow IT to easily
manage the rules created by SMEs. This includes functionality such as
setting access permissions, managing versions of rules, and controlling
the promotion of rules or sets or rules from development to testing to
production.
 An execution engine that optimizes the running of multiple rules under
a variety of conditions.
 A rule engine that can be exposed as a web service or an in-process call
8|P a ge inrule.com
Strategy 5 Choose the Right Integration Approach for Your Needs

BRMS typically provide a wide array of options for implementing the rule engine
itself into your application. Typically those options revolve around two key
approaches 1) run the engine in-process or 2) run it as a web service. If built
correctly an in-process approach can often provide many, if not all, of the
benefits of a web service approach without the associated performance costs of
making calls over the wire.
Following are examples of the most common implementation approaches for

calling a rule engine from an application; many other configurations are
possible. Note that in the diagrams the engine icon denotes the location of the
BRMS rule engine.
In general all of the examples follow a similar pattern:

1. The rule engine gets the rules from either a centralized rule store (aka
repository or catalog) or a file
2. The application provides data to the rule engine
3. Rules are run against the data and in some cases modify it
4. Modified data and execution results such as messages or statistics are
then made available by the rule engine
9|P a ge inrule.com
Integration Approaches Web Application with the Rule Engine In-process

In this example the engine is run in-process on each web server in a server farm
while the rules are pulled from the centralized rule store. The rules are cached
locally and the application only makes a call to the rule store periodically to get
the latest. This means that many of the benefits of placing logic in a web service
are achieved without the associated overhead.
10 | P a g e inrule.com
Integration Approaches Exposing Rules as a Decision Service (i.e. Black Box)
In this example the rules are executed on a centralized Decision Service which
pulls the rules from the Centralized Rule Store (enabling scale-out of the
decision service hardware if needed). The benefit to this approach is that a
wide variety of applications can pass data via a web service call and receive a
decision back. With this approach, those developing/configuring the calling
applications do not need to understand even the basics of how to call the rule
engine or even know that a rule engine is being used.
Web Service
Web Application Call
Server
Rules
Web Service
Call
Decision Service Centralized

Workflow Server Rule Store
Web Service
or other
Call
3rd Party
Tools Web Service
Call
J2EE
Apps
Mainframe
Apps
Integration Approaches Rule Engine Execution Service
Many BRMSs offer what’s called an execution service. Typically it’s a web
service wrapper around the rule engine which allows for the rules to be called
without the need to write any custom code. The main difference between this
approach and the previously mentioned “Black Box” approach is that the person
configuring/developing the calling application does need to have some
understanding of how to call the rule engine. The main benefit, though, is that
no custom code has to be maintained.
Integration Approaches Running Rules in the Field (i.e. Disconnected)
Often there is a desire to embed a rule engine in a desktop application that will
be on a machine that is disconnected from the organization’s network. By
running the rule engine in-process from within the desktop application and
storing the rules locally as a file this can be achieved quite easily.
Typically with these types of applications there is synchronization functionality

that allows the application to get the latest version of the rules when the device
is on the network. However it could be as simple as manually copying a file
containing the rules from a file share to the local device.
Integration Approaches High-volume Data Processing

In this type of scenario rules need to be run over a large volume of transactional
data. Typically this needs to be completed in a set amount of time (e.g. 500K
records in 3 hours). By creating multiple instances of the rule engine across a
battery of servers the processing can be done in parallel and scaled out to meet
whatever service level is needed.
The purpose of the controller server is to provide a queue of work from which
each of the processing servers pulls their directives. For example, the queue
could simply be a list of primary keys that the processing servers use to retrieve
the data. As mentioned in the previous examples the rules would come from a
centralized catalog which would most like be located in the Database Cluster.
Controller
Server
Execution Execution Execution Execution

Server Server Server Server
Database
Cluster
Conclusion
Application development is in the midst of significant changes, as rapidly
changing business requirements drive the need for Dynamic Business
Applications. The future of application development includes collaboration
between IT and non-technical subject matter experts, aided by technology that
supports collaboration and puts business decision logic in the hands of business
decision makers.
You can add value in the journey toward Dynamic Business Applications by
externalizing business rules and incorporating them into your application
frameworks. The strategies outlined above can help you gain real value today
while moving you closer to a strategic Dynamic Business Applications objective.
SECTION 2: Overview of Business Rule Technology for .NET
Authoring, Managing, Integrating, and Executing Business Rules

Components of a
for .NET
.NET BRMS This section is intended for Architects, Developers, Business Analysts and
Subject Matter Experts (SMEs) as an introduction to the capabilities of a
Business Rule Management System (BRMS).
Every BRMS should include capabilities allowing users to author and test, store
and manage, integrate and execute business rules.
Every BRMS should include
Author and Test
capabilities allowing users to:
 Author and Test  Provides authoring interfaces for both developers and subject matter
experts (business users)
 Store and Manage
 Allows the authoring of complex rules using Business Language
 Integrate Authoring and Decision Tables—without custom programming
 Execute  Includes integrated real-time testing allowing users to verify rules and
Business rules calculations and perform regression testing without a separate test
environment
Store and Manage

 Catalog enables management of rules from development through
production
 Capabilities include granular permission, check-in/check-out, version
“InRule has changed our control and change tracking for audit purposes
 Allows rules to be shared and reused
business… it’s the best
 Provides security levels to control access to rules and other elements
investment in software we’ve
made in a long time.” Integrate
 Delivered via an SDK with a full-featured API that allows calling
Development Manager,
applications to execute, interrogate, and respond to rule engine events
Canadian Insurance Company at run-time, so that developers can easily embed rule engine
functionality in their applications
 Provides a Services Oriented Architecture (SOA) option
 Should be designed and optimized for .NET for high performance and
easy integration (see next page)
Execute
 A rule engine provides run-time execution and logic, state management,
performance monitoring, and end-point interaction
 Allows rule applications to run in-process, via a web service or using a
message queue
Organizations using .NET as the primary development platform will want to

Leveraging Investments leverage their investments in Microsoft technologies and skills.
in Key Microsoft
Visual Studio
Technologies Developers should have the option to write and test rule-enabled code as well
as author, test, and maintain business rules directly within Visual Studio.
Allowing developers to work within the familiar Visual Studio environment to
set up authoring domains and to author, edit and manage rules shortens the
learning curve and streamlines the development of rule-enabled application
development.
Word
Subject matter experts at many organizations already use Microsoft Word to
“InRule is now the leading document business requirements and rules. Using a rule authoring tool
pure .NET choice” integrated with Word allows users to manage executable business rules directly
from within a familiar environment. This streamlines the transition from
From A Framework for Business
documenting requirements to executable logic and eliminates the need for
Rules Platform Selection,
separate requirements documents.
presented by Forrester analysts
at Business Rules Forum, Active Directory
November 2009. InRule was Importing Active Directory Users and Groups into the BRMS catalog simplifies
listed as one of the three the creation of user roles and groups. Once Users and Groups are imported, the
strongest BRMS options. administrator can assign roles and permissions to them.
BizTalk Server
A .NET BRMS should provide interoperability with a BizTalk Server
Orchestration, providing a way to call the rule engine directly or through the
use of static .NET Methods that return an XML document with rule results.
Windows Workflow Foundation

An out-of-the-box WF activity allows calls to the rule engine from a workflow by
dropping the activity onto the flow and setting its properties.
SharePoint
For many organizations, Microsoft SharePoint is a leading choice to manage
documents and document-centric, business processes. However, as
organizations look to deploy complex, decision-intensive processes using
SharePoint, they find that extensive customization of SharePoint is required.
Using a BRMS with a Business Process Management (BPM) tool built on top of
SharePoint significantly extends the power of SharePoint for advanced business
process management and business logic automation – without programming.
Exploiting the .NET Considerations

While supporting .NET simply means that application will run, exploiting .NET
Power of .NET means the application takes advantage of many .NET-specific capabilities that
can only be leveraged when the application is designed for a .NET environment
and built by .NET experts.
A BRMS that is designed, built, and optimized for .NET delivers many capabilities
that generic BRMS can’t (for example BRMS that were built on J2EE and ported
to .NET.)
.NET Classes, XSDs, and Databases – By harvesting schemas from existing .NET
In addition to support for
classes, XML Schemas and Database tables rather than re-creating them,
popular Microsoft tools such as
authoring takes less time and is more accurate.
Visual Studio and Word,
developers should consider .NET Generics - Advanced support for generic classes and methods, which
capabilities that support other combine reusability, type safety and efficiency in a way that their non-generic
.NET features counterparts cannot.
.NET Object Graphs – A BRMS should be able to execute against .NET object
graphs at run-time, acknowledging relationships among objects in the graph.
.NET Collections – Support for native .NET collections is important. For example,
a policy may contain a collection of borrowers, each of which contains
collections of assets and liabilities.
.NET Component Assemblies – The SDK should include a set of .NET assemblies
containing functionality that developers can easily embed within their own
applications. The SDK should require no additional tools to install, and enable
.NET developers to drop controls (such as decision tables and a language editor)
into .NET applications.
.NET DataSets. Organizations that have adopted .NET as their development

platform may have standardized on .NET DataSets, so a BRMS should operate
against these natively. Without this native support, additional code to manage
data must be written and maintained— resulting in significant overhead to
development resources and potentially slower performance.
.NET Events. A BRMS should expose events to consuming code using native .NET
Events. For example, a rule author may indicate that the rule engine should
raise a .NET event when certain conditions are met and pass data to the
application executing rules. This allows the developer to perform an application-
specific action when those conditions are met during rule execution.
Many organizations faced with building applications that can change quickly to
Summary accommodate the changing needs of a business are turning to BRMS to develop
dynamic and decisive business applications. These applications are built to
anticipate and easily accommodate change and deliver decisive results. The
strategies outlined in Section 1 provide a roadmap for developing these dynamic
applications.
Business Rule Management Systems (BRMS) deliver significant technical and

business value to application development efforts for organizations seeking to
develop dynamic, decisive business applications.
As .NET adoption grows, BRMS are increasingly being used to author and
update complex logic within core business applications implemented on a .NET
infrastructure.
With the right tooling and interface options, BRMS allow non-technical people,
such as subject matter experts, to update and manage changes to volatile
business decision logic. This frees IT professionals to focus on broader technical
and integration issues.
InRule, the premier .NET BRMS, provides all the capabilities needed to author
and test, store and manage, integrate and execute business rules for dynamic
business applications that deliver decisive results, while leveraging investments
in key Microsoft technologies.
About InRule Technology
About InRule Technology delivers InRule, the premier.NET solution for

authoring, managing and executing business rules. InRule helps
InRule Technology customers better manage and automate business decision logic without
expensive custom programming, delivering Business Logic Automation
and enabling organizations to respond quickly to rapidly changing
business requirements.
InRule supports a spectrum of business rule authors – from subject matter
experts to business analysts to developers – who can more easily write
sophisticated business rules and complex calculations. Improved Business
Decision Management results from an integrated approach to authoring,
storing, managing and executing rules.
With powerful rule management capabilities, a rich SDK, and the ability to
execute rules in process or as a service, InRule enables a flexible Enterprise
Logic Infrastructure, allowing business logic to be managed as an enterprise
asset and used consistently across multiple business processes, applications,
and platforms.
A Microsoft Gold Certified Partner and member of the Microsoft Business

Process Alliance, InRule Technology is committed to helping customers leverage
the power of .NET.
For more information, including white papers and a free trial download, visit
www.inrule.com.
InRule Technology
651 W. Washington
Suite 201
Chicago, IL 60661
312.648.1800
inrule.com

Strategies For Building: Inrule Technology 651 W. Washington Suite 500 Chicago, Il 60661 312.648.1800

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Strategies For Building: Inrule Technology 651 W. Washington Suite 500 Chicago, Il 60661 312.648.1800

Uploaded by

Copyright:

Available Formats

Strategies for Building

Dynamic .NET Applications

Table of Contents Topic Page

Section 1: Strategies for Dynamic Business Applications

Section 2: Overview of Business Rule Technology for .NET

About InRule Technology 19

Section 2 is intended for architects, development and project managers,

In addition Section 2 offers several important considerations for leveraging

Consider essential Simply rewriting applications is no longer good enough.

Following are five key strategies to consider:

KEY STRATEGIES SUMMARY

1. Understand Dynamic Business Applications &

Understand Dynamic Business Applications & Dynamic Decisioning

Dynamic Business Applications are built to support a rapidly changing business

Combine dynamic decisioning with Web services or a web-service like approach,

Determine project suitability for a Dynamic Rule Application

Strategy 3 Encourage the Joint Participation of IT and Business

Strategy 4 Isolate Rapidly Changing Logic with a Business Rule Management

The Essense of a BRMS

Consider a BRMS when

Strategy 5 Choose the Right Integration Approach for Your Needs

Following are examples of the most common implementation approaches for

In general all of the examples follow a similar pattern:

Integration Approaches Web Application with the Rule Engine In-process

Integration Approaches Exposing Rules as a Decision Service (i.e. Black Box)

Decision Service Centralized

Integration Approaches Rule Engine Execution Service

Integration Approaches Running Rules in the Field (i.e. Disconnected)

Typically with these types of applications there is synchronization functionality

Integration Approaches High-volume Data Processing

Execution Execution Execution Execution

Authoring, Managing, Integrating, and Executing Business Rules

Store and Manage

Organizations using .NET as the primary development platform will want to

Windows Workflow Foundation

Exploiting the .NET Considerations

.NET DataSets. Organizations that have adopted .NET as their development

Business Rule Management Systems (BRMS) deliver significant technical and

About InRule Technology delivers InRule, the premier.NET solution for

A Microsoft Gold Certified Partner and member of the Microsoft Business

You might also like