| [jwt-dev] EclipseCon Abstract |
|
Hi, I’ve added a few comments to
the abstract that reflect the things that attracted my attention, don’t
know if they’re helpful or nonsense but here we go… Make Your Business[0]Processes Executable! Business managers model their processes often as[1] an abstract version. They are
not concerned about how those will be executed later on (and they shouldn't
be!). The actual execution information[2] will[3] be added by the technical staff
afterwards. But what happens if the modeled process shall be deployed on different
process engines? Each vendor requires different data which has to[4] be added to the process model. The Eclipse Java Workflow Tooling (JWT) project
answers these requirements in its EMF / GEF-based Workflow Editor by providing
support for different views on the workflow, e.g.
technical or business, that reflect the role of the user, [5] and flexible model aspects[6] that allow easy
customization to adapt it to handle specificities of target runtime platforms
and existing data, as well as of modeled business domains. The process model also builds the basis for automatically[7] generating XPDL- or
WSBPEL-code [8]. We will also show the
possibility to monitor the process during execution[9]
as well as we'll demonstrate our integration with the Eclipse STP project (e.g.
by generating code for the STP-Intermediate Model) and within Service
Oriented Architectures[10] more
generally. [0]
refer to business processes specifically? [1] absolutely
not sure here, it’s been a long time since the last english lesson ;) [2] maybe
change to something like “information that is needed by process engine
that runs the process” to make the meaning of the term clearer for people
which are not familiar with which kind of information has to be added to
abstract business process to make them executable [3]
I think changing “can” to “will” could highlight that
this is the usual way to go [4] Stress
the fact that this is not a pleasant business ;) [5]
Insert this? [6] I’m
not sure if someone who is not familiar with EMF knows the business process is
represented as a model. Maybe keeping it more abstract like “and an easy
and flexible aspect-oriented customization mechanism that allows to handle…” [7]
Always good if something happens automatically [8] “…that
can be executed by compatible process engines…”? [9] just
my personal preference [10]
what would you think of changing STP and SOA, starting with SOA in general and
then referring to the STP project? Regards, Chris |