Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [bpel-dev] Minutes of call regarding BPEL validation


Hi Thomas,

speaking of validation and markers what is the storry of quickfixes. Picking up your sample of creating an empty Sequence activity, the validation would produce a marker. It would be really cool if we suggest possible fixes for the problem that are carried out automatically if the user doubleclicks. E.g. deleting the sequence or insert an empty activity (or whatever makes sense to suggest :-) ). Does this fall into the area of validation as well or is this another thread?

I like the idea of targeting an authored process to a known runtime. To kick it up a notch, would it make sense to not only make the validation based on the runtime but also certain points of the UI. E.g. if I want to provide tooling for a new kind of activity that is only supported by a certain runtime. Would it make sense to only show this tooling (palette entries, categories, property sections) if the process is targeted to the runtime?

Mit freundlichen Grüßen / Best regards
- Philipp Tiedt
_____________________________________
Software Engineer II4BPEL
Information Management
IBM Deutschland Entwicklung GmbH
Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49 (0) 7031-16-2786

Mail: philipp_tiedt@xxxxxxxxxx
Blog: http://philipptiedt.blogspot.com

"Throughout the centuries there were men who took first steps down new roads armed with nothing but their own vision"           -- Ayn Rand
                                                                                                     



Thomas Schulze/Germany/IBM@IBMDE
Sent by: bpel-dev-bounces@xxxxxxxxxxx

31.03.2006 11:08

Please respond to
"BPEL Designer project developer discussions."

To
bpel-dev@xxxxxxxxxxx
cc
Subject
[bpel-dev] Minutes of call regarding BPEL validation





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

_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev


Back to the top