[savara-commits] savara SVN: r427 - in trunk/docs/gettingstartedguide/src/main/en-US: module and 1 other directory.
do-not-reply at jboss.org
do-not-reply at jboss.org
Thu Sep 30 15:57:47 EDT 2010
Author: objectiser
Date: 2010-09-30 15:57:46 -0400 (Thu, 30 Sep 2010)
New Revision: 427
Added:
trunk/docs/gettingstartedguide/src/main/en-US/module/tap.xml
Modified:
trunk/docs/gettingstartedguide/src/main/en-US/master.xml
trunk/docs/gettingstartedguide/src/main/en-US/module/installation.xml
trunk/docs/gettingstartedguide/src/main/en-US/module/runtimevalidation.xml
trunk/docs/gettingstartedguide/src/main/en-US/module/servicedev.xml
Log:
Updates to getting started guide to discuss BPEL runtime validation, update installation instructions and TAP.
Modified: trunk/docs/gettingstartedguide/src/main/en-US/master.xml
===================================================================
--- trunk/docs/gettingstartedguide/src/main/en-US/master.xml 2010-09-30 17:25:15 UTC (rev 426)
+++ trunk/docs/gettingstartedguide/src/main/en-US/master.xml 2010-09-30 19:57:46 UTC (rev 427)
@@ -17,5 +17,6 @@
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/architecture.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/serviceanalysisdesign.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/servicedev.xml"/>
+ <xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/tap.xml"/>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="module/runtimevalidation.xml"/>
</book>
Modified: trunk/docs/gettingstartedguide/src/main/en-US/module/installation.xml
===================================================================
--- trunk/docs/gettingstartedguide/src/main/en-US/module/installation.xml 2010-09-30 17:25:15 UTC (rev 426)
+++ trunk/docs/gettingstartedguide/src/main/en-US/module/installation.xml 2010-09-30 19:57:46 UTC (rev 427)
@@ -14,19 +14,18 @@
The pre-requisites for the SAVARA Eclipse Tools are:
</para>
<orderedlist>
- <listitem>Eclipse JEE (3.5 or higher) <ulink url="http://www.eclipse.org">http://www.eclipse.org</ulink></listitem>
- <listitem>SAVARA (version 1.0.0.CR2 or higher), available from <ulink url="http://www.jboss.org/savara/downloads">http://www.jboss.org/savara/downloads</ulink></listitem>
- <listitem>JBoss Tools (3.1 or higher) <ulink url="http://www.jboss.org/tools">http://www.jboss.org/tools</ulink>
+ <listitem>Eclipse JEE (3.6 or higher) <ulink url="http://www.eclipse.org">http://www.eclipse.org</ulink></listitem>
+ <listitem>JBoss Tools (3.2 or higher) <ulink url="http://www.jboss.org/tools">http://www.jboss.org/tools</ulink>
available from an update site</listitem>
</orderedlist>
<para>
- The pre-requisites for the SAVARA Service Validator (for JBossESB) are:
+ The pre-requisites for the SAVARA Service Validator are:
</para>
<orderedlist>
<listitem>JBossAS (5.1.0.GA or higher) <ulink url="http://www.jboss.org/jbossas">http://www.jboss.org/jbossas</ulink></listitem>
<listitem>JBossAS (4.8 or higher) <ulink url="http://www.jboss.org/jbossesb">http://www.jboss.org/jbossesb</ulink></listitem>
- <listitem>SAVARA (version 1.0.0.CR2 or higher), available from <ulink url="http://www.jboss.org/savara/downloads">http://www.jboss.org/savara/downloads</ulink></listitem>
+ <listitem>SAVARA (version 1.1.0 or higher), available from <ulink url="http://www.jboss.org/savara/downloads">http://www.jboss.org/savara/downloads</ulink></listitem>
</orderedlist>
</section>
@@ -48,7 +47,7 @@
<para>
When Eclipse has been lauched, go to the <emphasis>Help->Install New Software..</emphasis>
menu item. Select the Eclipse update site
- for the version of Eclipse (e.g. Galileo or Helios). Within the SOA Development
+ for the version of Eclipse (e.g. Helios). Within the SOA Development
category, select the BPMN Project Feature. Follow the instructions to accept
the license and then restart Eclipse after the plugins have been
installed.
@@ -65,34 +64,33 @@
them within your Eclipse environment.
</para>
<para>
- The <emphasis>pi4soa core</emphasis> feature should be selected from the
- <emphasis>All JBoss Tools</emphasis> category.
+ The <emphasis>JBoss Savara Tools</emphasis> feature should be selected from the
+ <emphasis>SOA Development</emphasis> category.
</para>
<para>
If you wish to view the generated BPEL using a BPEL editor, rather than
XML, then you should also select the <emphasis>JBoss BPEL Editor</emphasis> from the
- <emphasis>All JBoss Tools</emphasis> category.
+ <emphasis>SOA Development</emphasis> category.
</para>
<para>
NOTE: If you don't install the BPEL Editor, then you will have to install
- GMF. This can be found on the Galileo/Helios update site, under the <emphasis>Modeling</emphasis>
+ GMF. This can be found on the Helios update site, under the <emphasis>Modeling</emphasis>
category. Select the <emphasis>Graphical Modeling Framework</emphasis> entry, and
following the instructions to install.
</para>
+
+ <para>
+ It is also recommended that you install the JBoss WebServices Tools, and JBossAS Tools,
+ from the All category. These are required to define and launch a JBossAS
+ server from within Eclipse, generate a JAX-WS web service from a WSDL definition,
+ and test a Web Service.
+ </para>
</listitem>
-
- <listitem>
- Install SAVARA Eclipse plugins
- <para>
- The Eclipse plugins for SAVARA are installed via an update site referenced
- on the SAVARA <ulink url="http://www.jboss.org/savara/downloads">download page</ulink>.
- </para>
- </listitem>
</orderedlist>
<para>
- The installation instructions for the SAVARA Service Validator (for JBossESB) are:
+ The installation instructions for the SAVARA Service Validator are:
</para>
<orderedlist>
<listitem>
Modified: trunk/docs/gettingstartedguide/src/main/en-US/module/runtimevalidation.xml
===================================================================
--- trunk/docs/gettingstartedguide/src/main/en-US/module/runtimevalidation.xml 2010-09-30 17:25:15 UTC (rev 426)
+++ trunk/docs/gettingstartedguide/src/main/en-US/module/runtimevalidation.xml 2010-09-30 19:57:46 UTC (rev 427)
@@ -12,15 +12,34 @@
</note>
<para>
- Once services have been deployed, as mentioned in the previous section, we still need to be
- able to verify that the services continue to conform to the choreography description.
+ The previous sections have provided a brief introduction to the design-time
+ SOA governance features provided within the SAVARA Eclipse Tools distribution.
+ The aim of these capabilities are to enable verification of an implementation, initially
+ defined just using BPEL process definitions, against a
+ choreography, which in turn has been verified against business requirements defined using
+ scenarios. Therefore this helps to ensure that the implemented system meets the original
+ business requirements.
+ </para>
+
+ <para>
+ Being able to statically check that the implementation should send or receive messages
+ in the correct order is important, as it will reduce the amount of testing required
+ to ensure the service behaves correctly. However it does not enable the internal
+ implementation details to be verified, which may result in invalid decisions being
+ made at runtime, resulting in unexpected paths being taken.
+ </para>
+
+ <para>
+ Therefore, to ensure this situation does not occur, we also need runtime governance.
+ We still need to be able to verify that the services continue to conform to the
+ choreography description.
The <emphasis>Service Validator</emphasis> capability within the SAVARA distribution
can be used to validate the behaviour of each service.
</para>
<para>
In this section, we will use the <emphasis>purchasing</emphasis> example found in the
- <filename>${SAVARA}/samples/purchasing]</filename> folder.
+ <filename>${SAVARA}/samples/purchasing</filename> folder.
</para>
<section>
@@ -125,6 +144,83 @@
</section>
<section>
+ <title>Web Service / WS-BPEL Example - Purchasing</title>
+
+ <note>
+ <para>
+ Savara now includes the ability to validate web services (and therefore BPEL
+ processes) that use the jbossws-native stack. However the ODE engine, used
+ to execute BPEL processes within RiftSaw, currently optimises communications
+ between BPEL processes executing within the same engine, so that the communications
+ do not occur using the Web Service stack. This means that Savara is currently
+ unable to validate these interactions. Therefore it is currently recommended to
+ implement the 'Credit Agency' participant as a JAX-WS service. More information
+ on this will be available on the Savara blog.
+ </para>
+ </note>
+
+ <section>
+ <title>Deploying the Example</title>
+
+ <para>
+ The first step is to deploy the BPEL processes for the Store and CreditAgency
+ participants to a JBossAS server running RiftSaw. This can be achieved
+ using the Eclipse Web Tooling Project (WTP) server support, in conjunction with
+ the JBoss Tools features mentioned in the installation section.
+ </para>
+
+ <para>
+ Create a JBossAS server, configured to point to a JBossAS environment that has
+ previously been configured to run RiftSaw. Select the server in the
+ <emphasis>Servers</emphasis> view, and then select the <emphasis>Add and Remove ...</emphasis>
+ menu item. This will show a dialog window that will include the CreditAgency
+ and Store BPEL projects on the left. Select both projects, and press the
+ <emphasis>Add</emphasis> button. When the <emphasis>Finish</emphasis> button
+ is selected, the BPEL processes will be associated with the server.
+ </para>
+ </section>
+
+ <section>
+ <title>Running the Example</title>
+
+ <para>
+ Start the server using the <emphasis>Start</emphasis> menu item associated with
+ the JBossAS server in the <emphasis>Servers</emphasis> view. Once the server
+ has fully started, the BPEL processes should have been deployed.
+ </para>
+
+ <para>
+ The next step is to start the <emphasis>Savara->Monitor</emphasis> associated
+ with the <filename>PurchaseGoods.cdm</filename> choreography description.
+ </para>
+
+ <para>
+ The final step is to send a test message to the <emphasis>Store</emphasis>
+ BPEL process. This can be achieved by selecting the <filename>PurchaseGoodsProcess_Store.wsdl</filename>
+ file, within the <emphasis>PurchaseGoodsProcess_Store</emphasis> project (bpelContents
+ folder), and then select the menu item <emphasis>Web Services->Test with Web Services Explorer</emphasis>.
+ </para>
+
+ <para>
+ Expand the 'StoreInterfaceBinding' node, in the left hand panel of the explorer,
+ and select the 'buy' operation. Then select the 'Source' link, which will show the
+ various sections of the SOAP message to be sent. Edit the message body to be:
+ </para>
+
+ <informalexample>
+ <programlisting role="XML" ><![CDATA[
+ <q0:BuyRequest id="1" amount="200" />
+ ]]></programlisting>
+ </informalexample>
+
+ <para>
+ Then press the 'Ok' button further down the panel. This will send the message to the
+ Store process, and eventually cause a response to appear in the lower panel.
+ </para>
+ </section>
+ </section>
+
+ <section>
<title>JBossESB Example - Trailblazer</title>
<section>
Modified: trunk/docs/gettingstartedguide/src/main/en-US/module/servicedev.xml
===================================================================
--- trunk/docs/gettingstartedguide/src/main/en-US/module/servicedev.xml 2010-09-30 17:25:15 UTC (rev 426)
+++ trunk/docs/gettingstartedguide/src/main/en-US/module/servicedev.xml 2010-09-30 19:57:46 UTC (rev 427)
@@ -104,33 +104,4 @@
</section>
</section>
-
- <section>
- <title>Summary</title>
-
- <para>
-This section has provided a brief introduction to the design-time SOA governance features
-provided within the SAVARA Eclipse Tools distribution.
- </para>
-
- <para>
-The aim of these capabilities are to enable verification of an implementation, initially
-defined just using BPEL process definitions, against a
-choreography, which in turn has been verified against business requirements defined using
-scenarios. Therefore this helps to ensure that the implemented system meets the original
-business requirements.
- </para>
-
- <para>
-Being able to statically check that the implementation should send or receive messages
-in the correct order is important, as it will reduce the amount of testing required
-to ensure the service behaves correctly. However it does not enable the internal
-implementation details to be verified, which may result in invalid decisions being
-made at runtime, resulting in unexpected paths being taken. Therefore, to ensure this
-situation does not occur, we also need runtime governance, which is discussed in a
-later section (Runtime Validation).
- </para>
-
- </section>
-
</chapter>
Added: trunk/docs/gettingstartedguide/src/main/en-US/module/tap.xml
===================================================================
--- trunk/docs/gettingstartedguide/src/main/en-US/module/tap.xml (rev 0)
+++ trunk/docs/gettingstartedguide/src/main/en-US/module/tap.xml 2010-09-30 19:57:46 UTC (rev 427)
@@ -0,0 +1,151 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+]>
+<chapter id="tap">
+ <title>Testable Architecture Project</title>
+
+ <para>
+ The previous sections have discussed the various phases of the software development
+ lifecycle, and the artifacts that can be created. They have also outlined some
+ validation performed between the scenarios and choreography, when a specific link
+ has been established from the scenario.
+ </para>
+
+ <para>
+ However the aim of the "Testable Architecture" methodology is to provide validation
+ between all artifacts, to ensure that artifacts defined at any particular phase
+ can be shown to be valid against the artifacts in preceding phases.
+ </para>
+
+ <para>
+ Therefore the concept of a "Testable Architecture Project" or TAP has been introduced.
+ This is essentially a file that records information about the artifacts defined in
+ each phase of the software development lifecycle, and the relationships between them.
+ This file can then be validated to ensure that each artifact, and its dependencies,
+ are valid in respect of each other.
+ </para>
+
+ <para>
+ For example, the <filename>purchasing</filename> example contains a TAP file with
+ the following contents:
+ </para>
+
+ <informalexample>
+ <programlisting role="XML" ><![CDATA[
+<project xmlns="http://www.savara.org/ta/project" xmlns:xsi="http://www.w3.org/2001/XMLSchema"
+ xsi:schemaLocation="http://www.savara.org/ta/project tap.xsd"
+ name="Purchasing" version="1.0.0">
+
+ <phase name="requirements">
+ <resource id="SuccessfulPurchase.scn">
+ <uri type="eclipse" context="purchasing" locator="/SuccessfulPurchase.scn" />
+ </resource>
+ <resource id="InvalidPurchase.scn">
+ <uri type="eclipse" context="purchasing" locator="/InvalidPurchase.scn" />
+ </resource>
+ </phase>
+
+ <phase name="architecture">
+ <resource id="PurchaseGoods.cdm">
+ <uri type="eclipse" context="purchasing" locator="/PurchaseGoods.cdm" />
+ <relationship type="depends" ref="SuccessfulPurchase.scn" />
+ <relationship type="depends" ref="InvalidPurchase.scn" />
+ </resource>
+ </phase>
+
+ <phase name="implementation">
+ <resource id="PurchaseGoodsProcess_Store.bpel">
+ <uri type="eclipse" context="PurchaseGoodsProcess-Store"
+ locator="/bpelContent/PurchaseGoodsProcess_Store.bpel" />
+ <relationship type="depends" ref="PurchaseGoods.cdm" >
+ <description>
+ Link from the BPEL process to the 'Store' participant
+ within the choreography
+ </description>
+ <link type="role" to="Store" />
+ </relationship>
+ </resource>
+ <resource id="PurchaseGoodsProcess_CreditAgency.bpel">
+ <uri type="eclipse" context="PurchaseGoodsProcess-CreditAgency"
+ locator="/bpelContent/PurchaseGoodsProcess_CreditAgency.bpel" />
+ <relationship type="depends" ref="PurchaseGoods.cdm" >
+ <description>
+ Link from the BPEL process to the 'CreditAgency' participant
+ within the choreography
+ </description>
+ <link type="role" to="CreditAgency" />
+ </relationship>
+ </resource>
+ </phase>
+</project>
+ ]]></programlisting>
+ </informalexample>
+
+ <para>
+ The top level element is <emphasis>project</emphasis>, with the <emphasis>name</emphasis>
+ and <emphasis>version</emphasis> attributes to define the details of the Testable Architecture
+ Project.
+ </para>
+
+ <para>
+ The project then contains <emphasis>phase</emphasis> elements, one for each stage of the
+ software development lifecycle we are interested in. These elements are only used to
+ segment the artifacts into the different phases, which can be useful for tasks such as
+ project management or documentation generation.
+ </para>
+
+ <para>
+ The phase element contains <emphasis>resource</emphasis> elements, one per artifact. A
+ resource represents an artifact that is of interest in the Testable Architecture Project.
+ </para>
+
+ <para>
+ The resource element contains one or more of the following elements:
+ </para>
+
+ <orderedlist>
+ <listitem>
+ uri
+ <para>
+ This element is used to define the location of a resource. A URI element is required for
+ each environent in which the resource may be accessed, for example, within Eclipse and
+ within an SOA Repository.
+ </para>
+ <para>
+ The <emphasis>type</emphasis> attribute defines the type of locator, which will usually
+ map onto the environment in which the resource exists. So in this case we are only
+ defining URI elements associated with the Eclipse environment.
+ </para>
+ <para>
+ The <emphasis>context</emphasis> attribute defines the local information that can be used
+ in the particular environment, to determine where the resource is contained. For example,
+ if the environment is Eclipse, the context would be the project name.
+ </para>
+ <para>
+ The <emphasis>locator</emphasis> attribute is used to specify the specific location of
+ the resource, within the particular specified context, in the environment type. For example,
+ if the environment was Eclipse, then the locator would be the relative path of the resource
+ within the project identified in the context attribute.
+ </para>
+ </listitem>
+ <listitem>
+ relationship
+ <para>
+ This element establishes a relationship from the containing resource, to another resource
+ identifed by the <emphasis>ref</emphasis> attribute.
+ </para>
+ <para>
+ The relationship element can optionally have additional information associated with it,
+ to help clarify the nature of the relationship between the two resources.
+ </para>
+ <para>
+ For example, in the TAP file illustrated above, the two BPEL resources (in the implementation
+ phase) have a relationship to the choreography file - however the relationship needs to be
+ more specific. We need to indicate what <emphasis>role</emphasis> within that choreography
+ the BPEL processes are associated with. The <emphasis>link</emphasis> element enables
+ the <emphasis>type</emphasis> to be defined, and a value to be specified in the
+ <emphasis>to</emphasis> attribute.
+ </para>
+ </listitem>
+ </orderedlist>
+</chapter>
More information about the savara-commits
mailing list