{section}
{column}
h1. Definition
{column}
{column:width=350px}
{panel:title=Table of contents}{toc}{panel}
{column}
{section}
h2. Sketch (Dictionary)
\\
{quote}
*Sketch:*
1. A hasty or undetailed drawing or painting often made as a preliminary study.
2. A brief general account or presentation; an outline.
{quote}
\\
Source: [http://www.thefreedictionary.com/sketch]
A synonym (and transparent word in French) is [*croquis*|http://encyclopedia.thefreedictionary.com/croquis].
h2. Sketch projects
Petals Studio introduced the notion of sketch (or croquis, that's the same) for BPEL and SCA.
These two technologies are supported by Petals ESB through two dedicated Petals components. However, BPEL processes and SCA applications running in Petals must respect some constraints that do not apply in other servers (e.g. Apache ODE, Apache Tuscany, OW2 FraSCAti...). Indeed, such elements are always service providers, but can also be service consumers. The constraints that Petals sets are about these consumers: *any service being consumed by SCA or BPEL in Petals must be a Petals service*.
* A BPEL process is a service itself. And it calls (consumes) other services to orchestrate them.
* An SCA application may have reference towards other services. An SCA reference indicates a dependency and an invocation target at runtime.
For both of them, running in Petals imply they can only call Petals services.
If the calls did not target Petals services, then the messages would not go through the bus.
And therefore, the bus would be useless for them.
\\
*When you want to create a BPEL process or an SCA application for Petals ESB with the Petals Studio, you must first create a sketch project.*
With a sketch project, you do not have to worry about whether a consumed service is a Petals service or not.
A sketch project allows you to design your BPEL process (or your SCA application) independently of Petals constraints.
Such a project can then be transformed into a set of concrete Petals projects, updating if necessary the SCA or BPEL artifacts to make them run in Petals.
h1. Motivation
The interest of going through a sketch project may not be trivial at first glance.
Let's take a look at the way it used to work before it appeared.
\\
We here use BPEL as an example, but SCA is very similar.
Formerly, you could directly create a SU project for BPEL. The wizard completed by creating a BPEL skeleton and a jbi.xml.
The export of such a project was a little more complicated that the usual SU export. During the export, the BPEL was introspected and external WSDL were imported in the archive.
Indeed, it is possible in your project to reference any WSDL, no matter where it is located (as long as the URI is valid).
\\
It sometimes happened that this export failed. Failures could occur because of bugs (it happens) or because the user had ignored some warnings or because the BPEL or the imported WSDL contained errors that were not visible during the edition. In all the cases, an export failure meant you had no service assembly to deploy. Most of the time, you were stuck to create your SA by hand.
{tip}
Sketch projects have a similar export, that import remote files when needed, but they provide an intermediary step.
The export does not result in a service assembly, but in a set of SU and SA projects.
These projects can be updated afterwards if necessary.
{tip}
\\
Besides, the former export for BPEL SU projects could only be made in the studio.
There was no way to automatize the export, unlike other service-unit types (SOAP, FTP...) where Maven can be used.
{tip}
A sketch project export results in a set of SU and SA projects, which are compatible with the Petals Maven plug-in.
{tip}
\\
Eventually, we mentioned the fact that a BPEL could reference any WSDL and these WSDL had to represent Petals services in order for this BPEL to run into Petals ESB.
Fact is: it is not possible, from a WSDL, to determine if the associated service is already deployed into Petals.
* First, the studio may be unable to find a service-unit that matches this WSDL (it may in some cases, but not always).
* And then, we cannot simply use the interface, service and end-point names to compare 2 WSDL definitions. Compare types would be good, but is expansive.
What it means is that it is not possible to determine if a BPEL is ready to run into Petals simply from the process definition.
It is up to the user to determine it.
{tip}
A sketch project export results in a set of SU and SA projects.
The SU projects that are proposed include the import of all the invoked services into Petals ESB (which is useful if the orchestrated services are outside Petals).
The sketch project may define a BPEL that may not run into Petals ESB, and be adapted to run into Petals ESB during the sketch export.
{tip}
\\
These 3 points explain why sketch projects were introduced.
Despite the relative inconvience they might represent at first glance, they really solve annoying issues.
They allow to create complete BPEL processes and SCA applications for Petals ESB, in a clean way.
h1. Sketches in action
Sketch projects are created using the Petals Sketch wizard (*File > New > Petals > Sketch project*).
!PetalsStudio_Sketch_1.jpg!
\\
The export of a sketch project results in the introspection of the created element (*.bpel or \*.composite) and in the proposals of SU and SA projects to create.
!PetalsStudio_Sketch_2.jpg!
\\
The creation and the export of a sketch project are detailed more precisely in tutorials about BPEL and SCA.
{column}
h1. Definition
{column}
{column:width=350px}
{panel:title=Table of contents}{toc}{panel}
{column}
{section}
h2. Sketch (Dictionary)
\\
{quote}
*Sketch:*
1. A hasty or undetailed drawing or painting often made as a preliminary study.
2. A brief general account or presentation; an outline.
{quote}
\\
Source: [http://www.thefreedictionary.com/sketch]
A synonym (and transparent word in French) is [*croquis*|http://encyclopedia.thefreedictionary.com/croquis].
h2. Sketch projects
Petals Studio introduced the notion of sketch (or croquis, that's the same) for BPEL and SCA.
These two technologies are supported by Petals ESB through two dedicated Petals components. However, BPEL processes and SCA applications running in Petals must respect some constraints that do not apply in other servers (e.g. Apache ODE, Apache Tuscany, OW2 FraSCAti...). Indeed, such elements are always service providers, but can also be service consumers. The constraints that Petals sets are about these consumers: *any service being consumed by SCA or BPEL in Petals must be a Petals service*.
* A BPEL process is a service itself. And it calls (consumes) other services to orchestrate them.
* An SCA application may have reference towards other services. An SCA reference indicates a dependency and an invocation target at runtime.
For both of them, running in Petals imply they can only call Petals services.
If the calls did not target Petals services, then the messages would not go through the bus.
And therefore, the bus would be useless for them.
\\
*When you want to create a BPEL process or an SCA application for Petals ESB with the Petals Studio, you must first create a sketch project.*
With a sketch project, you do not have to worry about whether a consumed service is a Petals service or not.
A sketch project allows you to design your BPEL process (or your SCA application) independently of Petals constraints.
Such a project can then be transformed into a set of concrete Petals projects, updating if necessary the SCA or BPEL artifacts to make them run in Petals.
h1. Motivation
The interest of going through a sketch project may not be trivial at first glance.
Let's take a look at the way it used to work before it appeared.
\\
We here use BPEL as an example, but SCA is very similar.
Formerly, you could directly create a SU project for BPEL. The wizard completed by creating a BPEL skeleton and a jbi.xml.
The export of such a project was a little more complicated that the usual SU export. During the export, the BPEL was introspected and external WSDL were imported in the archive.
Indeed, it is possible in your project to reference any WSDL, no matter where it is located (as long as the URI is valid).
\\
It sometimes happened that this export failed. Failures could occur because of bugs (it happens) or because the user had ignored some warnings or because the BPEL or the imported WSDL contained errors that were not visible during the edition. In all the cases, an export failure meant you had no service assembly to deploy. Most of the time, you were stuck to create your SA by hand.
{tip}
Sketch projects have a similar export, that import remote files when needed, but they provide an intermediary step.
The export does not result in a service assembly, but in a set of SU and SA projects.
These projects can be updated afterwards if necessary.
{tip}
\\
Besides, the former export for BPEL SU projects could only be made in the studio.
There was no way to automatize the export, unlike other service-unit types (SOAP, FTP...) where Maven can be used.
{tip}
A sketch project export results in a set of SU and SA projects, which are compatible with the Petals Maven plug-in.
{tip}
\\
Eventually, we mentioned the fact that a BPEL could reference any WSDL and these WSDL had to represent Petals services in order for this BPEL to run into Petals ESB.
Fact is: it is not possible, from a WSDL, to determine if the associated service is already deployed into Petals.
* First, the studio may be unable to find a service-unit that matches this WSDL (it may in some cases, but not always).
* And then, we cannot simply use the interface, service and end-point names to compare 2 WSDL definitions. Compare types would be good, but is expansive.
What it means is that it is not possible to determine if a BPEL is ready to run into Petals simply from the process definition.
It is up to the user to determine it.
{tip}
A sketch project export results in a set of SU and SA projects.
The SU projects that are proposed include the import of all the invoked services into Petals ESB (which is useful if the orchestrated services are outside Petals).
The sketch project may define a BPEL that may not run into Petals ESB, and be adapted to run into Petals ESB during the sketch export.
{tip}
\\
These 3 points explain why sketch projects were introduced.
Despite the relative inconvience they might represent at first glance, they really solve annoying issues.
They allow to create complete BPEL processes and SCA applications for Petals ESB, in a clean way.
h1. Sketches in action
Sketch projects are created using the Petals Sketch wizard (*File > New > Petals > Sketch project*).
!PetalsStudio_Sketch_1.jpg!
\\
The export of a sketch project results in the introspection of the created element (*.bpel or \*.composite) and in the proposals of SU and SA projects to create.
!PetalsStudio_Sketch_2.jpg!
\\
The creation and the export of a sketch project are detailed more precisely in tutorials about BPEL and SCA.