When creating a service contract you can specify the following options.

Decision Service name

The Decision Service name is used to identify a deployed Decision Service. By default, the name is the same as the Ruleflow used when the Decision Service was packaged into an EDS file. When deploying a Decision Service you can override this by specifying a different name.

Once deployed, the Decision Service will always be known, referenced and invoked in runtime by its name. Decision Service Names must be unique, although multiple versions of the same Decision Service Name may be deployed and invoked simultaneously. See Versioning for more details.

What type? WSDL or XSD?

  • Web Services Description Language (WSDL) - A WSDL service contract differs from the XSD in that it defines both invocation payload and protocol. It is the easiest as well as the most common way to integrate with a SOAP Web Services Server. The WSDL file defines a complete interface, including SOAP binding parameters, the Decision Service name, the payload (XML data elements required inside the request message), XML data elements provided within the response message. For more information on WSDL, see https://www.w3schools.com/xml/xml_wsdl.asp

    Important: The Web Services standard allows for two messaging styles between services and their callers: RPC-style and Document-style. Document-style ( also called Message-style) interactions are more suitable for Decision Service invocations because of the richness and (potential) complexity common in business. RPC-style interactions are more suitable for simple services that require a fixed parameter list and return a single result. Corticon Decision Service WSDLs are always Document-style! If you intend to use a commercially available software toolset to import WSDL documents and generate request messages, be sure the toolset contains support for Document-style WSDLs.

  • XML Schema (XSD) - The purpose of an XML Schema is to define the legal or valid structure of an XML document. This XML document will carry the data required by Corticon Server to execute a specified Decision Service. The XML document described by an XSD is the payload (the data and structure of that data) of a SOAP call to the Corticon Server or may also be used as the payload of a Java API call or invocation.

    XSD, by itself, is only a method for describing payload structure and contents. It is not a protocol that describes how a client or consumer goes about invoking a Decision Service; instead, it describes what the data inside that request must look like. For more information on XML Schemas, see https://www.w3schools.com/xml/schema_intro.asp

What level? Vocabulary or Decision Service?

  • Vocabulary - Often, the same payload structure flows through many decision steps in a business process. While any given Decision Service might use only a fraction of the payload's content (and therefore have a more efficient invocation), it is sometimes convenient to create a single master service contract from the Decision Service's Vocabulary. That simplifies the task of integrating the Decision Services into the business process because a request message conforming to the master service contract can be used to invoke all Decision Services that are built with that Vocabulary. This master service contract is referred to as Vocabulary Level.
  • Decision Service - The issue with a Vocabulary-level service contract is its size. Any request message generated from a Vocabulary-level service contract will contain the XML structure for every term in the Vocabulary, even if a given Decision Service only requires a small fraction of that structure. Use of a Vocabulary-level service contract therefore introduces extra overhead because request messages generated from it may be unnecessarily large. In an application or process where performance is a higher priority than integration flexibility, using a Decision Service Level service contract is more appropriate. A Decision Service-level service contract contains the bare minimum structure necessary to call that specific Decision Service – no more, no less. A request message generated from this service contract will be the most compact possible, resulting in less network overhead and better overall system performance. But it may not be reusable for other Decision Services.

Which messaging style? Flat or hierarchical?

There are two structural styles the payload can take. Flat payloads have every entity instance at the top, or root, level with all associations represented by reference. Hierarchical payloads represent associations with child entity instances indented within the parent entity structure.

  • FLAT - Entity names start with an upper-case character, associations are represented by href tags, and role names are in lowercase initial characters.
  • HIER - Hierarchical style, an embedded entity is identified by the role name representing that nested relationship (again, starting with a lowercase letter). Role names are defined in the Vocabulary.

SOAP Server URL

The URL for the SOAP node that is bound to the Corticon Server is the SOAP Server URL. It is enabled only for WSDL service contracts. The default URL, http://localhost:8850/axis/services/Corticon, makes a Decision Service available to the Corticon Server's application server. This Deployment property's default value can be overridden in your brms.properties file as com.corticon.deployment.soapbindingurl_1.

Platform: Java or IIS?

Editing one line in a generated WSDL can make it conform to what IIS expects. Locate the line: 
 <xsd:attribute name="decisionServiceName"> use="required"   type="xsd:string" />
Replace it with the line:
<CorticonRequest> <DecisionServiceName>"decisionServiceName"</DecisionService>
Note: Your client SOAP UI might make it a good idea to review Properties that tune service contract output and Extended service contracts: newOrModified.