Integrating Corticon Into Your Application

Progress Corticon provides tremendous flexibility in how you choose to implement your Business Rules Management System (BRMS). Read on as Prashant Thumma guides you through the benefits of each option.

I am a Software Architect who has worked on many enterprise products and frameworks. In each, I had to integrate, work with or orchestrate other third party solutions. It’s a rare luxury to work on a totally new project where you get to make all the design decisions. More likely, you’ll have to work with existing applications to fix or enhance them to solve new business needs.

When integrating solutions you often have to live with decisions made a while ago or have time constraints that prevent altering architectures. In all cases there are choices to be made, and you have to be aware of the benefits and the trade offs of each option.

BRMS solutions make the management of complex rules… manageable! You don’t build a complete application using a BRMS solution. Instead, you integrate it or orchestrate it within your application. Progress Corticon is designed to provide flexible deployment options.

Corticon can be deployed as a part of both Java and .NET solutions, and is built to work in the following environments:

• SOAP Web Services
• REST Web Services
• Embedded deployments
• J2EE Java Services

To help you determine which environment you may want to work with, let’s look a little more closely at each one.

SOAP WebServices

This is the most common deployment model used by Corticon customers. It allows Corticon to participate in deployments that leverage standards based Service Oriented Architecture. The SOAP deployment option has these characteristics:

• Standards based—The Corticon invocation interface is defined by a SOAP 1.2 API. The payload that is passed into the invocation call is an XML document that is well defined by a XSD. The XSD is specific to the decision service and allows the payload to be validated. The XML handling overhead is typically the most time consuming part of the decision service invocation. In a latency sensitive deployment, it might be better to leverage the Corticon REST interface.
• Interoperable model—Although Corticon provides a Java and a .NET SOAP implementations, the platform used to invoke the decision service need not be limited to these platforms. The decoupled nature of the deployment allows you to mix different platforms including, but not limited to, Node.js, Grails, Play, Ruby on Rails, etc.
• Independently Scalable—The decoupled nature allows you to independently scale the different parts of your application. For rules heavy applications you might need to scale the Corticon parts of the deployment while leaving the rest of your application intact. It also could be the other way around where your application needs to be scaled out, but your decision service invocations are just fine.
• Choice of Deployment containers—The Corticon Java implementation can be deployed to most J2EE web containers including Apache Tomcat, IBM WebSphere, Oracle WebLogic and JBoss. The Corticon .NET implementation can be deployed to IIS. The choice of containers allows you to leverage your existing infrastructure to deploy Corticon.

REST WebServices

REST API for decision service invocation is fairly new to Corticon, but it might quickly overtake the SOAP interface in new deployments. The REST API shares most of the benefits of the SOAP because of the decoupled nature of the architecture. The differences are:

• REST API with JSON—The Corticon REST invocation API is quite straight forward and follows the typical REST API conventions. The JSON object model for the payload is documented in the Request and Response examples section of the Corticon documentation. This custom JSON object model allows Corticon to map the payload to the rules vocabulary quickly. It provides facilities to model associations in the JSON, allowing you to minimize the replicated data that need to be transmitted.
• Faster than SOAP—JSON handing is just faster than XML handing. The underlying decision service invocation is shared by the SOAP and REST, but the data marshaling difference between XML and JSON is large. We have seen instances where JSON handling is an order of magnitude faster than XML!

Embedded Deployments

Corticon, at its core, is just a library with a defined API. This library can be embedded into an application just as you would any third-party library. For Java it is provided as a few JAR files and for .NET it is provided as DLL assemblies. This deployment has the following characteristics:

• Controlled lifecycle—Corticon is embedded as part of your application, and as such you control the lifecycle of the Corticon server.
•  Lightweight—This deployment model has no wrapper that adds overhead to invoke a decision service.
•  Direct object mapping—This deployment model allows you to invoke a decision service with your application data objects as the payload. This completely removes the overhead of any data marshaling!
•  Flexible—Since there is no requirement for a standard web container, you have the flexibility to incorporate Corticon into any architecture.  Examples of this are:
  •  Embed it in a standalone desktop or mobile application
  •  Create a decision service endpoint on a message bus
  •  Incorporate rules capability in distributed IoT framework
  •  Deploy as a bean in an application that leverages Spring Framework

J2EE Java Services

Corticon is also available as a J2EE Stateless Session bean (EJB) that allows you to orchestrate Corticon as part of an application that leverages the full J2EE stack. This model allows you to invoke decision services via Java Messaging Service (JMS) or Remote Method Invocation (RMI). This is the least used option as most developers prefer the lighter weight alternatives.

The Choice is Yours

Corticon provides a lot of flexibility to incorporate rules capabilities into your application. The model you use and the trade offs you make is your choice!