Tuesday, 15 June 2010

SAVARA 1.0.0.CR1 Released

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

This release has resulted in a number of significant changes to the structure of the project. Rather than have three separate distributions, we have consolidated all functionality into one main distribution, and an Eclipse update site for the plugins (see downloads page for the URL).

The functionality associated with 'conversation aware' ESB actions has been removed from the main distribution, and moved into a separate 'experimental' branch. This work has provided some useful insight in to some possible features for the future, however the ideas are not mature enough to remain as part of the first release.

NOTE: The annotation used for runtime validation has been renamed. Therefore if any choreographies have been written, that include this annotation, you will need to update the annotation name and the top level node of the XML fragment included in the annotation, from 'jbossesb' to 'validator'. This can either be achieved by creating new annotations and copying the destinations, or by opening the .cdm files in a text editor, and updating the elements directly.

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

Friday, 26 March 2010

Why Pi?

SAVARA is about Enterprise Modelling, and ensuring that artifacts created through the development lifecycle are verified for consistency, to ensure the original business requirements are implemented in the deployed solution. So generally we don't talk about the lower level concepts that underpin this work, its not relevant to an architect, service designer or developer - they simply want the benefits that a Testable Architecture can offer.

However, it was with great sadness that we learnt that the inventor of the Pi Calculus, Professor Robin Milner, passed away last weekend. So in honour of Robin, we wanted to describe how important Pi Calculus is for computer science in general, and more specifically to the future of the SAVARA project.

The Pi Calculus provides a concise mathematical notation for expressing all of the constructs necessary to describe the concurrent communicating behaviour of a set of participants. Having such a description enables analysis to be performed, specifically to determine if those interactions will lead to undesirable consequences, such as livelocks or deadlocks. Another important goal is to check conformance or compatibility of communication behaviour between two or more parties that are interacting. This ensures that whenever one party sends a message to another party, the recipient is in a suitable state to be able to receive and handle that message type. All of these properties are required when verifying artifacts as part of Testable Architecture.

The work we are doing with our academic colleagues, led by Dr Kohei Honda and Dr Nobuko Yoshida, in consultation with Robin, has built upon the Pi Calculus with the concept of the global model. This uses the Pi Calculus notation to describe the behaviour from a participant neutral perspective, rather than each participant's behaviour individually - equivalent to the distinction between a choreography (e.g. WS-CDL) against a process model (e.g. WS-BPEL). Using a global model enables deadlock/livelock freedom by design, assuming that certain properties are adhered to, by simply ensuring that all participants conform to the global model.

To the best of our knowledge, currently there are no products or standards that are truely based on the Pi Calculus, or leverage the type theory to detect livelocks or deadlocks. They may claim to be based on it, but in reality they are just using some of the concepts, like parallelism, recursion, choice, etc. The same is true for the first version of SAVARA, it is based on an informal 'interpretation' of this work.

However, the work we are now doing with our academic partners should deliver an enterprise tool that truely leverages the Pi Calculus to help build type safe (deadlock and livelock free) distributed systems. This will also provide a more formal basis for other reasoning and analysis, as may be needed to ensure that the solution meets all of the constraints upon it, and is not merely a heuristic approximation to the desired outcome.

The work of Robin and his colleagues in developing the Pi-Calculus informs us and guides us in what we do in SAVARA, and without his contribution SAVARA would never have existed in the first place.

Robin was always seeking real world examples to give further meaning to his research. The fruitful collaboration that started in the early days of WS-CDL, and now embodied in SAVARA, are a testament to Robin and his desire for ever more grounded and meaningful collaboration.




Gary Brown and Steve Ross-Talbot

Thursday, 4 March 2010

Architecting the Enterprise with SAVARA

The properties of Testable Architecture discussed in more detail in DZone article:

http://architects.dzone.com/articles/savara-architecture

Wednesday, 3 February 2010

Properties of a Testable Architecture

When producing a recent presentation for SAVARA, I found a useful way to characterise SAVARA was in terms of the following set of properties:

• Accurancy: Each stage of the Software Development Lifecycle is validated to ensure it conforms to artifacts in preceding stages, to check that each stage accurately reflects the original business requirements. This ensures misalignment to the business requirements is detected at the earliest possible stage.

• Efficiency: Having a strong and detailed contract between each stage of the Software Development Lifecycle, as well as between individual components (i.e. services) within the architecture, means there is less room for ambiguity, making the development process more efficient (especially when dealing with a large and geographically distributed development team).

• Quality: Having the continual testing and validation at each stage improves the level of quality, with in some cases the tests being derived from the requirements (i.e. scenarios), removing the need to manually create tests based on a potentially incorrect interpretation of the business requirements. This ensures defects are detected at the earliest possible stage.

• Fidelity: Ensuring that the executing solution continues to behave according to the architecture and original business requirements, even where some of the components (i.e. services) are obtained from third parties. This provides a form of Business Activity Monitoring driven from the architectural specification.

Wednesday, 23 December 2009

Movie: Tutorial 1 - Business Analysis Iteration 1

I have produced a movie, which will be the first of a set of mini tutorials, to demonstrate both the SAVARA methodology and tooling.

The first tutorial can be found at: http://downloads.jboss.org/savara/tutorials/Tutorial_1_BusinessAnalysis_Iteration_1

This tutorial covers the following:
  • Defining the participants and relationships between them
  • Creating a scenario to represent a business requirement
  • Creating example messages for use with the scenarios
  • Specifying the initial architectural model defined using a Choreography Description
  • Verifying that the architectural model meets the business requirements

DZone Q&A on SAVARA

There is a Q&A session on SAVARA at: http://www.dzone.com/links/qa_creating_testable_architectures_with_savara.html

Unfortunately there are some transcription errors - so may be best to listen to the podcast of the actual interview :)

Friday, 18 December 2009

SAVARA 1.0 Milestone 1 Released

We are pleased to announce the first milestone release for SAVARA 1.0.

More details about the release can be found at: http://community.jboss.org/thread/146018?tstart=0