Scenario format and editor changed in Savara 2.0.0.M2

Savara 2.0.0.M2 has just been released as an Eclipse update site version only. This is because all the work for this milestone has been in the core OSGi bundles and the Eclipse plugins, so no reason to build a new server integration distribution.

The main purpose of this milestone release is to perform some refactoring to enable extensibility in the contract/service generation areas, and the simulation of roles defined in a scenario. This has resulted in two main changes:

1) In previous releases the particular target generation format was selected on the context menu associated with the choreography description. From this milestone release, the generation menu now only provides two options, Contract and Service. These options launch a dialog window that enables the user to select the specific generation format for all relevant roles in the source model. So this means that all of the relevant contracts or services can be generated in one step, potentially using different target formats. Currently only BPEL and WSDL are supported.

2) New simplified Scenario format and associated editor. The new scenario format only contains the basic information required (equivalent to the business view in Savara1 scenarios) and is no longer tied to a particular (ws-cdl) model, which has its pros and cons. The pros are that it can be used against multiple models, which also means that each role can be simulated against a different model (or service implementation). The cons relate to the ease of specifying the scenario, as there is no direct reference model. However scenarios are intended to be specified before the model (in terms of the methodology when used top down), so in those situations a model wouldn't be available anyway. A future enhancement could be to enable artifacts to be associated with the scenario in a less explicit manner, which could be used by the editor to infer information that could be useful to the user in constructing the scenario.

Note that currently there are no docs for these changes. The aim is to make the features available as soon as possible, to encourage feedback - therefore a quick overview of the new scenario capability is described below.

The first change is that Savara scenarios (as opposed to the pi4soa Scenarios previously used) have their own category in the New menu.

The scenario editor itself is very similar. From first appearence it only looks like a few of the palette items have disappeared. These are the 'Assert State' and 'Record State' items, which were very limited in their capability and specific to WS-CDL. A future enhancement of the new scenario format could investigate ways of specifying assertions.

The main change to note here is the properties associated with the selected message link. With the new scenario format a message link now only identifies whether an error is expected, the optional operation and fault names, and one or more parameters. A parameter is comprised of two pieces of information, the parameter type and the URL to the message value.

The next change is the way in which scenarios are simulated. Previously when the simulation was triggered, it would immediately simulate the scenaro against the WS-CDL choreography description that had been directly referenced from within the scenario.

In this new version, performing the simulation action (i.e. pressing the green 'play' button or selecting scenario->simulate on the context menu), will show the following dialog window:

The main region of the dialog is composed of a repetitive group, one per role in the scenario. This group enables the (a) model (i.e. choreography), (b) role within the model, and (c) simulator, to be selected. There are also checkboxes at the top of the dialog (checked by default) that enable the same values for the model and simulator to be applied to all roles within the scenario - making it more efficient in the case where only a single model and simulator implementation is being used.

To load the model, simply press the '...' button by the first role's model text field. This will display a dialog box that can be used to find the appropriate model. The list of model roles, and simulators, will update once a model has been selected, to reflect the available roles and simulators that are appropriate to the model. So if you select any old file, then don't expect any values to appear in these comboboxes. Currently the only model type supported is the .cdm files.

In our example project we have a PurchaseGoods.cdm model. When this is selected, the dialog window makes its best estimate at the model role mappings:

When the OK button is pressed, this will trigger the simulation, which will be reflected in the graphical representation of the scenario as before:

Feedback on these new changes, and any enhancements required, would be welcome. Simply post to the user forum or raise an issue in the Savara jira.


To install the release, simply download the JEE version of Eclipse Helios, and then install the following using the "Help->Install New Software" menu option:

1) Savara 2.0.0.M2 from: http://downloads.jboss.org/savara/releases/updates/2.0.x

and if you wish to generate and/or view BPEL processes, then

2) SOA Development->JBoss BPEL Editor from: http://download.jboss.org/jbosstools/updates/stable/helios/

The example project used above can be found here: http://downloads.jboss.org/savara/releases/2.0.0.M2/samples.zip


The details for this release can be found here: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310870&version=12316056

Savara at last years SOA and Cloud Symposium

Last year in Berlin I had the fortune to speak back to back at the SOA and Cloud Symposium and then at JBoss World.

The SOA and Cloud Symposium released the following recording of the talk. Hope you enjoy it.

Happy to send the ppt to anyone that wants it. Just email me at steve.ross-talbot@cognizant.com.

Cheers

Steve T

First glimpse of the BPMN2 editor that will be used in Savara

Red Hat recently commissioned the development of a BPMN2 editor from a company called Codehoop. This editor will become the core of the BPMN2 based tooling in Savara - hopefully starting to appear in the near future.

The guys at Codehoop have done a great job! And here is a couple of movies they have put together to help users install the editor and view the OMG BPMN2 examples.

http://vimeo.com/ahtik/installing-bpmn2-editor

http://vimeo.com/ahtik/exploring-bpmn2-omg-samples

Note: the editor is based on Graphiti, which is only at version 0.7.1, and an early version of the Eclipse BPMN2 meta-model, so this is still a work in progress. So expect to find issues with any of the new technologies. However I would encourage you to download the editor and have a play.

The current editor provides the base level capabilities for creating a BPMN2 compliant model and diagram. However as with any new UI, there are areas where usability improvements would be required. This is work that will happen over the coming months, so feel free to express your views on how the use experience can be improved.

At the moment the issue reporting for the editor is through the jBPM project, using the 'Eclipse' component. However we are working towards moving this editor to Eclipse.org .... so watch this space.

Savara goes TAPless

Before anyone gets too excited, let me explain.

Savara 1 recently introduced the concept of the Testable Architecture Project (TAP). This is an XML representation of (as the name suggests) a testable architecture project, defining the different artifacts associated with the stages of the software development lifecycle, and the dependencies between them.

Savara 1 has been primarily focused on the Eclipse environment, and therefore a mechanism was needed to define the artifact dependencies, so that the static validation between various artifacts could be triggered when a change occurred.

However we always had an eye on the future, and that Savara 1 should ideally be working with an SOA repository, and that Savara 2 would be more web centric than Eclipse based. So the problem the TAP was attempting to address was to enable dependencies to be represented when no repository was available.

The problem it introduced was how the dependencies in the TAP would be synchronized with the dependencies that may be defined when those artifacts were also stored in a repository. This was one of the main objections raised to the use of the TAP on the Savara forums, but at the time it was difficult to see how dependency information could be managed without being fully dependent upon the artifacts being stored in the repository - i.e. static validation would only occur when changes were made and committed back to the repository.

However now there may be light at the end of the tunnel. There have been discussions about the creation of a general purpose repository project, with profiles suitable for specific domains (e.g. rules and SOA). There is potential for the Savara project to feed in its requirements, and help contribute to this repository project, to find a solution that would work with and without a repository being available (i.e. online).

Watch this space ........

SAVARA 1.1.0.CR1 Released

We are pleased to announce the release of version 1.1.0.CR1 of SAVARA.

The main new features within this release are service validators for Web Services based on the jbossws-native stack (which includes BPEL processes deployed in RiftSaw), and the first use of the TAP (Testable Architecture Project) file as a means of representing artifacts and their relationships, and being able to validate them.

This new functionality can also be seen in the movies located here.

The detailed release notes can be found at:
https://jira.jboss.org/secure/ReleaseNote.jspa?projectId=12310870&version=12315104

Testable Architecture in action

A new "movies" page has been added to the Savara project website: http://www.jboss.org/savara/documentation/movies.html

These short movies demonstrate the use of Testable Architecture, at various stages in the software development lifecycle, using the purchasing example that is distributed with Savara.

The version of the software used in the demo is JBoss Tools 3.2.0.Beta1 and Savara 1.1.0.M1 - both versions will be released very shortly.

SAVARA 1.0.0.Final Released

We are pleased to announce that version 1.0.0.Final of SAVARA has been released.

This is the first release of the SAVARA project, which aims to deliver a methodology and tools to support the concept of Testable Architecture. This first release provides the following:

1) An initial version of the Testable Architecture methodology. This can be found on the Savara documentation page. It provides guidance on the type of artifacts that should be defined at each stage of the software development lifecycle, and how these can be used in a testable manner. The Getting Started Guide provides an illustration of how this methodology can be applied in the context of the distributed samples.

2) Design-time tool capabilities include:

a) Integration with pi4soa WS-CDL choreography and scenario design tools, with simulation support for testing scenarios against a choreography

b) BPMN (version 1) export from a Choreography (currently just used for documentation purposes)

c) HTML documentation generation from a Choreography

d) WSDL generation from a Choreography

e) WS-BPEL generation from a Choreography (created as a JBoss Tools compatible BPEL project for deployment in RiftSaw)

3) Runtime capabilities include:

a) JBossESB service validation against a Choreography



The release can be found on the download page as a binary distribution, containing documentation, samples and the runtime service validation components, and an Eclipse update site for the design-time tools. Pre-requisites and installation instructions can be found in the Getting Started Guide.