Service Orchestration Functional Specification - Validation (Design
$Revision: 1.2 $
$Date: 2009/11/02 14:12:36 $
This functional specification will give details on the Validation feature for the BPEL Project. The Validation features' primary objective is to aid the developer while he is designing business processes in BPEL. It will assist the user via multiple sources such as the designer, source editor, navigator, project tree, properties window, Tasks/Suggestions window, output window. Some forms in which the validation can be shown are:
* Showing a list of errors in the BPEL or associated files.
* Providing visual annotations on the elements in the designer and navigator.
Validator: This is a component which can analyse the artifacts in the project (.bpel and the associated .wsdl and .xsd) and generate a list of suggestions, errors, tips etc.,
Validation Info Consumer: This is a component which can utilize the information provided by a Validator and display it in some form. This will be referred to as Consumer.
This feature will be implemented so that multiple providers and consumers can be plugged-in.
The Design Guidance system will make use of a module validation approach. This will allow multiple validators to be employed. Each validator will be responsible for validating specfic aspects of the BPEL process. This is really an implementation detail and end users will not need to understand this architecture. From the user perspective validation is a single atomic feature. They need not be aware that it is implemented as a collection of validation routines. However, users should be aware of the "range" of validation that will be undertaken. That is to say, they should be aware of "what" is being validated, even if they do not need to be aware of the "how" it is being done.
Validators analyse the BPEL file and related artifacts and come up with errors, warnings, suggestions etc., These validators themselves can be either fast in executing (in which case we can get validation results as the user designs) and some providers can be slow (in which case the validation results will be available only periodically / explicit user action). In all cases the validation results from all validators will be made available to consumers. Each consumer can only show the result that makes sense in its context.
Each validator will be responsible for enforcing a specific set of "rules" and will report violations of the rules in specific messages. Where possible these rules and messages will be fully documented in this or accompanying documents.
Here are the planned validators.
Not supported by BPEL Runtime Validator
This validator will check the BPEL process for usages of BPEL language constructs which are valid according to the BPEL 2.0 specification, but are not yet supported by the Sun BPEL SE.
This document BPEL_SE_wsbpel_main.xml is a version of the BPEL 2.0 xsd that has certain parts of the schema commented out. The commented out sections are those parts of the BPEL language which will not be supported by the Sun BPEL SE in its first release. The commented out sections therefore represent the "unsupported by runtime" language constructs.
BPLE Static Analysis Validator
This validator will check the BPEL process for violations of the 90 plus rules provided by the BPEL specification static analysis document.
This document Static Analysis Requirement is a modified copy of the static analysis rules provided by the BPEL 2.0 specification. The document has been modified to include the error messages that the BPEL Module wll generate for each rule violation. This is necessary because the BPEL specification only specifies the rules, it does not specify the rule violation messages.
BPEL XML Valdiator
This validator will simply invoke the standard XML Schema validation utility which will then validate the BPEL process to make sure it is accordance with the BPEL 2.0 xsd. The standard schema validation reports errors only in terms of source code line numbers, therefore. there will be an additional task required by our validator to parse the response from schema validator and turn it into a collection of ResultItems so that they can be mapped to the BPEL process elements.
This is wsbpel_2_0.xsd the version of the BPEL 2.0 xsd that was available at the time the BPEL Module was implemented. Since the BPEL 2.0 specifcation is still not final, this xsd may change. This version is the version that the BPEL Module will use to peform schema validation.
Messages - This functional specificaction cannot list all of the messages that may be generated by the XML Schema validation utility. That utility is not implemented by us. The BPEL Schema Validator will simply invoke this utility and present the messages returned from this utility to the users. These messages will be familiar to all users that have run the Validate XML action in NetBeans or any other tool that invokes the standard XML validation utility.
BPEL Broken Reference Validator
This validator will check the BPEL process for the presence of any broken references. This validator will detect "simple" broken references but will not detect potentially broken reference usage internal to XPath expressions. "Simple" broken references, refers to references which are formalized in the object model. For instance the "input variable" property of an Invoke element will be a refernce to a BPEL variable. That is a simple reference.
Rules Broken Reference Rules.
BPEL Semantic Validator
The Semantic Validator will add "extra validation" not covered by other valdiators listed in this document.
This document SemanticValidationRules.html contains both the rules and the messages.
Fast versus Slow Validators
Validators can perform the task in two ways:
Fast (Only validates the current document ).
- This will be invoked as the user designs the diagram.
- Used to show badges on the BPEL designer.
- This will be executed automatically. The user does not have
invoke it explicitly.
Slow (recursively validates all imported wsdl/schema
- This will be invoked by a user action and can take a few seconds
- Output will be shown in the Output window (similar to results of java compilation).
- Hyperlinks from the output window can be used to open the source editor for the file.
- This will validate all imported Schema and WSDL files.
Validation Information Consumers
Validation consumers accept the validation results and display it to the user. The consumers could be:
- Output Window
2. Technical details
Fast vs Slow validation Issues
For the fast Validator.
There will be a Controller which will overlook the entire
vdalidation information process. It will be coordinating activities
between the validators, the BPEL object model and the consumers. It
will work in the following way:
(a) The controller will have a reference
to the BPEL OM.
(b) The controller will receive events whenever the BPEL OM changes.
(c) Based on the type of event from the BPEL_OM, the controller will invoke a method on the validator passing a reference to the BPEL_OM.
(d) The controller will notify all registed clients when this validation information changes.
3.a Use Cases: Output Window
Results will be displayed here only on an explicit action such as 'Validate' which will call the 'Slow' validator defined above. This will display results like a compiler does with line numbers, hyperlinks to the line in the source editor etc., Since this will validate the BPEL and all imported WSDL and Schema files, the user can expect error message from the WSDL and Schema files also.
This will be the same validator that will be called when 'Compile'
action is performed.
3.b Use Cases: Designer
As the user works in the designer, navigator, modifies properties in the property sheet, the designer will be updating annotations on its elements.
The annotation icon could be 'Error', 'Warning', 'Suggestion'.
The annotation will be updated every few seconds. (Like the java editor which displays error information a few seconds after the user stops typing).
3.c Use Cases: Navigator
The navigator node tree can be used to annotate validation
information by badging.
3.d Use Cases: Problems List
This will display results in a table similar to the ToDo window in Netbeans. This list will be updated periodically as the user designs the BPEL process.
| Message Type | Message | File name |
| | | |
Each row in the table will act as a hyerlink to select the line if the source editor is open or the element in the designer.
3.e Use Cases: Source editor
The error stripes and editor annotations in the margin can
be used to display validation information. Mouse over on the
annotation can display the assoicated message.
3.f Use Cases: Project tree
The project tree can follow the Netbeans convention
of badging nodes in case there is any error associated with it.
3.g Use Cases: Properties
All the property editors can utilize this validation
information to appropriately badge incorrect properties.
3.h Use Cases: Suggestions framework
This framework assists the user in fixing the error itself
in addition to displaying it to the user. This will again show up
in the editor / designer with a 'bulb' icon and a right click will
present different actions available to fix the error/warning.
4. Implementation schedule
In Netbeans Enterprise Pack Beta timeframe, the
following clients will be implemented.
- Output Window. (UC 3.a)
- Design Editor. (UC 3.b)
- Navigator (possibly?) (UC 3.c)
In Netbeans Enterprise Pack Beta timeframe, the following
validators will be implemented. These are descibed above.
- BPEL Runtime not supported Validator
- BPLE Static Analysis Validator
- BPEL Schema Valdiator
- BPEL Broken Reference Validator
- BPEL Semantic Validator
If there is a warning, suggestion or error message related to an element on the diagram, an error toggle button shows up. The toggle button behaves as a real toggle button in Swing toolbar; it reacts on mouse over (visual feedback) and mouse press (besides visual feedbaci a cal out pop out). When it is toggled on, validation call out pops up; the visibility of the entire call out is assured. The call out can be dismissed by toggling the button off, or by bringing up a different call out. It also disappears when a different element on the diagram is selected.
The following mock up shows how the call out is attached to the
diagram, the actual visual appearance of the callout internals is
depicted on the next figure.
Figure - Validation call out mockup
Figure - Actual visual appearance of the callout internals
The call out details are described in the following table. The internals of the call out were delivered in a zip file (issue #81468).