[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [bpel-dev] Minutes of call regarding BPEL validation
|
Hi Bruno,
I think too, that it would be cool to have some technology where we could
be able to offer 'write once, run anywhere'. But I think this won't be
possible in all cases.
I would expect that it should be able for a user to have multiple runtimes
available. But I expect to, that these two runtimes may support different
(mustUnderstand) extensions. If we allow in the designer to author a
process containing both extensions, the process wouldn't be deployable on
both of the runtimes. Not very useable, I think.
Only in case I have two runtimes installed which support the same set of
extensions I would not need to care about that.
Even when thinking about standard BPEL (no extensions) it is possible that
one process can be run by one runtime, but not by another. Recently,
correlationSets have been made optional by the BPEL TC. This means a
process with multiple inbound activities will not be forced to use
correlationSets any longer. A target runtime may provide another
functionality to correlate an inbound message with a particular instance.
In reality this means we will have a set of processes, the one without
correlationSets, which can't be deployed on every runtime. Even without
extensions! I don't know how to address this in a tooling designed for
multiple runtimes.
Maybe it is possible to target a process not only for one runtime. Maybe it
would be cool to give the user the possibility to say: "I want to author a
process which is able to run on runtime A, B and C." Because of the
information which extensions are supported by which runtime (and maybe we
can handle the correlationSet issue equally) we can decide which extensions
to offer in the editor - only those which are supported by all target
runtimes. I think in the most cases this would be standard BPEL only, with
correlationSets.
Additionally we should keep in mind, that there might be runtimes which do
not fully support BPEL. For example a runtime might support only WSDL-types
variables. This would add additional restrictions for portability.
Best regards/Mit freundlichen Grüßen,
Thomas Schulze
Bruno Wassermann
<B.Wassermann@cs.
ucl.ac.uk> To
Sent by: "'BPEL Designer project developer
bpel-dev-bounces@ discussions.'"
eclipse.org <bpel-dev@xxxxxxxxxxx>
cc
31.03.2006 13:41 Subject
RE: [bpel-dev] Minutes of call
regarding BPEL validation
Please respond to
"B.Wassermann"
and "BPEL
Designer project
developer
discussions."
Hi guys,
Just a few thoughts on targeting a particular runtime at process modeling
time.
Is it okay to expect a user to specify the target runtime at process
modeling time (i.e. before thinking about deployment) or would this
introduce some usability issue?
Should a user be free to choose the vocabulary/constructs that best suits
her modeling needs and then think about which runtime to employ or is this
unrealistic (i.e. should we expect a user to only have one particular
runtime available and should therefore provide support, during modeling,
for valid processes for this particular runtime).
However, if we don’t ask for a target runtime, we wouldn’t know which tools
to offer in palette and which ones to hide. Then again, we mentioned in the
runtime extension thread that there will be runtime-specific validation and
feedback to the user at deployment time.
It would be really cool to have some technology where we offer ‘write once,
run anywhere’ without users having to reason about portability issues.
Regards,
-- Bruno
From: bpel-dev-bounces@xxxxxxxxxxx [mailto:bpel-dev-bounces@xxxxxxxxxxx] On
Behalf Of Philipp Tiedt1
Sent: 31 March 2006 10:03
To: bpel-dev@xxxxxxxxxxx
Subject: 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
To
bpel-dev@xxxxxxxxxxx
31.03.2006 11:08 cc
Subject
[bpel-dev] Minutes of call
regarding BPEL validation
Please respond to
"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
