[CONF] Apache Ode: BPEL Simplified Syntax (simBPEL) (page created)

Wed, 24 Oct 2007 04:29:06 -0700

Page Created : ODExSITE : BPEL Simplified Syntax (simBPEL)

BPEL Simplified Syntax (simBPEL) has been created by Tammo van Lessen (Oct 24, 2007).

Content:

Simplified BPEL Syntax (simBPEL)

Proposal by IAAS

Tammo and Oliver from the IAAS took your ideas and worked on a syntax for BPEL4Coders. This file is a quick summary of our results.

Main design goals:

  1. Use _javascript_ Syntax as basis
  2. Provide a 1:1 mapping to BPEL and back

We introduced implicit variable declaration, which does not fulfill the second goal, but perfectly fits to the first goal.

BPEL offers block-structured and graph-based programming. Since block-structured programming is more in-line with _javascript_, we first present on a ordering process how this is reflected in BPEL4Coders.

The commands are executed in sequential order (BPEL: <sequence>)

process OrderCheapestBook  {
	// partner porttypes - identified by QNames of their WSDL porttype
	service amazon = {http://aws.amazon.com/aws}Bookstore
	service bol = {http://bws.bol.de/bws}Bookstore

	// port types offered by the process. Since the process acts as "client" for the partner, "client" as chosen as keyword
	client me = {urn:iaas:toll}BookReseller
	
	// variable declaration. XML support is built-in: po is an XML variable, whose type is defined in a WSDL
	var {urn:iaas:ourxsd}PurchaseOrder po

	// the variable purchaseOrder is declared
	// the type is the type returned by the function me.orderBook()
	// me is a client. Therefore the semantics of function calls on that object is to wait for a partner to call. The received message is returned by the function
	// BPEL: <receive partnerLink="me" operation="orderBook" variable="purchaseOrder" />
	var purchaseOrder = me.orderBook()

	// Service declaration. Type is determined by the first assignment to it
	service res

	// Variables without direct type declaration get their type by the first assigment to them
	var tmp1, tmp2

	// Parallel execution (BPEL: <flow> instead of <sequence>.)
	// nested sequential execution can be made by "seq {...}"
	par {
		tmp1 = amazon.getDollarPriceForISBN()
		tmp2 = bol.getEURPriceForISBN()
	}

	// compiler exception
	tmp1 = tmp2 

	// TODO: compiler exception, since amazon and bol are type incompatible
	if (tmp1/@price < tmp2/@price) {
		res = amazon
	} else {
		res = bol
	}

	// me.orderBook() is a synchronous operation
	// <reply> is done by assigning a value to the operation (cf. Pascal-Syntax)
	me.orderBook() = res.buyBook()
}

Having seen the block-structured part, a simplified loan approval process is now used to illustrate the graph-based part of the language.

process LoanApproval {
	service autoAssessor = {urn:auto}pt
	service humanAssessor = {urn:human}pt
	service customer = {urn:customer}pt
	client me = {urn:me}pt

	// After the statement, links may come
	// Links are separated by commas
	// The condition is enclosed in square brackets
	// the target of a link (indicated by ->) is a label
	var request = me.request() [$request.amount < 50000]->lauto, [$request.amount >= 50000]->lhuman

	// Label "lauto" for the autoAssessor
	lauto: var risk = autoAssessor.approve(request) l1=[$risk = 'high']->lhuman, l2=[risk = 'low']->lapp

	lhuman: var hresult = humanAssessor.approve(request) [$hresult = 'approved']->lapp, [$hresult = 'rejected']->lrej

	lapp: customer.appoved();
	lrej: customer.rejected();
}

The example misses join conditions. Join conditions are put in square brackets in front of the label. To reference links in the join conditions, links have to be named. This happens by putting <linkName>= in front of the link-condition and target.

For example:

lauto: var risk = autoAssessor.approve(request) l1=[$risk = 'high']->lhuman, l2=[risk = 'low']->lapp
[l1 and l2] lapp: customer.appoved();

Scopes are enclosed in braces (prefixed by {{scope }} -> Matthieu):

// Scope
scope {
	onEvent: me.getStatus() {|msg|
		// Event handler for call at operation "getStatus()"
		// msg contains the message sent by the partner
		client.notify("processing");
	}
	onEvent: me.getExtStatus() {|msg|
		...
	}
	...
	} onFault f {
		// Fault Handler for fault f
	} onCompensation {
		// Compensation Handler
		...
	} onTermination {
		// Termination Handler
		...
	}
	...
}

There is no disambiguity in the usage of the brackets. For example, if a scope should be nested in a handler, it looks like follows:

...
} onFault f {
	scope("test") {
		...
	} onFault g {
	}
} onCompensation {
...

Future work:

  • Check whether all aspects of <assign> are covered by BPEL4Hackers
  • How should the extension activity be modeled? "
    {{{XML-Code for the extension}}}
    "? (Three braces, because some Wiki-Syntax definitions use that for verbatim text)
  • Should activity naming be supported? (could be done via , name="..." put before/after the outgoing links)
  • Provide syntax for all BPEL activities. Especially forEach (parallel vs. non-parallel)
  • Clarify whether a grouping of clients and services is needed. - BPEL's partnerLink concept offers myRole and partnerRole. BPEL4Coders currently offers either myRole or partnerRole (you can choose between "client" and "service").
  • Describe implicit variable declaration
  • Provide a grammar for BPEL4Coders
  • Describe the transformation from BPEL4Coders to WS-BPEL 2.0

Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request

Unsubscribe or edit your notifications preferences

Reply via email to