skip to main content
Corticon Server: Integration & Deployment Guide : Introduction to Corticon Server deployment : Choose the deployment architecture
 

Try Corticon Now

Choose the deployment architecture

Corticon Decision Services are intended to function as part of a service-oriented architecture. Each Decision Service automates a discrete decision-making activity – an activity defined by business rules and managed by business analysts.
Important: A Corticon Ruleflow deployed to the Corticon Server and available to process transactions is referred to as a Decision Service. Rulesheets are not directly deployable to Corticon Server. They must be packaged as Ruleflows in order to be deployed and executed on Corticon Server.
The application architect must consider how these Decision Services will be used (consumed) by external applications, clients, processes or components. Which applications need to consume Decision Services and how will they invoke them? Your choice of installation and deployment architecture impacts subsequent steps, including installation of Corticon Server, and integration and invocation of the individual Decision Services deployed to Corticon Server.
The primary available options are described in the following table, and addressed in detail below:
Table 16. Table: Corticon Server Installation Options
Installation Option
Description
Appropriate If:
1 - Web Services
Corticon Server is deployed with a Servlet interface, causing individual Ruleflows to act as Web Services. Invocations to Corticon Server are made using standard SOAP requests, and data is transferred within the SOAP request as an XML payload.
*Currently using Web Services.
*Need to expose Decision Services to the Internet or other distributed architecture.
*Using Microsoft .NET or other legacy systems which do not support Java method calls (invocations).
2 - Java Services with XML Payloads
Corticon Server is deployed with an Enterprise Java Bean (EJB) interface and integrated with architectures that can make Java method calls and transfer XML payloads.
*Prefer to use XML for best flexibility in data payload.
*Prefer JMS or RMI method calls for high performance and/or tighter coupling to client applications.
3 - Java Services with Java Object Payloads
Corticon Server is deployed with an Enterprise Java Bean (EJB) interface and integrated with architectures that can make Java method calls and transfer Java object payloads.
*Prefer Java objects for data payload.
*Prefer JMS or RMI method calls for high performance.
*Willing to accept decreased portability
4 - In-process Java Classes (POJO)
Corticon Server is deployed into a client-managed JVM as Java classes
*Require lightest-weight, smallest-footprint install.
*Prefer direct, in-process method calls for lowest messaging overhead and fastest performance
Table 17. Table: Corticon Server Communication Options
Server Installed As…
Call Server With…
Send Data As…
Java Servlet
*SOAP: RPC or Document-style
*XML String (RPC-style)
*XML Document (Document-style)
Java Session EJB
*Corticon Server API via JMS
*Corticon Server API via RMI
*XML String or JDOM
*collection or map of Java Business Objects
Java Classes
*in-process Java methods from the Corticon Server API
*XML String or JDOM
*collection or map of Java Business Objects
* Installation option 1: Web services
* Installation option 2: Java services with XML message payloads
* Installation option 3: Java services with Java object payloads
* Installation option 4: In-process Java classes with Java object, XML, or JSON payloads