There are two approaches that can be used to validate artifacts.
For certain artifact types, that represent either global (e.g. Choreography) or local (e.g. Process) behaviour, a protocol definition can be derived that expresses the externally observable behaviour.
This behaviour can then be validated to determine certain properties. Currently only a limited set of validation rules are provided, but these will be extended in future versions.
To enable this type of validation, it is necessary to explicitly set a property on the Eclipse resource. This can be achieved by selecting the Properties menu item associated with the resource, and accessing the Savara->Validation node:
When enabled, the validation will place any errors or warnings detected in the Problems view. When a problem (error/warning) is selected, it will open the appropriate editor and focus on the element that is associated with the problem.
Where a simulator exists associated with the service implementation technology, it is possible to replay the message events defined within a scenario against an executing version of the service implementation, to ensure that a real service instance handles the scenario correctly.
For example, a scenario can be simulated against a SCA composite definition. (Switchyard services will be supported in the near future).
This type of validation not only ensures the externally observable behaviour is correct, but also validates the internal service logic.
For choreographies, service designs (which have no executable semantics), or implementations where no simulator exists that can perform dynamic verification, it may be possible to simulate valid behavior (as defined by a set of scenarios) against the protocol derived from the choreography/service design/implementation.
This ensures that the choreography handles the business requirements outlined in the scenarios, and ensures the service design and/or implementation has the correct communications structure to be able to interact with other services (whether consumers or other producers).
For example, a scenario can be simulated against a BPEL process definition (and in the near future a BPMN2 process model) to determine whether they have the correct communication structure, even before they contain enough details to be executed.
Although not currently supported, the longer term goal will be to perform conformance checking between related artifacts that are based on behaviour. For example a Choreography can be conformance checked against a Process Model representing one of its roles, to determine whether it has compatible behaviour.