BPEL Designer Editor


Introduction

The project has been created. Please visit the project page.

The BPEL Designer Editor is a proposed open source project under the Eclipse Technology Project.

This proposal is in the Project Proposal Phase (as defined in the Eclipse Development Process document) and is written to declare its intent and scope. This proposal is written to solicit additional participation and input from the Eclipse community. You are invited to comment on and/or join the project. Please send all feedback to the http://www.eclipse.org/newsportal/thread.php?group=eclipse.technology.bpel-designer. newsgroup.

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

Background

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

Description

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 and WS-Addressing.

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 party vendors.

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.

Project Principles

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.

Organization

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

Interested parties

The following parties have expressed interest in this project. Key contacts listed.

The submitters of this proposal welcome interested parties to post 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.

Code Contributions

None planned at this time.

Tentative Plan

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

  • The tool must have the ability to construct BPEL flows visually. The visual representation should have a predefined “UI layout”. 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.
  • A palette of elementary building blocks must be available for drag/drop functionality
  • The 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 look 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 attributes
  • Each node in the flow should be customizable by a inspector specific to the semantics of the node. This is a fairly standard UI paradigm available in a number of development tools.
  • The inspectors must allow for pluggable customizers that can better help a user with a customization process.
  • Zoom in and out support.
  • Support for Cut Copy Paste (simple text), but also for Cut/Copy/Paste of whole segments of a BPEL process. Cut/Copy for node cloning with automatic rename.
  • Drag and drop support for integration with resources such as WSDLs , XML Schemas, etc.
  • Undo 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.
  • Support for editing several BPEL process definitions at once. This can be done by allowing the user to open several process definitions each in their own editor instance and independent of one another.
  • Support for editing large BPEL processes with complex maps - breaking and managing visual complexity (whitespace, layers).
  • The ability to customize Font and Colors. At the beginning this can be very basic but the code should be written with the concept of pluggable resources and colors.
  • Ability to add notes to the process map. These are help notes that document the process in and are not in any way part of the process semantics. Support for rich text (perhaps HTML) should be considered, 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 things out".
  • 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 documentation)
    • 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.


Automation/Generation Functionality

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 + invoke). 

Additional Functionality

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

Extension Points

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 deployed processes
    • Addition of  functions callable from the BPEL process.
  • Providing plugin support for different query languages (XPath (default), XQuery, JavaScript)
  • Extensions to BPEL palette definition
  • BPEL element extensions and visual tool contributions
  • Pluggable "type" system to allow 3rd parties to extend the designer visually
    • 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 projects: 

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 navigator.
    • 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

General

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

Runtime support

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 (extension) 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 accomplished.
  1. 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.
  2. 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