Hi Philipp,
no, carrying out any quickfixes does not fall into the area of validation.
My understanding of validation is that it only analyzes the process and
does not modify it. Only the editor should modify the process, I think.
There's the question what to propose as quickfix and how to define that. In
the example, possible solutions would be to remove the sequence, or to add
an activity. Adding an activity can propose a list of activities, but
which? For example, rethrow and the two compensate activities are only
allowed at defined places. So, propose all activities or only a special
set? Providing all would potentially lead to other errors, providing only a
special set would require an additional analysis which activities are
allowed in this context. Providing such a quickfix functionality would be
very challenging, I think. Especially when keeping in mind that we have
currently about 400 different checks.
To support that, there would need to be an additional interface between
validation and editor which defines what the editor have to propose,
because only the validation knows the reason for the error. Only if you
know the reason you can provide possible fixes. That would be very
challenging, too.
In summary, I think we do not have the time to implement this cool feature.
But maybe we should add it to a feature function list.
What we can do very easily is to provide additional information about a
marker. Generally a marker message should be as short as possible. The
reason is the short problems view. As a first step instead of the quickfix
functionality, additional information about a marker would be very helpful
for the user. In detail, we have defined for each marker message an
explanation and an user action. For that, validation needs to save that
additional information in the marker object and the editor needs to be able
to display it. I think this is doable.
Of course, the target runtime of a process would not only be consumable by
the validation. The editor can use this information as well.
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
Philipp
Tiedt1/Germany/IB
M@IBMDE To
Sent by: bpel-dev@xxxxxxxxxxx
bpel-dev-bounces@ cc
eclipse.org
Subject
Re: [bpel-dev] Minutes of call
31.03.2006 12:02 regarding BPEL validation
Please respond to
"BPEL Designer
project developer
discussions."
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 To
bpel-dev@xxxxxxxxxxx
cc
31.03.2006 11:08
Subject
[bpel-dev] Minutes of call
Please respond to regarding BPEL validation
"BPEL Designer project developer
discussions."
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
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
