Author: objectiser Date: 2009-03-02 09:05:59 -0500 (Mon, 02 Mar 2009) New Revision: 531 Modified: cdl/trunk/docs/docbook/userguide/src/main/module/conversation-validation-with-cdl.xml Log: Minor fixes to the doc Modified: cdl/trunk/docs/docbook/userguide/src/main/module/conversation-validation-with-cdl.xml =================================================================== --- cdl/trunk/docs/docbook/userguide/src/main/module/conversation-validation-with-cdl.xml 2009-03-02 09:33:54 UTC (rev 530) +++ cdl/trunk/docs/docbook/userguide/src/main/module/conversation-validation-with-cdl.xml 2009-03-02 14:05:59 UTC (rev 531) @@ -92,7 +92,7 @@ </informalexample> <para> -The 'validator' element has an optional boolean attribute called 'mode', with the possible values of 'monitor' or 'manage'. If the +The 'validator' element has an optional attribute called 'mode', with the possible values of 'monitor' or 'manage'. If the mode is 'monitor' (which is the default), then any messages that result in validation errors being detected will continue to be received or sent, with the errors only be reported for information purposes. If the mode is 'manage', then any erronous messages detected during validation, that conflict with the behaviour as described in the choreography, will be prevented from being received or sent. </para> <note> @@ -105,7 +105,8 @@ The optional 'replyToTimeout' (defined in milliseconds) is used to determine how long a dynamic reply-to destination should be monitored for validation purposes. In some message exchanges, the response destination will not always be known in advance. Therefore the configuration can identify such situations, and monitor the reply-to destination for the response. However, if a response is not delivered in a particular time period, we need to be able to discontinue the validation of the dynamic endpoint. If this did not occur, then over time too many endpoints would be monitored, which may result in out-of-memory problems. The default timeout period is 10 seconds. </para> <para> -Within the 'validator' element is a list of 'service' elements, one per service being validated. The behaviour of the service being validated is identified by specifying the model (e.g. choreography description file) and the role (e.g. participant type) within the model. Therefore, within the above configuration, the first set of destinations (eprs) are associated with the <emphasis>LoanBrokerParticipant</emphasis> defined within the choreography description model found in the file <filename>models/TrailBlazer.cdm</filename>, which will be located within the <emphasis>overlord-cdl-validator.esb</emphasis> bundle. +Within the 'validator' element is a list of 'service' elements, one per service being validated. The behaviour of the service being validated is identified by specifying the model (e.g. choreography description file) and the role (e.g. participant type) within the model. Therefore, within the above configuration, the first set of destinations (eprs) are associated with the <emphasis>LoanBrokerParticipant</emphasis> defined within the choreography description model found in the file <filename>TrailBlazer.cdm</filename>, which will be located within the <filename>models</filename> folder contained within the +<emphasis>overlord-cdl-validator.esb</emphasis> bundle. </para> <para> The elements contained within the 'service' element define the <emphasis>input</emphasis> and <emphasis>output</emphasis> eprs (Endpoint References) that are associated with the service. The <emphasis>input</emphasis> eprs are the destinations on which messages will be received and the <emphasis>output</emphasis> eprs are the destinations on which messages will be sent by the service.