JBoss.orgCommunity Documentation

Getting Started Guide

Testable Architecture

This section describes the installation procedure for the SAVARA tools.

The installation instructions for the SAVARA Eclipse tools are:

Download the latest version of Eclipse JEE, from http://www.eclipse.org , and install in your environment.

  • Savara Eclipse Tools

Start up your Eclipse environment, and go to the Help->Install New Software.. menu item. Select the appropriate update site URL from the SAVARA Downloads page. Once the contents of the update site is available, then select the Savara and Savara Dependencies categories and follow the instructions to install them within your Eclipse environment.

One of the stages within the architecture phase is to define the information model for the message types associated with the messages exchanges between the interacting participants.

This involves defining message schema for each example message. The schema could already exist and be reused, it could be based on existing schema and just need to be upgraded to support new requirements, or it may need to be defined from scratch.

An example of a schema associated with the purchasing model is the store.xsd shown here:

Once the schema has been defined, then the example messages need to be updated to reference the schema, as shown in the following BuyRequest.xml example message:

The next step in the development process is to specify a Choreography Model to implement the requirements described within the set of scenarios. Information on how to build a choreography can be found in the User Guide.

The choreography description for the Purchasing example can be found in purchasing/architecture/PurchaseGoods.bpmn , and looks like this:

The SAVARA tools can be used to validate the scenarios against the choreography description, to ensure that the choreography correctly implements the requirements. To test the requirements/SuccessfulPurchase.scn scenario against the choreography, launch the scenario editor by double-clicking on the scenario file, and then pressing the green play button in the toolbar. This will display a dlalog window used to configure what models and simulators are used for each role in the scenario:

When simulating all roles against a single model (i.e. a choreography), then simply browser for the model (using the ... button) - which in this case is the PurchaseGoods.bpmn file in the same Eclipse project (architecture folder), and then when asked "Should model be set for all roles", press the "Yes" button. This will setup the simulation configuration for all roles:

The simulators are all automatically initialised to "Protocol simulator", as this is the only simulator that supports the ".bpmn" type of model, and the model roles are initialised on a best guess basis. If the roles in the scenario are completely different names to the ones in the model (i.e. choreography), then the user will need to select the appropriate model roles to map from the scenario roles.

When the "Simulate" button has been pressed, and the simulation is complete, the scenario should look like the following image, indicating that the scenario completed successfully.

To view a scenario that demonstrates a test failure, open the requirements/InvalidStoreBehaviour.scn scenario by double-clicking on the file, and then initiate the test using the green play button in the toolbar. When complete, the scenario should look like the following image.

You will notice that the Store participant has a red 'send' node, indicating that this action was not expected behaviour when compared with the choreography description. The reason this is considered an error, is that the Store participant should only send an AccountNotFound message following a customer unknown response from the credit agency.

When an error is detected in a scenario, the architect can then determine whether the scenario is wrong (i.e. it does not correctly describe a business requirement), or whether the choreography is wrong and needs to be updated to accommodate the scenario.

At this point in the lifecycle, various activities would occur related to reviewing services (i.e. in a SOA Repository) and understanding whether existing services meet requirements, need to be modified, or whether new services need to be developed from scratch.

Services can be developed by generating initial development artifacts, based on artifacts created in preceding phases (e.g. architectural model or service contracts/designs).

To ensure that the services continue to conform to the artifacts defined in the previous phases, the tools will (eventaully) perform conformance checking between the service implementation and the existing architecture/design artifacts. This is not possible with all implementation languages - they must provide the means to extract the communication structure for comparison.

The following sections explain how the generation can be achieved for the WS-BPEL and SCA Java implementations.

The tools include a capability to generate a service implementation, for a participant in a choreography, using WS-BPEL.

This section shows how to generate SCA Java based services from a choreography, add implementation details to the service and then verify it against scenarios.

In a previous section of the document, it showed how to use the Scenario (that represents a particular use case or requirement) to verify an architectural model (or choreography). The same scenarios can be used to test the service implementations generated from those architectural models or designs.

For example, to test the SCA Java implementation for the Store participants, you open the requirements/SuccessfulPurchase.scn scenario and press the green "play" button in the toolbar. This will show the 'scenario simulation' dialog. Then for the Store role, select the relevant composite file, so for the Store role locate the Store.composite file in the PurchaseGoods-Store/src/main/resources folder:

When the SCA composite has been selected, then it will automatically set the simulator to be "SCA simulator" and clear the model role - this is because the model role is not relevant as the service implementation represents a single role, rather than a collection of roles as in the case of a choreography being used for the model.

Next press the "Simulate" button. Unlike the verification against a choreography model, which is pure simulation, when the SCA simulator is used and configured with a particular SCA composite file, then the simulation is performed by executing the service implementation. The simulation output is the same though:

Note however, before being able to verify the SCA Store implementation through simulation, you will need to implement the service logic. Initially it will be created as a skeleton. The following is a completed version of the org.savara.examples.store.StoreImpl class:

package org.savara.examples.store;

import java.math.BigInteger;
import java.util.logging.Logger;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
import javax.xml.bind.annotation.XmlSeeAlso;

import org.savara.examples.creditagency.CreditAgency;
import org.savara.examples.logistics.Logistics;
import org.jboss.examples.store.AccountNotFoundType;
import org.oasisopen.sca.annotation.Reference;

 * This class was generated by Apache CXF 2.4.0
 * 2012-02-08T10:25:28.453Z
 * Generated source version: 2.4.0

                      serviceName = "StoreService",
                      portName = "StorePort",
                      targetNamespace = "http://www.savara.org/examples/Store",
                      wsdlLocation = "wsdl/PurchaseGoods_Store.wsdl",
                      endpointInterface = "org.savara.examples.store.Store")

public class StoreImpl implements Store {

    private static final Logger LOG = Logger.getLogger(StoreImpl.class.getName());

    public CreditAgency  creditAgency;

    public Logistics  logistics;

    /* (non-Javadoc)
     * @see org.savara.examples.store.Store#buy(org.jboss.examples.store.BuyRequestType  content )*
    public org.jboss.examples.store.BuyConfirmedType buy(org.jboss.examples.store.BuyRequestType content) throws InsufficientCreditFault , AccountNotFoundFault    {
        LOG.info("Executing operation buy");
        try {
        	org.jboss.examples.creditagency.CreditCheckType check=
        			new org.jboss.examples.creditagency.CreditCheckType();

        	org.jboss.examples.creditagency.CreditRatingType rating=


        	if (rating.getRating().intValue() > 5) {
	        	org.jboss.examples.logistics.DeliveryRequestType deliveryRequest=
	    			new org.jboss.examples.logistics.DeliveryRequestType();
	        	deliveryRequest.setAddress("1001 Acme Street");

	        	org.jboss.examples.logistics.DeliveryConfirmedType delivery=

	            org.jboss.examples.store.BuyConfirmedType _return =
	            		new org.jboss.examples.store.BuyConfirmedType();
	            return _return;
        	} else {
	            org.jboss.examples.store.BuyFailedType buyFailed =
	            		new org.jboss.examples.store.BuyFailedType();

	            throw new org.savara.examples.store.InsufficientCreditFault("Buy failed", buyFailed);
        } catch(org.savara.examples.creditagency.CustomerUnknownFault cuf) {
        	AccountNotFoundType anft=new AccountNotFoundType();
        	anft.setReason("Don't know you");
        	throw new AccountNotFoundFault("Account not found", anft);