Service Orchestration Functional Specification - Overview

$Revision: 1.3 $
$Date: 2006/06/20 10:34:50 $

Note: This document contains hidden sections. You may show them using the following links: Reader Notes: Hide / Show  |  Author Notes: Hide / Show

Status: Content not perfect, but acceptable

Jirka: (copied from the index page):

* We may polish the use cases, put them in style.
* Maybe, just to revise the BPMN vs BPEL.

1. Introduction

This functional specification will give details about the design of the new SOA Web Service Orchestration Designer tool (aka BPEL-BPMN tool) which will be introduced in NetBeans Enterprise Pack. Web Services Business Process Execution Language is a specialized programming language for specifying business process behavior based on Web Services. Note that the current finalized specification of BPEL4WS is 1.1. The next generation of this specification will be WS-BPEL 2.0, note the name change. This functional specification will primarily use the term BPEL in order to maintain focus on the language rather than a particular specification number. It is currently assumed that the first release of the Orchestration Designer will target WS-BPEL 2.0.

"WS-BPEL provides a language for the formal specification of Executable and Abstract business processes. By doing so, it extends the Web Services interaction model and enables it to support business transactions. WS-BPEL defines an interoperable integration model that should facilitate the expansion of automated process integration in both the intra-corporate and the business-to-business spaces."  WS-BPEL 2.0

A BPEL4WS technology solution consists of design time and runtime aspects. The design time technology must allow BPEL developers to  author BPEL files which describes a BPEL process. The runtime technology consists of a BPEL Server,(aka BPEL engine) to which BPEL artifacts are deployed. Once deployed, the BPEL server "contains" the BPEL processes and supports process instantiation and execution. BPEL servers may be written in any language and hosted in any configuration that a BPEL server vendor provides. This means that a BPEL server is not the same as a J2EE server. A BPEL server may be hosted by a J2EE Server, or it may be a stand alone entity. That is a BPEL server vendor decision.

Relationship between Orchestration Designer and BPEL Server(s)

This functional specification will concentrate, primarily, on those features of the new feature cluster which will support the design time authoring and interactive debugging of BPEL processes. While the primary BPEL artifacts developed in JSE will be portable to any BPEL server, the full cycle BPEL support described in this functional specification will be limited to those BPEL processes which are deployed to the co-bundled Fivesight PXE BPEL Server. JSE will provide an out of the box BPEL runtime environmet by bundling the open source PXE Orchestation Server from FiveSight. This will allow JSE to provide a full cycle orchestration ecology that enables developers to design, deploy, test, and debug BPEL processes. This functional specification will address the integration points between the JSE design time environment and the bundled Fivesight PXE BPEL server.

Additionally, the Sun Java Business Integration (JBI) team plans to host a BPEL server as part of its Java Business Integration Server offering. At present, the plan of record is that this BPEL server will also be the PXE orchestration server, albeit one which has been modified to be hosted by JBI. Eventually, the JSE Orchestation Design tool may support full cycle development to the JBI hosted PXE server in a similar fashion to that which is envisioned for the bundled stand alone PXE server. However, the exact details of a JSE - JBI bundling are out of scope for this version of the functional spec.

Finally, in the interest of avoiding confusion, there is a third BPEL runtime on the horizon. That is the BPEL runtime provided by SeeBeyond, which was recently acquired by Sun. Eventually, the JSE Orchestation Design tool may support full cycle development to the SeeBeyond hosted BPEL server in a similar fashion to that which is envisioned for the bundled stand alone PXE server. However, the exact details of a JSE - SeeBeyond bundling are out of scope for this version of the functional spec.

Relationship between Orchestration Designer and BPMN Notation

BPMN stands for Business Process Modeling Notation. It is also a specification from BPMI.org whose current finalized version is BPMN 1.0.

“The Business Process Modeling Notation (BPMN) specification provides a graphical notation for expressing business processes in a Business Process Diagram (BPD). The objective of BPMN is to support business process management by both technical users and business users by providing a notation that is intuitive to business users yet able to represent complex process semantics. The BPMN specification also provides a mapping between the graphics of the notation to the underlying constructs of execution languages, particularly BPEL4WS.” BPMN Spec V1.0

BPMN is intended to compliment BPEL4WS by providing a standard visual notation since BPEL4WS does not specify a visual modeling notation. BPMN appeals to both tool vendors and business process designers who will be able to standardize on the modeling notation for business process diagrams as opposed to a vendor specific free for all world where every tool promotes its own unique notation. This is analagous to the appeal of UML which also provides a standard modeling notation that benefits both tool vendors and designers. In fact, BPMI.org has submitted BPMN to the OMG (the standards body that oversees UML) for consideration as the foundation for a new UML diagram type called business process diagram. This last point is merely meant to suggest the future direction of BPMN. For the sake of this functional specification we will be referring to BPMN 1.0.

Our intent in the JSE Orchestration Designer is to provide business process analysts and designers with a design time IDE where they can visually design business process diagrams using the BPMN notation and the tool will then generate BPEL process files based on these diagrams. Conversely, the tool should be able to import arbitarty BPEL files and present them for continuing development as BPMN diagrams. However, the Orchestration Desisgner will not support the full scope of BPMN.

While, on the surface, BPMN and BPEL seem totally complimentary, the real story is more complex. Unfortunately, at this time, the BPMN specification only provides a mapping from BPMN to BPEL. It does not provide a mapping from BPEL to BPMN. Additionally, BPMN is "bigger than BPEL" to the extent that the BPMN specification includes some BPMN constructs that are not mappable to BPEL. It is not as simple as diagramming in BPMN and then easily generating BPEL. After much analysis, the decision has been made to bias the Orchestration Designer in favor of BPEL. This means that the design center will be the BPEL process and to this end the tool will make use of as little or as much of the BPMN technology as is reasonable. The Orchestration Designer will be true to the spirit of BPMN but not the letter of BPMN. The tool will use the BPMN shapes but the properties for each element will more directly reflect the BPEL source code than the BPMN element properties. This strategy has the advantage of allowing developers to more transparantly and intuitively understand the relationhip between the process diagram and the BPEL source. It also makes the job of reverse engineering from BPEL to BPMN much, much easier and acheivable.

2. High Level Use Cases

This section will list all the high level use cases that relate to Orchestration Designer functionality for JSE.

ID	Component	Description		Source
		Use Case	Customer Need
	Orchestration Designer	Designer should support the visual authoring of BPEL files in a forward engineering fashion. Forward engineering is where a developer works on a "visual business process diagram" and the Designer generates the corresponding BPEL source code.	Customers need to be able to author BPEL files without having to read or write the actual BPEL XML markup.
	Orchestration Designer	Designer should support the visual authoring of BPEL files in a reverse engineering fashion. Reverse engineering is where a developer imports an arbitrary BPEL file and the Orchestration Designer generates a corresponding "diagram". The developer is then free to forward engineer modifications to the BPEL.
	Orchestration Designer	Designer should support deployment of BPEL artifacts to BPEL server(s) Initially, automation of deployment may be restricted to the co-bundled Fivesight PXE BPEL server since there is no standard BPEL deployment across BPEL server vendors.
	Orchestration Designer	Designer should support importation of arbitrary WSDL files in an easy to use fashion to expedite the creation of BPEL where the WSDL files correspond to "partners" of the BPEL process
	Orchestration Designer	Designer should support interactive debugging of deployed BPEL processes. Initially, interactive debug may be restricted to the cobundled Fivesight PXE BPEL server since there is no standard BPEL debugging API across BPEL server vendors.
	Orchestration Designer	Designer should provide a robust sample data and process test drive environment for the BPEL process under development.

2.1. Requirement Assumptions

 

• In the absence of a BPEL4WS endorsed notation, the only significant specification for business process notation is BPMN. And since BPMN is specifically targeted at being mappable to BPEL, this is a reasonable choice for the Orchestration Designer tool to use BPMN as its notation of choice. The alternative is for the Orchestration Designer to expose a proprietary BPEL notation of our own design. A proprietary notation is less appealing for many reasons.
• The correspondence between the BPMN specification and the BPEL execution language is less than perfect, particularly as regards reverse engineering BPEL to BPMN. For this reason the orchestration designer will limit its usage of BPMN and compliance with the BPMN specification to that which is practical and expedient. The Orchestration Designer wil employ a heavy bias toward BPEL process design. Rapid development of BPEL is the goal, BPMN is merely a means to get there.The assumption here is that the BPEL bias will provide a more consistent and productive full cycle development environment for our targeted customers. A companion assumption is that, while not strict BPMN, the diagrams will be readily intelligible to anyone familiar with BPMN.
• This specification will be a living document. The first draft will be light on pictorial details of the actual tool. As these details are filled in, this document will be adjusted to reflect those designs. Eventually, all images and descriptions will be precise for the JSE version.
• The persisted process file (.bpel) will be the primary design artifact. Diagram layout metadata will be either embedded in the .bpel file via the BPEL extension mechanism or kept in a companion side file.
• In theory each BPEL file can be deployed and run on any BPEL Server. This functional specification will concentrate primarily on those features of JSE which will support the design time authoring of BPEL processes. While the primary BPEL artifacts developed in JSE will be portable to any BPEL server, the JSE interactive BPEL debugging support described in this functional specification will be limited to those BPEL processes which are deployed to the co-bundled Fivesight PXE BPEL Server.