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
Tuesday, 19 October 2010
Wednesday, 6 October 2010
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.
Thursday, 19 August 2010
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.
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.
Wednesday, 21 July 2010
CSC support for Savara Open Source Project
CSC are pleased to support SAVARA methodology and are keen to investigate the usage of testable architectures/ modelling and simulation in addition to their industry standard and approved methods for solution development. CSC looks forward to benefiting from the deliverables / outcomes delivered by the SAVARA project.
Friday, 2 July 2010
SAVARA 1.0.0.CR2 Released
We are pleased to announce the release of version 1.0.0.CR2 of SAVARA.
This release is primarily a bug fix release, with a number of issues being resolved with the BPEL and WSDL generation.
The detailed release notes can be found at:
https://jira.jboss.org/secure/ReleaseNote.jspa?projectId=12310870&version=12314160
This release is primarily a bug fix release, with a number of issues being resolved with the BPEL and WSDL generation.
The detailed release notes can be found at:
https://jira.jboss.org/secure/ReleaseNote.jspa?projectId=12310870&version=12314160
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
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
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
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
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.
• 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.
Subscribe to:
Posts (Atom)