The Savara Eclipse tooling includes the ability to generate services from source models. These models can vary, including (currently) choreographies and BPEL process definitions.
Select the "Savara->Generate->Service" menu item associated with the context menu of the source model. For example,
This will display a dialog window to allow the user to select how each role, identified within the source model, should be generated as a service design or implementation:
Figure 5.2. Dialog for specifying the service generation information information for each role in the source model
The "Service Role" check box is used to indicate whether that role, within the source model, should result in a service being created.
The "Project Name" field is used to enter the name of the project that will be generated. The project name is constructed from a combination of the model name and the role. If the project already exists, then the background of this field will be red, and the OK button will be disabled until either the service role checkbox for that role is unchecked, or the project name changed.
The "Service Type" field displays a list of service generation types. This list will be dependent upon the source model type, and so will not be discussed in detail here. The particular structure of each generated project will be dependent upon the service type selected. Some of these service types will relate to implementation technologies (e.g. SCA Java and BPEL), while others may be used to represent a service design (e.g. BPMN2 Process - although a BPMN2 Process can also evolve into an executable implementation).
When the OK button is pressed, each of the projects for the enabled roles will be created with their relevant artifacts.
NOTE: The list of target 'service types' is not related to the source model type. So (for example) if the source model is a BPEL process definition, then it is still possible that BPEL will be offered as a target service type. Although this may seem redundant, it can offer the opportunity to generate a abstract skeleton (observable behavior) version of a fully implemented executable BPEL process.
A Service Design or Implementation can be verified in two ways.
For service designs, which have no executable semantics (i.e. cannot be executed), or implementations where no simulator exists that can perform dynamic verification, it may be possible to simulate valid behavior (as defined by a set of scenarios) against the protocol derived from the service design/implementation.
This ensures that the design or implementation has the correct communications structure to be able to interact with other services (whether consumers or other producers).
For example, a scenario can be simulated against a BPEL process definition (and in the near future a BPMN2 process model) to determine whether they have the correct communication structure, even before they contain enough details to be executed.
Where a simulator exists associated with the service implementation technology, it is possible to replay the message events defined in the scenarios against an executing version of the service implementation, to ensure that a real service instance handles the scenario correctly.
For example, a scenario can be simulated against a SCA composite definition. (Switchyard services will be supported in the near future).