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
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