From do-not-reply at jboss.org Thu Oct 7 07:23:55 2010
Content-Type: multipart/mixed; boundary="===============8410753139354584750=="
MIME-Version: 1.0
From: do-not-reply at jboss.org
To: savara-commits at lists.jboss.org
Subject: [savara-commits] savara SVN: r432 - in trunk:
docs/gettingstartedguide/src/main/en-US/module and 1 other directories.
Date: Thu, 07 Oct 2010 07:23:55 -0400
Message-ID: <201010071123.o97BNtUl010463@svn01.web.mwc.hst.phx2.redhat.com>
--===============8410753139354584750==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Author: objectiser
Date: 2010-10-07 07:23:55 -0400 (Thu, 07 Oct 2010)
New Revision: 432
Added:
trunk/docs/gettingstartedguide/src/main/en-US/images/SAVARAMonitorPurcha=
sing1.png
trunk/docs/gettingstartedguide/src/main/en-US/images/SAVARAMonitorPurcha=
sing2.png
Modified:
trunk/docs/gettingstartedguide/src/main/en-US/module/runtimevalidation.x=
ml
trunk/tools/pom.xml
Log:
Change purchasing example docs and update link to pi4soa update site for bu=
ild.
Added: trunk/docs/gettingstartedguide/src/main/en-US/images/SAVARAMonitorPu=
rchasing1.png
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(Binary files differ)
Property changes on: trunk/docs/gettingstartedguide/src/main/en-US/images/S=
AVARAMonitorPurchasing1.png
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Added: trunk/docs/gettingstartedguide/src/main/en-US/images/SAVARAMonitorPu=
rchasing2.png
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
(Binary files differ)
Property changes on: trunk/docs/gettingstartedguide/src/main/en-US/images/S=
AVARAMonitorPurchasing2.png
___________________________________________________________________
Name: svn:mime-type
+ application/octet-stream
Modified: trunk/docs/gettingstartedguide/src/main/en-US/module/runtimevalid=
ation.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/docs/gettingstartedguide/src/main/en-US/module/runtimevalidation.=
xml 2010-10-01 14:34:26 UTC (rev 431)
+++ trunk/docs/gettingstartedguide/src/main/en-US/module/runtimevalidation.=
xml 2010-10-07 11:23:55 UTC (rev 432)
@@ -146,31 +146,46 @@
Web Service / WS-BPEL Example - Purchasing
=
-
- Savara now includes the ability to validate web services (and therefore=
BPEL
+ Savara includes the ability to validate web services (and therefore BPEL
processes) that use the jbossws-native stack. However the ODE engine, u=
sed
to execute BPEL processes within RiftSaw, currently optimises communica=
tions
between BPEL processes executing within the same engine, so that the co=
mmunications
do not occur using the Web Service stack. This means that Savara is cur=
rently
- unable to validate these interactions. Therefore it is currently recomm=
ended to
- implement the 'Credit Agency' participant as a JAX-WS service. More inf=
ormation
- on this will be available on the Savara blog.
+ unable to validate these interactions by default.
-
=
+
+ There are two solutions to this problem. The first is to disable the in=
terprocess
+ communications used between the two BPEL processes, which will be the a=
pproach
+ described in this section. The other approach is to implement the 'Cred=
it Agency'
+ participant as a JAX-WS service.
+
+ =
Deploying the Example
=
- The first step is to deploy the BPEL processes for the Store and Credi=
tAgency
+ Once the BPEL processes have been generated, and the implementation de=
tails
+ added, it is currently necessary to disable the 'inter-process' commun=
ication
+ that is used to communicate between the two processes (an ODE optimiza=
tion
+ when the processes are running in the same engine). This is achieved by
+ editing the deployment descriptor for the Store process (using a text =
editor
+ rather than the Eclipse form editor), and add the attribute
+ usePeer2Peer=3D"false" to the invoke element.
+
+ =
+
+ The next step is to deploy the BPEL processes for the Store and Credit=
Agency
participants to a JBossAS server running RiftSaw. This can be achieved
using the Eclipse Web Tooling Project (WTP) server support, in conjunc=
tion with
the JBoss Tools features mentioned in the installation section.
=
- Create a JBossAS server, configured to point to a JBossAS environment =
that has
+ Create a JBossAS server entry in the Servers view=
, using
+ the New->Server menu item on the view's context m=
enu.
+ Configure the server entry to point to a JBossAS environment that has
previously been configured to run RiftSaw. Select the server in the
Servers view, and then select the Add a=
nd Remove ...
menu item. This will show a dialog window that will include the Credit=
Agency
@@ -185,7 +200,9 @@
=
Start the server using the Start menu item associ=
ated with
- the JBossAS server in the Servers view. Once the =
server
+ the JBossAS server in the Servers view, or manual=
ly from
+ a terminal window in the JBossAS server's bin fol=
der using
+ the run script. Once the server
has fully started, the BPEL processes should have been deployed.
=
@@ -197,8 +214,9 @@
The final step is to send a test message to the Store
BPEL process. This can be achieved by selecting the Purchase=
GoodsProcess_Store.wsdl
- file, within the PurchaseGoodsProcess_Store proje=
ct (bpelContents
- folder), and then select the menu item Web Services->Test wi=
th Web Services Explorer.
+ file, within the PurchaseGoodsProcess_Store proje=
ct
+ (bpelContents folder), and then select the menu
+ item Web Services->Test with Web Services Explorer.
=
@@ -217,6 +235,39 @@
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.
+ =
+
+ Four entries should appear in the SAVARA monitor, the buy request, cre=
dit check
+ request, credit check ok (response) and buy confirmed (response).
+
+ =
+
+
+
+
+
+ To demonstrate how an error would be detected and reported, issue a ne=
w request
+ such as:
+
+
+
+
+ ]]>
+
+ =
+
+ This will result in an unexpected message to be reported, as there is =
a difference
+ between the choreography and the CreditAgency BPEL process (implementa=
tion).
+ The choreography defines that a valid credit check should be returned =
if the
+ amount is less than 250. However the BPEL process has implemented this=
condition
+ as a valid credit check is where the amount is less or equal to 500.
+
+ =
+
+
+
+
=
Modified: trunk/tools/pom.xml
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/tools/pom.xml 2010-10-01 14:34:26 UTC (rev 431)
+++ trunk/tools/pom.xml 2010-10-07 11:23:55 UTC (rev 432)
@@ -58,7 +58,8 @@
pi4soa
- http://download.jboss.org/jbosstools/builds/nightly/3.2.helios/jbo=
sstools-pi4soa/all/repo/
+ http://download.jboss.org/jbosstools/builds/staging/pi4soa/all/rep=
o/
+
p2
true
--===============8410753139354584750==--