When you deploy Corticon Server in a Java application, you call it with a Java payload -- XML, JSON, or business objects. For more information see Java application requirements topic.

The specific method used to invoke a Decision Service is the execute() method. The method offers a choice of arguments:

  • An XML string, or an XML JDOM document, which contains the Decision Service Name as well as the payload data. The payload data must be structured according to the XSD in Corticon Studio. Defining this data payload structure to include as an argument to the execute method is the most common use of the XSD service contract.
  • A JSON object which contains the Decision Service Name as well as the payload data.
  • The Decision Service Name plus a collection of Java business objects which represent the WorkDocuments.
  • The Decision Service Name plus a map of Java business objects which represent the WorkDocuments.

Optional arguments representing Decision Service Version and Effective Timestamp may also be included – these are described in the topic Ruleflow versions and effective dates .

All variations of the execute() method are described fully in the JavaDoc.

Java Business Objects

For example, in Tutorial: Basic Rule Modeling, the three Vocabulary entities: FlightPlan, Cargo, Aircraft would be represented by the caller as three Java classes. Each class would have properties corresponding to the Vocabulary entity attributes (for example, volume, weight). The association between Cargo and FlightPlan would be handled by Java class properties containing object references; the same would be true for the association between Aircraft and FlightPlan.

Note that even if there is only a one-way reference between two classes participating in an association (from FlightPlan to Cargo, for example), if the association is defined as bidirectional in the Vocabulary, rules may be written to traverse the association in either direction. Bidirectionality is asserted by Corticon Server even if the Java association is unidirectional (as most are, due to inherent synchronization challenges with bidirectional associations in Java objects).

Certain hard-coded classes are included in CcServer.jar so as to ensure their inclusion on the JVM's classpath whenever CcServer.jar is loaded. The hard-coded Java objects are intended for use when invoking the ProcessOrder.eds Decision Service included in the default installation.