The work for SWITCHYARD-1180 introduces configuration changes for the BPM & Rules Components.  The configuration changes have been made for these reasons:

1. To support the new way Drools & jBPM 6 gets configured/bootstrapped.  Specifically, the new KIE API module/container methodology.
2. To be able to choose/delineate between #1 and the existing configuration mechanism.  Specifically, the exisiting Drools & jBPM 5 builder/resource addition method.  This is for backwards compatibility, and there until we're sure which direction we want to take.
3. To still support those configuration options that still work with either method.
4. To homogenize the configuration between the BPM & Rules Components for ease of use by developers, which also means code-sharing within each components on the SwitchYard side, as well as possible code-sharing within the SwitchYard tooling.

Old Configuration

Here is an example old Rules configuration:

<implementation.rules xmlns="urn:switchyard-component-rules:config:1.0" agent="true" clock="PSEUDO" eventProcessing="STREAM" maxThreads="10" multithreadEvaluation="true">
    <action name="processFoo" type="EXECUTE"/>
    <action name="processMan" type="FIRE_ALL_RULES"/>
    <action name="processBar" type="FIRE_UNTIL_HALT" entryPoint="bars"/>
    <audit interval="2000" log="foobar" type="CONSOLE"/>
    <eventListener class="org.kie.event.rule.DebugWorkingMemoryEventListener"/>
    <channel class="org.switchyard.component.rules.config.model.RulesModelTests$TestChannel" input="theInput" name="theName" operation="theOperation" reference="theReference"/>
    <resource location="foo.dsl" type="DSL"/>
    <resource location="bar.dslr" type="DSLR"/>
    <globals>
        <mapping expression="message.content" variable="payload"/>
    </globals>
    <facts>
        <mapping expression="context['foobar']"/>
    </facts>
</implementation.rules>

Here is an example old BPM configuration:

<implementation.bpm xmlns="urn:switchyard-component-bpm:config:1.0" processDefinition="foobar.bpmn" processDefinitionType="BPMN2" processId="foobar" persistent="true" sessionId="3">
    <eventListener class="org.drools.event.DebugProcessEventListener"/>
    <taskHandler class="org.switchyard.component.bpm.task.work.SwitchYardServiceTaskHandler"/>
    <resource location="foobar.drl" type="DRL"/>
    <parameters>
        <mapping expression="message.content" variable="payload"/>
    </parameters>
    <results>
        <mapping expression="message.content = payload;"/>
    </results>
</implementation.bpm>

New Configuration

Here is an example new Rules configuration:

<implementation.rules xmlns="urn:switchyard-component-rules:config:1.0">
    <actions>
        <action id="anID" operation="process" type="FIRE_ALL_RULES">
            <globals>
                <mapping expression="context['foobar']" scope="EXCHANGE" variable="exchangeVar"/>
            </globals>
            <inputs>
                <mapping expression="message.content.nested" variable="contentIn"/>
            </inputs>
            <outputs>
                <mapping expression="message.content" variable="contentOut"/>
            </outputs>
        </action>
    </actions>
    <channels>
        <channel class="org.switchyard.component.rules.config.model.RulesModelTests$TestChannel" name="theName" operation="theOperation" reference="theReference"/>
    </channels>
    <listeners>
        <listener class="org.kie.event.rule.DebugWorkingMemoryEventListener"/>
    </listeners>
    <loggers>
        <logger interval="2000" log="theLog" type="CONSOLE"/>
    </loggers>
    <manifest>
        <resources>
            <resource location="foo.drl" type="DRL"/>
            <resource location="bar.dsl" type="DSL"/>
        </resources>
    </manifest>
    <properties>
        <property name="foo" value="bar"/>
    </properties>
</implementation.rules>

        <!-- the resources element above can be replaced with a container element like below; it is an xsd choice between the two: -->
        <container baseName="theBase" releaseId="theGroupId:theArtifactId:theVersion" scan="true" scanInterval="60000" sessionName="theSession"/>

Here is an example new BPM configuration:

<implementation.bpm xmlns="urn:switchyard-component-bpm:config:1.0" persistent="true" processId="Foobar" sessionId="42">
    <actions>
        <action id="anID" operation="process" type="START_PROCESS">
            <globals>
                <mapping expression="context['foobar']" scope="EXCHANGE" variable="exchangeVar"/>
            </globals>
            <inputs>
                <mapping expression="message.content.nested" variable="contentIn"/>
            </inputs>
            <outputs>
                <mapping expression="message.content" variable="contentOut"/>
            </outputs>
        </action>
    </actions>
    <channels>
        <channel class="org.switchyard.component.bpm.config.model.BPMModelTests$TestChannel" name="theName" operation="theOperation" reference="theReference"/>
    </channels>
    <listeners>
        <listener class="org.drools.event.DebugProcessEventListener"/>
    </listeners>
    <loggers>
        <logger interval="2000" log="theLog" type="CONSOLE"/>
    </loggers>
    <manifest>
        <resources>
            <resource location="foobar.bpmn" type="BPMN2"/>
        </resources>
    </manifest>
    <properties>
        <property name="foo" value="bar"/>
    </properties>
    <workItemHandlers>
        <workItemHandler class="org.switchyard.component.bpm.config.model.BPMModelTests$TestWorkItemHandler" name="MyWIH"/>
    </workItemHandlers>
</implementation.bpm>

        <!-- the resources element above can be replaced with a container element like below; it is an xsd choice between the two: -->
        <container baseName="theBase" releaseId="theGroupId:theArtifactId:theVersion" scan="true" scanInterval="60000" sessionName="theSession"/>

As you can see, in the new configurations, the BPM component is exactly the same as the Rules component, except with some additional attributes and elements, and different possible values for the action type.  These are all enforced via XSD.

Notable Configuration Changes

1. <eventListener>s are now <listener>s and live inside a <listeners>.
2. <channel>s now live inside a <channels>.
3. <taskHandler>s are new <workItemHandler>s and live inside a <workItemHandlers>.
4. <resource>s now live inside a <resources>, which are only applicable within a <manifest>.
5. agent="true|false" is now on the <container> and renamed to scan="true|false".  Only <container> resource scanning is supported by KIE/Drools/jBPM from now on.  There is also a scanInterval="long" attribute on <container>.  Default is 60000 (60,000 milliseconds, or 1 minute).
6. Things like clock="", eventProcessing="", and other drools properties are now specified via their actual <property>s contained inside a <properties>.
7. <audit> is renamed to <logger> and contained within a <loggers>.
8. <action>s are now contained within an <actions>, each being able to contain <globals>, <inputs> and/or <outputs>.
9. Each <action> specifies an operation="" attribute, which is associated with the interface operation (method).
10. Each of the mapping elements (<globals>, <inputs>, <outputs>) can contain any number of <mapping>s, which haven't changed.
11. The old rules <facts> is now <inputs>.  (If using rules entry points, the variable attribute can be used to name the entryPoint.)
12. The old bpm <parameters> is now <inputs>.
13. The old bpm <results> is now <outputs>.  (Can you say "homogenization"?)
14. The <implementation.bpm> element's processDefinition and processDefinitionType attributes are gone. The process definition now is listed as a <resource location="" type=""/> just like everything else.
15. The <implementation.bpm> element's messageContentIn/Out attributes are gone.  Use <mapping>s like everything else.
16. There is a new rules action type: INSERT.  This will insert rules into a stateful session, but won't fire the rules.

Implementation Notes

1. The implementation you specify in <workItemHandler class="the.Implementation"/> is required to implement org.kie.runtime.process.WorkItemHandler.
2. The implementation you specify in <channel class="the.Implementation"/> is required to implement org.kie.runtime.Channel.
3. The implementation you specify in <listener class="the.Implementation"/> is required to implemement java.util.EventListener.