I have another example, now on the website, but you can also download from here:

ICSOC08 Obligation Analysis Demonstration

Hope that helps…

I just tried it too and receive the same error. I will look into it and get back to you.

However it shows us an error windows "An error occurred performed analysis. null" during the verification.

Following are information on running environment:
Operating System:Win XP Pro
Eclipse version: We have tried 3.4, 3.4.2, 3.5

Please use the link http://tinyurl.com/yhcbbas to download the WS-EngineerProb.zip file that contains ErrorMessage.gif, roadassistance.cdl, and roadassistance.bpel

ErrorMessage.gif - Screen shot of the error message window
roadassistance.cdl, and roadassistance.bpel - the CDL and BPEL file we are using for obligation test.

Is there any problem of the downloaded running files? Or it is due to some subtle issues on WS-Engineer?
Thanks for looking into it!

Thanks.

Some other things not supported (mainly WS-BPEL 2.0 things) are listed here: http://ws-engineer.wikidot.com/wsewsbpel2

Kind Regards

A remark: uncommenting the faultHandler block breaks the translation.

Thanks,
DB

 <!-- loanapproval BPEL Process [Generated by the Eclipse BPEL Designer] --> <!-- Date: Wed Nov 04 12:22:38 PST 2009 --> <bpel:process name="loanapproval" targetNamespace="http://example.com/loan-approval/" suppressJoinFailure="yes" xmlns:lns="http://example.com/loan-approval/wsdl/" xmlns:bpel="http://docs.oasis-open.org/wsbpel/2.0/process/executable" > <!-- ================================================================= --> <!-- PARTNERLINKS --> <!-- List of services participating in this BPEL process --> <!-- ================================================================= --> <import importType="http://schemas.xmlsoap.org/wsdl/" location="loanapproval.wsdl" namespace="http://example.com/loan-approval/wsdl/" /> <bpel:partnerLinks> <bpel:partnerLink name="customer" partnerLinkType="lns:loanPartnerLT" myRole="loanService"></bpel:partnerLink> <bpel:partnerLink name="approver" partnerLinkType="lns:loanApprovalLT" partnerRole="approver"></bpel:partnerLink> <bpel:partnerLink name="assessor" partnerLinkType="lns:riskAssessmentLT" partnerRole="assessor"></bpel:partnerLink> </bpel:partnerLinks> <!-- ================================================================= --> <!-- VARIABLES --> <!-- List of messages and XML documents used within this BPEL process --> <!-- ================================================================= --> <bpel:variables> <bpel:variable name="request" messageType="lns:creditInformationMessage"/> <bpel:variable name="risk" messageType="lns:riskAssessmentMessage"/> <bpel:variable name="approval" messageType="lns:approvalMessage"/> </bpel:variables> <!-- ================================================================= --> <!-- ORCHESTRATION LOGIC --> <!-- Set of activities coordinating the flow of messages across the --> <!-- services integrated within this business process --> <!-- ================================================================= --> <!-- <bpel:faultHandlers>--> <!-- <bpel:catch faultName="lns:loanProcessFault"--> <!-- faultVariable="error"--> <!-- faultMessageType="lns:errorMessage">--> <!-- <bpel:reply partnerLink="customer"--> <!-- portType="lns:loanServicePT"--> <!-- operation="request" variable="error"--> <!-- faultName="unableToHandleRequest" />--> <!-- </bpel:catch>--> <!-- </bpel:faultHandlers>--> <bpel:sequence> <bpel:flow> <bpel:links> <bpel:link name="receive-to-assess"></bpel:link> <bpel:link name="receive-to-approval"></bpel:link> <bpel:link name="approval-to-reply"></bpel:link> <bpel:link name="assess-to-setMessage"></bpel:link> <bpel:link name="setMessage-to-reply"></bpel:link> <bpel:link name="assess-to-approval"></bpel:link> </bpel:links> <bpel:receive name="receive1" partnerLink="customer" portType="lns:loanServicePT" operation="request" variable="request" createInstance="yes"> <bpel:sources> <bpel:source linkName="receive-to-approval"> <bpel:transitionCondition>bpel:getVariableProperty('request', 'amount') &lt; 10000></bpel:transitionCondition> <!-- <bpel:transitionCondition>$request.amount &lt; 10000></bpel:transitionCondition>--> </bpel:source> <bpel:source linkName="receive-to-assess"> <bpel:transitionCondition>bpel:getVariableProperty('request', 'amount') >= 10000></bpel:transitionCondition> <!-- <bpel:transitionCondition>$request.amount >= 10000></bpel:transitionCondition>--> </bpel:source> </bpel:sources> </bpel:receive> <bpel:invoke name="invokeAssessor" partnerLink="assessor" portType="lns:riskAssessmentPT" operation="check" inputVariable="request" outputVariable="risk"> <bpel:targets> <bpel:target linkName="receive-to-assess"></bpel:target> </bpel:targets> <bpel:sources> <bpel:source linkName="assess-to-approval"> <bpel:transitionCondition>bpel:getVariableProperty('risk', 'level') != 'low'</bpel:transitionCondition> <!-- <bpel:transitionCondition>$risk.level!='low'</bpel:transitionCondition>--> </bpel:source> <bpel:source linkName="assess-to-setMessage"> <bpel:transitionCondition>bpel:getVariableProperty('risk', 'level') = 'low'</bpel:transitionCondition> <!-- <bpel:transitionCondition>$risk.level='low'</bpel:transitionCondition>--> </bpel:source> </bpel:sources> </bpel:invoke> <bpel:invoke name="invokeapprover" partnerLink="approver" portType="lns:loanApprovalPT" operation="approve" inputVariable="request" outputVariable="approval"> <bpel:targets> <bpel:target linkName="receive-to-approval"></bpel:target> <bpel:target linkName="assess-to-approval"></bpel:target> </bpel:targets> <bpel:sources> <bpel:source linkName="approval-to-reply"></bpel:source> </bpel:sources> </bpel:invoke> <bpel:assign name="assign"> <bpel:copy> <bpel:from> <bpel:literal>yes</bpel:literal> </bpel:from> <!-- <bpel:to variable="approval" part="accept"></bpel:to>--> <bpel:to variable="approval" property="accept"></bpel:to> </bpel:copy> <bpel:targets> <bpel:target linkName="assess-to-setMessage"></bpel:target> <bpel:sources> <bpel:source linkName="setMessage-to-reply" /> </bpel:sources> </bpel:targets> </bpel:assign> <bpel:reply name="reply" partnerLink="customer" portType="lns:loanServicePT" operation="request " variable="approval"> <bpel:targets> <bpel:target linkName="setMessage-to-reply"></bpel:target> <bpel:target linkName="approval-to-reply"></bpel:target> </bpel:targets> </bpel:reply> </bpel:flow> </bpel:sequence> </bpel:process> 

The name of a construct (as far as I can tell) is not mandatory in BPEL, thus a "backup" unique naming strategy is adopted in WS-Engineer.
I guess, the naming strategy in WS-Engineer could be improved to avoid clashes.

For now, just avoid using the same name suffixed with a number (e.g. sequence1) and give them a nice helpful meaningful name (e.g. mainSequence).

http://ltsa.wikidot.com/forum/t-170787/ws-engineer-ltsa-installation-on-mac-eclipse-3-5#post-553339

“Good news” is a quick Google search seems to link it to a long running set of Sun AWT problems (probably in Eclipse Linux build).

Two such bugzilla entries are running:
Bug 74095
Bug 171432

Bad News is naturally I don’t want to change the ltsa eclipse code (that works on Windows) unless we know a compatible fix.

If you have any ideas, let me know.

this is the output in console:
at sun.awt.X11.XToolkit.SAVED_ERROR_HANDLER(XToolkit.java:125)
at sun.awt.X11.XToolkit.GlobalErrorHandler(XToolkit.java:136)
at sun.awt.X11.XlibWrapper.CallErrorHandler(Native Method)
at sun.awt.X11.XToolkit.SAVED_ERROR_HANDLER(XToolkit.java:125)
at sun.awt.X11.XToolkit.GlobalErrorHandler(XToolkit.java:136)
at sun.awt.X11.XlibWrapper.CallErrorHandler(Native Method)
at sun.awt.X11.XToolkit.SAVED_ERROR_HANDLER(XToolkit.java:125)
at sun.awt.X11.XToolkit.GlobalErrorHandler(XToolkit.java:136)
at sun.awt.X11.XlibWrapper.CallErrorHandler(Native Method)
at sun.awt.X11.XToolkit.SAVED_ERROR_HANDLER(XToolkit.java:125)

Link to YouTube demo

Link to Help Guide

Note: new install site - http://www.doc.ic.ac.uk/ltsa/eclipse/install

To re-enable the old update manager: Window->Preferences->General->Capabilities and select "Classic Update".

To remove Equinox p2 see this article on Eclipse Wiki: Equinox p2 Removal

There is one major issue I know already with the installation and the Update Manager. It appears when you install WS-Engineer the update manager has a problem resolving dependencies (and therefore doesn't resolve anything).

First you get a "The software items you selected may not be valid with your current installation. Do you want to open the wizard anyway to review the selections?". Clicking yes gives you details such as:

Cannot complete the request. See the details.
Cannot find a solution where both Match[requiredCapability: org.eclipse.equinox.p2.iu/ic.doc.sensoria.modes.Dino/[1.1.1,1.1.1]] and Match[requiredCapability: org.eclipse.equinox.p2.iu/ic.doc.sensoria.modes.Dino/[1.1.0,1.1.0]] can be satisfied.

I'm looking in to this as I write…

It is currently out-of-date, but provides a rough guide on how to use the tool. UPDATES SOON!

LTS Interaction Demo

A draft primer (http://www.oasis-open.org/committees/download.php/23797/wsbpel-primer-draft.doc) contains the following change summary:

3. What’s new in WS-BPEL 2.0

As a result of the OASIS Technical Committee’s issues process, the original BPEL4WS 1.1 specification has received several updates. The following list summarizes the major changes that have been incorporated in the WS-BPEL 2.0 specification.

Data Access
• Variables can now be declared using XML schema complex types
• XPath expressions are simplified by using the ‘$’ notation for variable access, for example, $myMsgVar.part1/po:poLine[@lineNo=3]
• Access to WSDL messages has been simplified by mapping directly mapping WSDL message parts to XML schema element/type variables
• Several clarifications have been added to the description of the <assign> activity’s <copy> semantics
• The keepSrcElementName option has been added to <copy> in order to support XSD substitution groups or choices
• The ignoreMissingFromData has been added to automatically some of <copy> operation, when the from data is missing.
• An extension operation has been added to the <assign> activity
• A standardized XSLT 1.0 function has been added to XPath expressions
• The ability to validate XML data has been added, both as an option of the <assign> activity and as a new <validate> activity
• Variable initialization as part the of variable declaration has been added

Scope Model
• New scope snapshot semantics have been defined
• Fault handling during compensation has been clarified
• The interaction between scope isolation and control links have been clarified
• Enrichment of fault catching model
• A <rethrow> activity has been added to fault handlers
• The <terminationHandler> has been added to scopes
• The exitOnStandardFault option has been added to processes and scopes

Message Operations
• The join option has been added to correlation sets in order to allow multiple participants to rendezvous at the same process with a deterministic order
• Partner link can now be declared local to a scope
• The initializePartnerRole option has been added to specify whether an endpoint reference must be bound to a partner link during deployment
• The messageExchange construct has been added to pair up concurrent <receive> and <reply> activities

New Activitiesy types
• Added serial and parallel <forEach> with optional completion condition
• Added <repeatUntil>
• Added new extension activity
• Changed <switch> to <if>-<elseif>-<else>
• Changed <terminate> to <exit>
• Differentiate different cases of <compensate> by renaming them to <compensate> and <compensateScope>

Miscellaneous Cchanges
• Added repeatEvery alarm feature to event handlers
• Clarified resources resolution (e.g. variable, partner link) for event handlers
• Added formal <documentation> support
• Added extension namespace declarations in order to specify what extension must be understood
• Add <import> support to import WSDL and XSD formally

Abstract Processes
• Clarified Abstract Process usage patterns
• Introduced Abstract Profiles to address different needs in Abstract Processes, and two concrete profiles “Observable Behavior” and “Process Template” listed in the specification

Here is a screenshot of one such choreography (taken from an example WS-CDL document)….

We plan to add support for BPEL 2.0 as defined in the (currently draft) specification at OASIS.`

News will be posted on this site when this is available.

The aim is to list the following:

WS (Engineering) Area - Profile, Composition, Choreography, Service, Standards etc
WS Sub Area - Editor, Validation, Verification, Deployment etc.
Title/Link - Link to download the tool
Requirements - Prerequisites for using the tool
Description - summary of what the tool is used for.

Comments welcome.
regs,
WSEngineer

BPEL is a work in progress. Like any of its predecessor standards (SQL, XML, etc.), industry gadflys and naysayers will bash BPEL right up to the point where it's pervasively adopted, then they'll jump on the bandwagon and claim they played a major role in shaping BPEL's success.

BPEL 1.1, while certainly imperfect, provides a rich grammar for expressing a broad range of service orchestrations. BPEL 1.1 (with or without vendor extensions) has been used as the cornerstone of many deployed SOA applications. Thus, assertions about BPEL's limited value as an execution language are now being laid to waste by real world anecdotes. Like it or not, BPEL is rapidly achieving "de facto standard" status. And BPEL 2.0 represents a meaningful step forward, adding important constructs and resolving prior ambiguities.

The thesis that BPEL's primary value lies in process portability (or even more absurd, interoperability through abstract processes) flies directly in the face of other successful standards. The real value of any standard is KNOWLEDGE portability. SQL is a case in point. Oracle's PL/SQL and Sybase's Stored Procedures are proprietary, non-portable extensions to the SQL standard. Yet millions of IT professionals know SQL syntax and semantics, and enjoy the enormous leverage resulting from that portable KNOWLEDGE. While it's true that standards enable interoperability and (in theory) reduced switching costs, portability of KNOWLEDGE is really where the rubber meets the road. BPEL is directly analogous to SQL in this regard.

With regard to transitions from BPEL 1.1 to 2.0, the level of rework will depend on how the 1.1 processes were constructed. Our 1.1 users have generally been mindful of the reality that they're building orchestrations based on an evolving standard, and they've factored some rework effort into their plans. That said, our BPEL 2.0 products are 100% backward compatible with 1.1. So ActiveBPEL users can simultaneously execute both 1.1 and 2.0 orchestrations in the same server, allowing them to migrate from 1.1 to 2.0 on timetables that suit their individual needs.

Fred Holahan
Active Endpoints, Inc.

Posted by: Fred Holahan at September 21, 2006 08:38 AM

The idea of a well implemented BPEL 2.0 is that many of the things people complain are missing, are quite easy to implement in the language as a sub-process, for example, human task workflow. However, this depends on a good implementation. Languages such as BPEL are not designed to be used only to expose services of existing technologies. BPEL needs an engine. This is called a process virtual machine. Good BPMS products include a process virtuall machine, and great design tools. For example, a tool can be used to design a workflow process, which can then be re-used within any other process. A process virtual machine is therefore a superset of typical workflow engines, allowing the whole process to be mapped, including sophisticated integration paths, data processing etc. This is not apparent from reading the BPEL spec. Only through an implementation can the value of a BPMS be seen. Having said all that, I'm not a great fan of BPEL myself. I preferred BPML. It was formally complete and rigorous in ways BPEL is not. But BPMS vendors were forced to adopt BPEL because the big boys in our industry appeared not to want to, or could not, implement BPML. So debates on BPEL are tied up with past debates over BPEL versus BPML. The ironic thing is, a good BPMS can use either, for the process virtual machine is what is complete and rigorous. Ultimately, BPEL, or BPML, is only an external syntax for the engine's execution semantics. Also, be aware that BPEL only specifies one participant's execution. A BPMS process engine must exectute across independently executing BPEL threads. These "end to end processes" are where the power of a BPMS lies. The BPMS can expose and reuse processes wherever they lie, in old code or new. (ex co-chair BPMI.org)

Posted by: Howard Smith at September 28, 2006 11:51 PM

Let's face it, BPEL 1.1 was a bad standard that left so much out that many end users and vendors found it useless. In response, the vendors put a ton of proprietary extensions in their BPEL 1.1 - based products, thus diluting its value to the point of "why bother."

While I've been ranting and raving about this for some time, Dave Chappell does a much better job in explaining the limitations.

"Promoting BPEL's portability helps significantly in the first of these goals, since customers like the idea of not being locked in to a single vendor. But actually making customers successful has typically required extending BPEL in proprietary ways, which works against the language's promised portability. While BPEL purists might argue that all of these extensions should be provided via programming language-neutral web services interfaces, this isn't what?s actually happening in the products."
With huge investment in BPEL by the larger SOA players out there the dirty little secret is that BPEL 1.1 never really worked as advertised, and the amount of custom and proprietary extensions required making the technology useful meant that the money, time, and effort was pretty much wasted if standards and portability was the goal.

Enter WS-BPEL 2.0, and another opportunity for vendors to get BPEL right. You can find the draft specification here, which I read, and discovered that this spec was much improved, but with many issues that remain. For instance, WS-BPEL 2.0 has considerable differences to its previous 1.1 version. The major differences include syntax changes to the language, inclusion of new features including parallel for-each, and modifications to the semantic of existing constructions, such as compensation handling.

Hmmmm. So, what if I already implemented orchestrations using BPEL 1.1, what do I do now? In short, you purchased Beta and the world is moving to VHS (yes, I'm old). I thought that this article by BEA's Alexandre Alves did a good job in summing things up.

"For all but the simplest business processes, migration from BPEL 1.1 to BPEL 2.0 is not an easy task. Some of the syntactic changes can be automated as shown [in this article], however the semantic differences, especially when dealing with links, messaging, compensation handling, and data manipulation, will demand a comprehensive and time-consuming process."

I suspect the BPEL sales guys will get some angry calls around Christmas time from their users, perhaps more so considering the use of many proprietary extensions to get around the limitations of BPEL 1.1. Not a good way to start a standard, I guess that is why my old boss told me never buy products until release 3.0.

Ok, from the systems integration view of web services, my preference is to take the W3C Web Services Requirements definition (being the World Wide WEB consortium) which is:

“A web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artefacts and supports direct interactions with other software applications using XML based messages via Internet-based protocols.”

Infact, even the W3C give differing definitions (W3C Web Services Architecture Group)… but I believe the above definition is flexible enough to cater for different technologies and transport protocols.

bpws:getVariableData('input','payload', '/global:PhilosopherRequest/global:iterations')

Section 14.1 of the BPEL4WS spec WS-BPEL1.1 explains….

Expressions

These extensions refer to the Expressions feature of BPEL4WS.

The first extension defines a standard fault for erroneous use of the XPath 1.0 function defined for extracting global property values from variables.

bpws:getVariableProperty ('variableName', 'propertyName')

The first argument names the source variable for the data and the second is the qualified name (QName) of the global property to select from that variable (see Message Properties). If the given property does not appear in any of the parts of the variable's message type or the given property definition selects a node set of a size other than one, then the standard fault bpws:selectionFailure MUST be thrown by a compliant implementation.

The second extension defines an additional XPath 1.0 function usable only in executable processes. This function extracts arbitrary values from variables.

bpws:getVariableData ('variableName', 'partName', 'locationPath'?)

The first argument names the source variable for the data, the second names the part to select from that variable, and the third optional argument, when present, provides an absolute location path (with '/' meaning the root of the document fragment representing the entire part) to identify the root of a subtree within the document fragment representing the part. The return value of this function is a node set containing the single node representing either an entire part (if the third argument is absent) or the result of the selection based on the locationPath. If the given locationPath selects a node set of a size other than one during execution, then the standard fault bpws:selectionFailure MUST be thrown by a compliant implementation.

I am working on a patch and will roll out asap.

The Intellectual Property Rights for this tool are currently owned by the authors (Dr Howard Foster, Professor Jeff Magee etc). We may release the source code as public in furture releases, however currently, users may not change or redistribute the software available freely.