SAVARA

Generating SwitchYard BPEL applications

2011-10-18T08:00:00.000-07:00

With the release of Savara Eclipse Tools 2.0.0.M5, it is now possible to generate BPEL projects that can be deployed to the new jboss.org ESB called SwitchYard. This post explains how to generate an example application and deploy it to the ESB. BPEL support will be available in version 0.3 of SwitchYard, due to be released early November 2011.

Setting up your Eclipse environment

First step is to set up your Eclipse environment. If you don't already have an Eclipse environment, then we suggest downloading the JEE version of Indigo from http://www.eclipse.org/downloads/.

Once you have installed Eclipse, run it up and go to the Help->Install New Software menu item. Enter the Savara Update Site (http://downloads.jboss.org/savara/releases/updates/2.0.x) location into the top text field and press the return key. In the main panel it will show a tree with the categories Savara and Savara Dependencies at the top level. Select both of these categories, and then press the Finish button. Follow the instructions presented by the update manager until you will be requested to restart your Eclipse environment.

Importing the Purchasing Example project

The purchasing example can be found here: http://downloads.jboss.org/savara/examples/purchasing.zip

Once this file has been downloaded, go to the Eclipse environment and select the context menu from within the Project Explorer. Select the "Import ...->General->Existing Projects into Workspace" menu item, then when the dialog is displayed, choose the "Select archive file" radio button and use the "Browse" button to locate the downloaded purchasing.zip file.

When the 'Finish' button is pressed, the purchasing project will be imported into the Project Explorer.

Generate the SwitchYard BPEL Projects

When the purchasing project is expanded, you will find a choreography file in the top level folder called PurchaseGoods.cdm. Select the context menu for this file, and choose the menu item "Savara->Generate->Service", as shown in the following image:

This menu item will cause the following dialog to be displayed:

Select the 'Switchyard BPEL' Service Type for each of the service roles, and then press the 'OK' button to generate the three projects.

If you expand the PurchaseGoodsProcess-Store project, you will see that the artifacts for the Switchyard BPEL application are primarily contained within the src/main/resources folder:

Adding Implementation Details

The generated project contains an 'abstract' version of the BPEL process definition, outlining how it interacts with any consumers, or external services. However it does not contain all of the implementation logic, as this is not available within the choreography description from which the BPEL process was generated.

As a short cut, we have provided a version of the BPEL processes for this example, with the implementation details fully completed. This can be downloaded from here: http://downloads.jboss.org/savara/examples/purchasing_bpel_impl.zip

In this zip you will find three BPEL processes. These should be used to replace the generated versions - although if curious, first copy them to another location in your Eclipse environment, and perform a comparison to see the differences. For example, select the PurchaseGoodsProcess_Store.bpel from the generated project, and the version obtained from the downloaded zip, and use the "Compare With->Each Other" menu item and you will see:

The generated version on the left contains the main structure of the process, and the interaction statements (e.g. receive, reply, invoke). The 'one we prepared earlier' version on the right adds assignment and condition statements.

Running the Example

The final step is to package and deploy the SwitchYard applications. The SwitchYard version we will be using is the 0.3 AS7 based distribution. (Note: version 0.3 will be released early November 2011).

For each of the generated projects, from the project node in the explorer select "Export ..." from the context menu. From the dialog select "Java->JAR file", and in the next dialog specify the location of where the Jar should be stored. For example, you could create a Store.jar, CreditAgency.jar and Logistics.jar.

Once the SwitchYard server has been started, using the "./standalone.sh" command in the bin folder, copy the three SwitchYard BPEL applications into the $AS7/standalone/deployments folder.

When a service has been successfully deployed, you will see messages similar to the following associated with the LogisticsService:

14:46:48,820 INFO [org.apache.cxf.endpoint.ServerImpl] (MSC service thread 1-2) Setting the server's publish address to be http://127.0.0.1:18001/LogisticsService
14:46:48,858 INFO [org.jboss.as.server.controller] (DeploymentScanner-threads - 1) Deployed "Logistics.jar"

Lastly, using your favourite SOAP client (e.g. SOAPUI), send the following message to http://127.0.0.1:18001/StoreService:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:stor="http://www.jboss.org/examples/store"> <soapenv:Header/>
<soapenv:Body>
<stor:BuyRequest id="1" product="bike" customer="Joe"/>
</soapenv:Body>
</soapenv:Envelope>

you will get a response:

<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
<soap-env:Header>
<soap-env:Body>
<BuyConfirmed id="1" xmlns="http://www.jboss.org/examples/store" />
</soap-env:Body>
</soap-env:Header>
</soap-env:Envelope>

If you now change the request so the customer is "Fred", then you will receive an 'AccountNotFound' fault.

Savara 2.0.0.M4 is released with initial BPMN2 and SCA support

2011-07-21T06:25:00.000-07:00

The Savara team are pleased to announce the release of milestone 4 of Savara 2.0. The Savara project provides tools in support of the Testable Architecture methodology, which aims to ensure that artifacts defined at different stages of the software development lifecycle are valid against each other, ensuring that the delivered system meets the original business requirements.

The main new features in this release are:

First 'technical preview' of the choreography to BPMN2 process model generation. Currently this still uses the WS-CDL based choreography, but will use the BPMN2 choreography model in a future release.

Generation of SCA Java based service implementations from a choreography. This creates a Java project, including the SCA composite descriptor, WSDL and XSD files (representing the external service contract), the Java interfaces and template Java service implementation class.

Update to simulation framework, to enable different roles within a scenario to be simulated against different models.

SCA Simulator, to enable a scenario to be simulated against SCA Java based service implementations.

Upgrade to latest version of Scribble (draft 1.0 version of protocol spec). Scribble is a notation for representing protocols, and provides the underlying canonical model for describing behaviour across artifacts in Savara.

Many bug fixes.

Full details can be found here: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310870&version=12316424

Scenario format and editor changed in Savara 2.0.0.M2

2011-04-07T09:10:00.000-07:00

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

2011-04-07T07:30:00.000-07:00

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

2011-04-06T05:18:00.000-07:00

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

2011-02-11T15:37:00.000-08:00

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

2010-10-19T13:43:00.000-07:00

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

2010-10-06T10:12:00.000-07:00

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

2010-08-19T03:26:00.000-07:00

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.

CSC support for Savara Open Source Project

2010-07-21T06:40:00.000-07:00

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.

SAVARA 1.0.0.CR2 Released

2010-07-02T15:02:00.000-07:00

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

SAVARA 1.0.0.CR1 Released

2010-06-15T15:04:00.000-07:00

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

Why Pi?

2010-03-26T10:53:00.000-07:00

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

Architecting the Enterprise with SAVARA

2010-03-04T02:29:00.000-08:00

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

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

Properties of a Testable Architecture

2010-02-03T01:55:00.000-08:00

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.

Movie: Tutorial 1 - Business Analysis Iteration 1

2009-12-23T09:54:00.000-08:00

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

2009-12-23T03:51:00.000-08:00

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 :)

SAVARA 1.0 Milestone 1 Released

2009-12-18T10:27:00.000-08:00

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

Alignment of SAVARA (Testable Architecture) to TOGAF

2009-12-03T09:13:00.000-08:00

The importance of SAVARA becoming a standard method / toolset for enterprise and solution architects to clearly and formally describe system (collaboration / communication) architectures cannot be emphasised enough. The benefits seen in early implementations of Testable architectures (the underpinnings of SAVARA) have been impressive to say the least.

In the same light, there is an increased acceptance of enterprise architecture framework like TOGAF in the industry which enables clear architecture descriptions, reduces redundancies and improves architecture output and adds value to the business solution.

Please see the downloadable whitepaper below which brings these two methodologies together and specifies the broad alignment of SAVARA (Testable Architecture) to The Open Group Enterprise Architecture Framework (TOGAF) showcasing that SAVARA can be used in conjunction with accepted enterprise modelling languages like Archimate to describe communications architecture in formal and testable manner using simulation and visualisation.

http://docs.jboss.org/savara/whitepapers/Testable_Architecture_and_TOGAF.pdf

SAVARA and the SOA Manifesto

2009-10-27T02:37:00.000-07:00

A group of leading SOA evangelists recently met in Rotterdam to agree an "SOA Manifesto". This work resulted in a list of guiding principles that have been documented here.

Initial feedback has been positive, although one common theme through many comments has been the lack of detail. However it provides a similar level of detail as the popular Agile Manifesto, and therefore I don't see this as a major issue at this stage.

The main purpose of this meeting was to establish the high level principles. I think it is how these principles are subsequently applied that will determine the success of this manifesto.

There are a number of ways in which the SAVARA project can help support these guiding principles:

"SOA can be realized through a variety of technologies and standards."

One of the goals of SAVARA is to provide a methodology and tool framework that can accommodate various technologies and standards, in a way that can deliver a testable architecture where the different artifacts can be validated against each other.

"Identify services through collaboration with business and technology stakeholders."

The SAVARA methodology covers the complete development lifecycle, helping to capture the requirements from the business and technology stakeholders, through defining the architecture, to service identification/analysis, design, implementation and deployment.

"Verify that services satisfy business requirements and goals."

This is the main aim of a testable architecture, to ensure that the artifacts at each stage of the development lifecycle are valid compared to artifacts from preceding stages, thus ensuring that the deployed services can be shown to indirectly satisfy the original business requirements.

"Evolve services and their organization in response to real use."

Through a detailed understanding of the behaviour of a system, from requirements through to implementation, it makes it easier to accommodate changes in requirements and understand the impact of the changes on a production environment. This manageability is critical to enable a system to evolve as efficiently as possible without introducing risk to the business.

"Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change."

SAVARA enables the behavioural dependencies to be understood, thus significantly reducing the potential impact of change.

TOGAF meets Savara

2009-10-16T02:07:00.000-07:00

Last time I blogged about Togaf I said “TOGAF gives you some generic artefacts. But it is up to you to gather and decide which artefacts you need. How do you decide "what you need?" How do you know that "what you need" is "what it takes?”

Let’s focus on one single artefact: requirements.

Some of Togaf prescribed requirements are inputs or outputs to the following phases:

Preliminary Phase: Stakeholder’s requirements
Requirements Management: Requirements-related inputs/outputs from each Togaf ADM phase
Phase Architecture Vision: Business requirements, Stakeholder’s requirements
Business Architecture: Technical requirements, Business requirements
Information Systems Architectures – Data Architecture: Architecture Requirements, Data interoperability requirements, Technical requirements, Business requirements, Application requirements
Information Systems Architectures – Application Architecture: Application interoperability requirements, Technical requirements, Business requirements, Updated data requirements
Technology Architecture: Technical requirements
Opportunities & Solutions: Draft Architecture requirements, Interoperability and co-existence requirements
Migration Planning: Finalized Architecture requirements specification
Implementation Governance: Recommendations on service delivery requirements

From this large set of requirements, a subset will be used as input by solution architectures. The question that I want to pose is “how do we ensure that all artefacts created throughout the lifecycle of a software development project are verifiable against these requirements?” or more specifically “how do we know that the solution architectures we create actually meet the requirements that they are based upon?”.

Savara is your answer. Using Savara it is is possible to ensure that the delivered system conforms to the original set of requirements.

Integrating Togaf ADM and Savara puts you in the position of ensuring that the delivered systems conform to the original set of requirements.

The underpinings of this can be found in Steve’s blog where he talks about successive refinement of req uirements and models. In my next blog I want to revist this and align it more explicitly to TOGAF.

In my next blog I want to revist this and align it more explicitly to TOGAF.

More on the SOA-Manifesto

2009-10-15T07:18:00.000-07:00

I have been thinking ever more about the SOA Manifesto. In part fuelled by the proximity of the WG meeting and in part by comments that have been made.

I take on board the comments on the need for "boldness" I have never been shy about dealing with that. But we need to ensure that the manifesto has use today that is practical and very business focused - something I have picked up from the many comments made at infoQ. And we need to map out what is missing and look deeper into a brave new world that builds upon our current available SOA platforms and methods of constructing solutions.

One thing stands out for me on the practical usage side and one on the future.

On the practical side:

The use of Service Orientation is underpinned by delivering continuous business value. Business value MUST always be aligned to business goals and needs.

In the future:

It MUST be possible to express the information model(s), the static service model and the dynamic model of service collaboration such that the first describes the data needs of services, the second describes the service usage across peers of a specific service and the third describes the common collaborative behavior of peers collectively. All of which MUST be founded upon one or more business requirements.

I think these two and refinements of them will stand us in good stead. The devil is always in the detail.

The former is really motherhood and apple pie. Easy to say but how do we bake it?

The latter is more of challenge because it requires a better understanding of what underpins a distributed system in terms of behavior and information that drives that behavior and these, at the end of the day, are complex mathematical topics. We must be careful and ensure that we do not go into too much detail but provide the right syntactic sugar that allows formalism to deliver to us in a way that we can all understand and use.

Let us not forget that without mathematics we would have no computing. In fact without it we would have no engineering. They are all based on mathematics but we rarely see the models that are used to underpin engineering but in the case of computing we use those models all the time. They have syntactic sugar we call them programming languages.

A Personal Architecture Manifesto (cross blogged)

2009-10-07T06:32:00.000-07:00

Way back in 2004 a good friend of mine, Alexis Richardson, decided to convene a summit of architects. The summary of the event is below:

The Architects Summit is a one off event challenging a group of pragmatic and active technologists to formulate, document and publish a consensus view on requirements and best practice for software application platforms and development tools.

I cannot remember now how many turned up but it was well attended and amongst the participant Chris Swan and Hugh Grant were there, Rod Johnson was there, Matthew Rawlings, John Davies, Cameron Purdy and many others.

I was asked to co-chair with Alexis, presumably because chairing seems to be my thing amongst a diverse set of individuals and opinion.

The net result was certainly a stimulating debate but no manifesto was ever issued because we could not get agreement. In part this was because the camps divided into classic enterprise architects and guru-status technical architects. And never the twain can agree.

However, given the fashion for manifesto’s here is my own personal one which was done at that time and to which I still pretty well subscribe to.

Outline structure for Testable Architecture Methodology now on the wiki

2009-09-25T01:11:00.000-07:00

An outline structure for the Testable Architecture Methodology has been uploaded to the wiki. This outline is intended to help refine the phases, and steps within those phases, before the methodology is encoded using Eclipse Process Framework.

For more information please see: http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257011#4257011 and http://www.jboss.org/community/wiki/TestableArchitectureMethodology

In the press

2009-09-03T14:40:00.000-07:00

SAVARA project officially launched at JBossWorld, and on the Red Hat press blog.

Announcing the SAVARA project

2009-09-01T02:44:00.000-07:00

We are pleased to announce a new jboss community project, called Savara, established in collaboration with Cognizant (www.cognizant.com ) and Amentra (www.amentra.com ).

The purpose of this project is to develop a new methodology for Enterprise Architecture and Distributed Computing, called “Testable Architecture”, and provide appropriate tooling support.

This methodology aims to ensure that any artifacts defined during the development lifecycle can be validated against other artifacts in preceding and subsequent phases. This ensures that the final delivered system is guaranteed to meet the original business requirements. Through runtime governance, it is also possible to ensure that the running system continues to meet those requirements.

As a system evolves, through subsequent enhancements to the business requirements, having such a precise understanding of the system, from requirements, through design, implementation and deployment, enables more sophisticated change management techniques to be considered.

For more information on the project, please visit the project website.