BPEL Designer Editor
The project has been created. Please visit the project page.
The BPEL Designer Editor is a proposed open source
project under the Eclipse
This proposal is in the Project Proposal Phase (as defined in the
Development Process document) and is written to declare its intent
and scope. This proposal is written to solicit additional participation
input from the Eclipse community. You are invited to comment on and/or
project. Please send all feedback to the
The goal of this project is to add comprehensive support to Eclipse
for the definition, editing, deploying, testing, and debugging of
BPEL4WS flows (Business Process Definition Language for Web
in vendor neutral environments. The implementation will be extensible
to third party vendors so that runtime implementations could integrate
seamlessly to the design/build/deploy/test cycle and integrate
specific domain BPEL4WS constructs and extension
BPEL4WS is developing standard supported by the major software
vendors such as Oracle, IBM,
BEA,Microsoft, SAP, and Siebel
Systems. It is a key component of the SOA (Service Oriented
Architecture) stack and it is finding great
acceptance within the community of users and solution providers. While
each vendor is pursuing their own runtime for BPEL the tool
support is lagging behind and is based on vendor specific tool
solutions which developers are finding increasingly less appealing.
BPEL4WS depends on WSDL 1.1, XML Schema 1.0, XPath 1.0 and
WS-Addressing. Although WSDL and XML schema are integral to the BPEL
design, this project will not be providing any tools to manage these
resources and will leverage parts of the Eclipse ecosystem for
This project will provide broad support for integrating BPEL4WS
design time experience with
the Eclipse platform. BPEL4WS is defined in here.
BPEL4WS is a flow type XML language used to orchestrate business
process flows. The key tasks performed by BPEL processes are
manipulation of XML documents
and interaction with Web Services. BPEL4WS depends on the
following XML-based specifications: WSDL 1.1, XML Schema 1.0, XPath 1.0
The specific intent of this project is to provide better,
integrated, and extensible design time experience on the Eclipse
platform. Key to the success will be pairings of vendor runtime
environments and design time extensions (palette extensibility or
element extensibility for example). We intend to use the standard
Eclipse mechanism of extension points to allow 3rd party integration of
various such elements.
The two core components of the
project would be visual and source design of the flow and
interpretation of XML
schema model used as definition for BPEL variables and messages. The
project would focus on the design time aspect of BPEL
which includes construction, definition, inspection, and
documentation. The runtime aspect of BPEL is typically vendor specific
and includes such parts as validation, compilation, deployment,
debugging, versioning, and migration.
While the runtime aspect is not the focus of the project suitable
extension points will be defined to allow pairing of BPEL runtime to
create complete design time experience. At minimum this will include
validation, compilation, and deployment interfaces for extension by 3rd
At the time of this writing, BPEL 1.1 has been defined but BPEL 2.0
specification has not been finalized and changes are expected before
the final draft is issued. Accordingly, the scope of this proposal will
track the draft specification. More information on BPEL4WS version 2.0
can be found here.
In the event that version 2.0 of the BPEL
specification is not complete we anticipate releasing versions of the
designer which may not support the full 2.0 specification. Such
intermediate versions may include no
support or partial support
for the unfrozen sections of the BPEL specification.
Leverage the Eclipse Ecosystem
: It is our goal to
extend the Eclipse user experience as well as leverage other Eclipse
project functionality where applicable.
Vendor Neutrality: We intend to build the tool that so that
it is not biased toward any particular BPEL runtime. Proposed
vendor runtime support
is discussed in Runtime Support.
Extensibility: It is our intention to provide a set of
extension points to allow for the binding the runtime time environment
and to allow extensibility of component palettes. The implementation
should have a rich model representation of BPEL with support for
validation. That the model should be extensible so that new activities
and expression languages can be defined.
Incremental Development: As this project will be
subject to an evolving specification, an agile development process will
be employed to manage and respond to changing requirements. We will
employ the milestone approach used by many eclipse projects.
We propose this project should be undertaken as an incubator within
the Eclipse Technology Project.
Initially BPEL Expert Group members and other individuals and
organizations that have serious interest will be solicited to
participate. This list would cover a broad base of organizations
interested in BPEL.
Proposed project lead and initial committers
The following parties have expressed interest in this
project. Key contacts listed.
The submitters of this proposal welcome interested parties to
to the eclipse.technology.bpel-designer
newsgroup and ask to be added to the list as interested parties or to
suggest changes to this document.
None planned at this time.
Below are areas of targeted support for the project:
BPEL Designer Specific functionality
This section illustrates type type of functionality the BPEL visual
designer should have
tool must have the ability to construct BPEL
flows visually. The visual representation should have a predefined “UI
Free form layout design maps tend to be cumbersome and hard to
navigate. The tree like structure of a
BPEL orchestration definition leads itself to predefined UI layout.
palette of elementary building blocks must be
available for drag/drop functionality
palette must be extensible by 3rd party vendors so that contributions
of useful building blocks can be made to the palette.
- Skinnable look
- Palette items should be skinnable - this includes both visual
and textual description on the palette and process map and in other
views where such items would be visible.
- Process Map visuals - this includes iconic representation on
the process map as well as description format.
- Properties drawer (inspector area) for customizing elements and
node in the flow should be customizable by
a inspector specific to the semantics of the node. This is a fairly
UI paradigm available in a number of development tools.
inspectors must allow for pluggable
customizers that can better help a user with a customization process.
in and out support.
for Cut Copy Paste (simple text), but
also for Cut/Copy/Paste of whole segments of a BPEL process. Cut/Copy
cloning with automatic rename.
- Drag and drop support for integration with resources such as
WSDLs , XML Schemas, etc.
and Redo capabilities need to be present.
- Editor must have the capability to deal with "unknown" activities
(that is names which may be "custom" or vendor specific).
- Ability to view and work within a standard-only world and flag
parts of the process definition which are not portable.
for editing several BPEL process
definitions at once. This can be done by allowing the user to open
process definitions each in their own editor instance and independent
- Support for editing large BPEL processes with complex maps -
breaking and managing visual complexity (whitespace, layers).
ability to customize Font and Colors. At the
beginning this can be very basic but the code should be written with
concept of pluggable resources and colors.
to add notes to the process map. These
are help notes that document the process in and are not in any way part
process semantics. Support for rich text (perhaps HTML) should be
since text notes may contain links etc.
- Ability to "open" and "save" processes from a variety of places:
- already deployed processes
for further editing and evolution (via BPEL runtime binding).
- from a .bpel file available in an Eclipse project container.
- from a a variety of source repositories (CVS)
- WebDAV accessible file systems
- Remotely installed web services need to be “explorable” from the
designer tool. The WSDL of the web service must be visually
presented to indicate what types of messages and data types are
supported for that service. A good starting point might be a WSIL
document which leads to a WSDL or other WSIL documents.. Just a way to
look at the "structure" of a web service; in/out arguments, type view
of messages, etc
- Add Hoc interaction with Web Services - simple client interface
to web services - simple interactions with published services to "try
- UDDI browse capability to discover existing services.
- There should be several views to look at the process:
- Process map - the "diagram" view of the process
- Tree structure that mimics the XML BPEL structure
- Raw XML view of the process definition.
- Documentation view (generated from BPEL source and annotation
- Additional views which convey other types of information
- Support for refactoring support for BPEL process maps. For
example, pushing activities into a scope or sequence container and
placing the result on a palette.
- Support for robust searching, bookmarking, and navigating the
process map and the process code.
Wizards will be provided to assist in prototyping and jump starting
of projects. This does not imply that a special project needs to be
opened for editing a BPEL document. However, a set of templates and
wizards will provide a starting point for a creating a BPEL file.
In addition, commonly used pieces of BPEL code will be added to the
palette so that they can be easily dragged onto the process map to help
with common "patterns" of BPEL flow (such as scope + assign +
Developer productivity will be enhanced with the following features.
- Inspection of XML schemas and visual XPath expression building.
- Support for BPEL extension functions in the design time
environment (some of which can be vendor specific).
- Support for on the fly validation if a runtime has been paired to
the design environment.
- Support for schema definition through existing Eclipse frameworks
The project should be architected as a set of plug-ins, each of
which provides the ability for other groups or vendors to further
extend and customize the functionality in a well-defined manner. Here
is a list of possible extension points that it may provide:
- Runtime environment pairing
- Validation -
- Compilation - vendor specific execution map creation and
execution map creation
- Deployment - interaction with "administrative" API for
installing process at runtime
- Exploration - "read" and "save" (deploy) semantics of
- Addition of functions callable from the BPEL process.
- Providing plugin support for different query languages (XPath
- Extensions to BPEL palette definition
- BPEL element extensions and visual tool contributions
- Pluggable "type" system to allow 3rd parties to extend the
- Modifying existing element definitions such as adding
properties or modifying visuals
- Adding new element definitions such as "custom" bpel activities.
- A set of extension points around skinabilty
Integration Points with Other Eclipse Projects
Given the scope of the project, the BPEL4WS designer will
interact with and leverage the following existing Eclipse
High Level Use Cases
- Create new BPEL process
- New Process Wizard to create new BPEL Process
- Drag 'n' Drop activities from component palette to process map
- Drag 'n' Drop useful resources (like WSDLs or Schemas) from the
- Add partner links, variables
- Create correlation sets for long running interacting processes.
- Customize properties of BPEL activities
- Process is validated on the fly
- Build and deploy to runtime container
- Import Existing Project
- Import Project into Workspace. Import can be from
- File system, file
- CVS or other source repository
- BPEL runtime (via runtime bindings)
- Continue as before
- Browse and edit deployed processes
- Browse deployed processes
- Import for editing
- Edit,Validate, Deploy
- Import extension to Palette
- Add plugin extending the palette extension points
- Added palette appears in the palette menu
- Add extension for runtime support
- Add plugin extending runtime support extension points
- Runtime extension point paired
- Add extension for BPEL runtime functions
- Added plugin extending the runtime functions extension points
- Function wizard and expression builder aware of new functions
- Import new activities definitions
- New activities bundle is added to the designer type system
- Palette contributions are reflected
- Property sheets are defined
- Runtime support: Win32 and Linux minimally
- The initial release will be for the en locale; we will follow
localization guidelines to make translations and localization simple
- Accessibility issues will not be addressed initially other then
by skinability extension points which could for example add hight
contract or black and white or larger visuals.
While the focus of this project will not include runtime components,
runtime interfaces will be provided so that BPEL runtime vendors can
adapt their engines to the design time experience offered by the
designer. This will typically involve steps such as validating,
compiling, and deploying a process. The mechanism for writing such
runtime bindings would typically involve defining a plugin
) which uses extension points
of the BPEL
designer to interact with the engine's "administrative" API.
A given BPEL engine's "administrative" API to perform such tasks may or
may not be public. Hence, there are two paths in which this can be
- A given BPEL engine has public "administrative" API.
In this case, any interested party can provide runtime bindings through
eclipse.org or independently. The source code to such plugin must be (in case of eclipse.org)
or may not be provided.
- A given BPEL engine does not have public "administrative" API.
Only the vendor may provide such runtime bindings and such work would
be most likely outside of eclipse.org.
In order to validate the adapter framework/components we anticipate to
provide runtime support for the following BPEL runtime platforms