[bpel-dev] Minutes of call regarding BPEL validation

[Thomas Schulze <ThomasSchulze@xxxxxxxxxx>]

Hi guys,

last week Michal, James and I had a call regarding the validation of BPEL
processes. We (IBM) have proposed to contribute the initial starting point
for the validation based on the BPEL validation performed in IBM's
WebSphere Integration Developer.

As the initial contribution of the editor, the validation is already based
on the BPEL EMF model. Schema validation as well as "semantical" validation
is performed. Schema validation is the well known validation of the .bpel
file against one or more XSDs. Semantical validation performs additional
checks as defined by the BPEL specification. For example, not allowed
crossing links or cyclic links are detected.

The current Schema validation is performed against a "relaxed" XSD. Relaxed
means that it is not as strict as the original BPEL XSD.
The reason for this is the disability to connect validation markers
resulting from the Schema validation with objects on the canvas of the BPEL
editor. The markers resulting from the Schema validation only provide a
row/line information. This marker is only helpful when using a text editor,
XML editor or another kind of source editor. In the graphical BPEL editor
these markers can't be displayed in an meaningful way. Markers created by
the semantical validation can. Both, the editor and the semantical
validation are based on the same BPEL EMF model, therefore EMF markers are
used to identify the objects with which a marker have to be connected in
the editor.
For example, if the user adds with the BPEL editor a new sequence activity
to a process but does not put another activity into that sequence, this
will normally result in a marker from the Schema validation. Exactly this
is one of the places where the Schema have been relaxed to avoid a Schema
error. Instead the semantical validation checks this rule and is able to
create a meaningful marker for the graphical editor. This is very helpful
in cases where the user wants to save an incomplete process, for example if
wants to have a big cup of Java coffee ;-)

The current semantical validation performs about 400 checks. That are
checks to ensure references within the BPEL, to WSDL documents or to XSD
Schemas are valid and that are checks to ensure the rules defined by the
BPEL specification are not violated. The core of the semantical validation
is environment independent, means it can run within Eclipse or outside of
Eclipse in a J2SE environment (as well as the BPEL EMF model). Only some
code around the core is responsible for creating markers in the one case or
to throw an exception containing all found error messages in the other
case.
While the call, we have identified that this design makes it easy to
implement an "incremental" validation, or "validation on the fly". This
means the validation is performed not only when the BPEL is saved, it can
be separately called by the editor while the user is authoring a process,
for example, after an activity have been added. The editor may decide when
it runs the validation, validation will not create new markers for that
case, it will return the found problems i.e. in a list, and the editor will
be responsible to decide which errors will be marked as fixed (as we all
know it from the Java editor).

Additionally we have discussed about how to deal with BPEL extensions.
Processes are normally authored for a given target runtime which supports a
well-defined set of BPEL extensions. So, a serverType definition can
provide a list of supported extensions and an authored process must be
targeted for a known runtime. With this the BPEL editor and validation will
know which extensions are allowed for that process. This could include that
an extension specific or server specific validation may be performed
already while authoring a process not only when deploying it to a server.
Of course, this would put the requirement of full extensibility and full
control on the validation. For example if a server has different
implementation restrictions or extensions, the server specific validation
must be able to parameterize the standard validation accordingly. For
example, if a BPEL engine supports other expression languages than XPath
1.0 the standard validation must not forbid this, it should provide a
possibility to author and validate this at authoring time. Vice versa, if
an implementation supports only XPath 1.0 and the process contains
expressions written in another expression language, someone must detect
this, if possible while authoring the process, too.

Michal and James, in case I have forgotten another important point which we
have discussed, please add or correct me.

As said already, we have proposed to contribute this code as an initial
starting point. I've agreed to further maintain and enhance this code, but,
of course, anyone who wants to join me enhancing the BPEL validation is
welcome.

Guys, please let us know what you think about this proposal. Thanks in
advance!

Best regards/Mit freundlichen Grüßen,

       Thomas Schulze