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.
When a choreography description has been created, it is possible to generate a BPEL Process (and associated WSDL files and deployment descriptor) for each of the participants defined within the choreography. To try this out, select the
Savara->Generate->Service
menu item from the popup menu associated with the
architecture/PurchaseGoods.bpmn
.
This will display a dialog listing the possible services that can be generated from this choreography, with a proposed Eclipse project name, and the option to select a service type.
Press the 'Ok' button and this will create a single a BPEL project for the Store , Logistics and CreditAgency participants.
Each project will contain a single
bpelContent
folder containing the WS-BPEL process definition for the participant, a list of relevant WSDL files and a deployment descriptor file for use with any Apache ODE based engine (e.g. RiftSaw). However the WS-BPEL and WSDL files are standard, so can be deployed to any WS-BPEL 2.0 compliant engine.
The SAVARA tools include the ability to statically verify the external observable behaviour of a BPEL process definition against other artifacts (e.g. a scenario).
To verify a scenario against one or more BPEL process definitions, open the scenario in the editor and select the green play button. When the dialog is displayed, select the BPEL process associated with the role being simulated. For example, the
Store
role should be associated with the generated
PurchaseGoods_Store.bpel
, the
CreditAgency
role associated with the
PurchaseGoods_CreditAgency.bpel
, etc. When the OK button is pressed, the simulation will be performed against the selected BPEL process definitions.
'Static' verification refers to the fact that a protocol description is derived from the BPEL process, describing the communications behaviour of the process. It is this protocol description that is validated against other artifacts - in this case a scenario.
In contract, a dynamic verification would involve actually executing an instance of the BPEL process, to determine whether it correctly behaves when presented with a series of sample (simulated) use cases. We hope to be able to support this functionality in the near future.
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.
When a choreography description has been created, it is possible to generate a SCA Java implementation (and associated WSDL files and SCA composite descriptor) for one or more of the participants defined within the choreography. To try this out, select the
Savara->Generate->Service
menu item from the popup menu associated with the
architecture/PurchaseGoods.bpmn
.
This will display a dialog listing the possible services that can be generated from this choreography, with a proposed Eclipse project name, and the option to select a service type (in this case SCA Java ).
Press the 'Ok' button and this will create a Java project for the Store , Logistics and CreditAgency participants.
Each project will be generated as a Java project, containing the relevant Java interfaces and classes for the service implementation, the WSDL and XSD files for the public service interface, and the SCA composite descriptor.
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.
Figure 6.4. Scenario simulation configured for validating the SCA Java implementation for the Store role
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:
Figure 6.5. Result of simulating the Store role, within the Successful Purchase scenario, against the SCA Java implementation
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
*
*/
@javax.jws.WebService(
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());
@Reference
public CreditAgency creditAgency;
@Reference
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");
System.out.println(content);
try {
org.jboss.examples.creditagency.CreditCheckType check=
new org.jboss.examples.creditagency.CreditCheckType();
check.setId(content.getId());
check.setCustomer("C104536");
org.jboss.examples.creditagency.CreditRatingType rating=
creditAgency.creditCheck(check);
System.out.println("RATING="+rating);
if (rating.getRating().intValue() > 5) {
org.jboss.examples.logistics.DeliveryRequestType deliveryRequest=
new org.jboss.examples.logistics.DeliveryRequestType();
deliveryRequest.setId(content.getId());
deliveryRequest.setAddress("1001 Acme Street");
org.jboss.examples.logistics.DeliveryConfirmedType delivery=
logistics.delivery(deliveryRequest);
org.jboss.examples.store.BuyConfirmedType _return =
new org.jboss.examples.store.BuyConfirmedType();
_return.setId("1");
_return.setAmount(BigInteger.valueOf(500));
return _return;
} else {
org.jboss.examples.store.BuyFailedType buyFailed =
new org.jboss.examples.store.BuyFailedType();
buyFailed.setId("1");
throw new org.savara.examples.store.InsufficientCreditFault("Buy failed", buyFailed);
}
} catch(org.savara.examples.creditagency.CustomerUnknownFault cuf) {
AccountNotFoundType anft=new AccountNotFoundType();
anft.setId(content.getId());
anft.setReason("Don't know you");
throw new AccountNotFoundFault("Account not found", anft);
}
}
}