[jboss-cvs] JBossAS SVN: r104969 - in projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US: images and 1 other directory.

jboss-cvs-commits at lists.jboss.org jboss-cvs-commits at lists.jboss.org
Wed May 19 01:42:58 EDT 2010


Author: marius.bogoevici
Date: 2010-05-19 01:42:58 -0400 (Wed, 19 May 2010)
New Revision: 104969

Added:
   projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/images/account-person.png
   projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/images/application-modules.png
   projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/images/domain-entities.png
Modified:
   projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/Introduction.xml
   projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/Modules.xml
   projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/UseCases.xml
Log:
docs updated

Modified: projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/Introduction.xml
===================================================================
--- projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/Introduction.xml	2010-05-19 05:35:53 UTC (rev 104968)
+++ projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/Introduction.xml	2010-05-19 05:42:58 UTC (rev 104969)
@@ -7,32 +7,100 @@
 <chapter id="chap-guide-Test_Chapter">
   <title>Introduction</title>
 
-  <para>This chapter describes the purpose of the example, as well as the
-  general structure of the documentation.</para>
+  <para>The Sportsclub application provides a real-world inspired example on
+  integrating Spring with Java EE 5 and JBoss. It consists of three web
+  applications packaged together which illustrate various use cases and
+  combinations of components and technologies. It also illustrates how to use
+  the Snowdrop library in order to provide JBoss-specific integration
+  features, such as standalone deployment of an ApplicationContext, and
+  injection of beans provided from that application context in non-Spring
+  components such as EJBs.</para>
 
+  <para>The main goal is to illustrate the mechanics of using Spring with
+  different Java EE 5 components, in the specific context of JBoss, explaining
+  why a certain approach is preferable to another, when the Spring Framework
+  provides two or more options to achieving the same goal. For example, it
+  will explain why we gave preference to JCA-based JMS integration over the
+  DefaultMessageListenerContainer, or why we prefer to use an
+  application-server deployed persistence context versus having Spring create
+  one.</para>
+
+  <para>The example is not intended to be a guide on creating a domain model,
+  breaking down the various layers of the application or on UI design. While
+  the domain model has attempted to follow the general priciples of
+  object-oriented and domain-driven design, which are commonly associated with
+  Spring application, there are many other options and ways of doing it, which
+  are discussed in far more detail elsewhere. For example, the application
+  uses DAOs (or Repositories in DDD terms), but this shouldn't be viewed as
+  advocacy for using them in absolute terms. A significant number of Spring
+  applications use this particular design, and we have employed it to
+  illustrate the technical integration use cases.</para>
+
+  <para>Also, the application uses RichFaces as a component library for JSF.
+  We strongly encourage you to consult the Richfaces documentation and
+  examples for Richfaces-specific information.</para>
+
   <section>
-    <title>Making sure you have all you need</title>
+    <title>Prerequisites: making sure you have all you need</title>
 
     <para>Running the example requires the following setup:</para>
 
     <itemizedlist>
       <listitem>
-        <para>Java 6 JDK</para>
+        <para>Java 6 JDK;</para>
       </listitem>
 
       <listitem>
-        <para>JBoss AS 5.1.0 GA or JBoss EAP 5 or higher</para>
+        <para>JBoss AS 5.1.0 GA or later;</para>
       </listitem>
 
       <listitem>
-        <para>Maven 2.0.8 or higher</para>
+        <para>Maven 2.0.9 or later, with properly set up repositories;</para>
       </listitem>
+
+      <listitem>
+        <para>The Spring Deployer.</para>
+      </listitem>
     </itemizedlist>
+
+    <simplesect>
+      <title>Setting up Maven repositories</title>
+
+      <para>The Maven project setup does not make any assumptions where the
+      artifacts used in the project are coming from (which repository), as
+      users may have different settings for their Maven repositories (direct
+      access to community repositories, proxies, enterprise repository with
+      approved artifacts). Therefore, the setup of the repositories is left to
+      the user of the application.</para>
+
+      <para>In the most simple case, this example can be built out of the box
+      if the settings.xml file for the local Maven installation enables the
+      repositories from Maven Central and JBoss Releases. Instructions for
+      setting up the latter can be found at:
+      http://community.jboss.org/wiki/MavenGettingStarted-Users.</para>
+
+      <para>The pom.xml can be modified to include references to other
+      repositories, or equivalent artifact versions (if the build environment
+      uses an enterprise-wide repository in which the artifacts have different
+      version numbers).</para>
+    </simplesect>
+
+    <simplesect>
+      <title>Installing the Spring Deployer in JBoss AS</title>
+
+      <para>For running the application, the Spring Deployer must be installed
+      in JBoss AS. Please refer to the Snowdrop documentation for
+      details.</para>
+    </simplesect>
   </section>
 
   <section>
-    <title>How to run the examples</title>
+    <title>How to build and run the examples</title>
 
+    <para>The documentation will provide a more detailed account of the
+    application structure and use cases covered, but sometimes it is easier to
+    just run the application.</para>
+
     <para>Running the application consists of the following
     steps:<itemizedlist>
         <listitem>
@@ -50,8 +118,18 @@
         <listitem>
           <para>Deploying the application</para>
         </listitem>
+
+        <listitem>
+          <para>Starting the database</para>
+        </listitem>
+
+        <listitem>
+          <para>Starting the application server</para>
+        </listitem>
       </itemizedlist></para>
 
+    <para>Below are some details on how to perform some of these steps.</para>
+
     <simplesect>
       <title>Building the application</title>
 
@@ -124,28 +202,117 @@
         </listitem>
       </itemizedlist>
 
-      <para>The Spring Deployer will be setup by extracting it into the
+      <para>As explained in the prerequisites, the Spring Deployer will be
+      setup by extracting it into the
       &lt;JBoss-Home&gt;/servers/&lt;server-instance&gt;/deployers folder.
       Please refer to the Spring Deployer documentation for details.</para>
 
       <para>For creating the DataSource and the Destination, you need to use
-      the facilities provided in the jbossconf folder. Just execute;</para>
+      the facilities provided in the jbossconf folder.</para>
 
       <para><informalexample>
           <programlisting>cd jbossconf
-mvn -Pinstall</programlisting>
+</programlisting>
+        </informalexample><informalexample>
+          <para>Modify the jbossconf/jbossas.properties file to indicate the
+          correct location of the JBoss AS installation. A commented example
+          is provided.</para>
+
+          <programlisting>mvn -Pinstall</programlisting>
         </informalexample>This will copy the datasource and JMS destination
       definitions into the JBoss server. Like the previous one, this step
       needs to be executed only once.</para>
     </simplesect>
 
     <simplesect>
-      <title>Deploying</title>
+      <title>Deploying the application</title>
 
-      <para>Deploying the application is as easy as copying one of the EARs
-      produced by the application into the $JBOSS_HOME/servers/default/deploy
-      folder. You can do that either before starting the application server,
-      or after it has started. Before you deploy the application</para>
+      <para>Copy one of the two ears produced by the build to the deploy
+      folder of JBoss AS.ou </para>
+
+      <para>The deployment folder is: JBOSS_HOME/server/default/deploy, and
+      the two (alternative) build files are:</para>
+
+      <itemizedlist>
+        <listitem>
+          <para>sportsclub-ear/target/sportsclub.ear (Hibernate-based
+          implementation);</para>
+        </listitem>
+
+        <listitem>
+          <para>sportsclub-jpa-ear/target/sportsclub.ear (JPA-based
+          implementation, using Hibernate as the underlying provider).</para>
+        </listitem>
+      </itemizedlist>
     </simplesect>
+
+    <simplesect>
+      <title>Starting the database</title>
+
+      <para>From the database folder:</para>
+
+      <para><informalexample>
+          <programlisting>cd database
+</programlisting>
+        </informalexample>Execute one of the two startup scripts:</para>
+
+      <itemizedlist>
+        <listitem>
+          <para>On Linux and other *nix-like systems:</para>
+
+          <informalexample>
+            <programlisting>./startdb.sh</programlisting>
+          </informalexample>
+        </listitem>
+
+        <listitem>
+          <para>On Windows:</para>
+
+          <informalexample>
+            <programlisting>startdb.bat</programlisting>
+          </informalexample>
+        </listitem>
+      </itemizedlist>
+
+      <para>The database must be always started before the application server
+      is started and the application is deployed. The application can also be
+      deployed in a running application server (for example after making
+      changes to it), but this should always happen while the database is
+      started).</para>
+    </simplesect>
+
+    <simplesect>
+      <title>Special configuration for distinct profiles</title>
+
+      <para>The Sportsclub application can be deployed in different JBoss
+      Application Server profiles. Some of these profiles, like for example
+      the Web profile, do not include a message broker, therefore JMS
+      integration features (see dedicated section) must be disabled. In order
+      to disable JMS integration in the Sportsclub application, the file
+      <code>sportsclub-invoicing-webmvc/src/main/webapp/WEB-INF/spring-business-context.xml</code>
+      must be modified by commenting out the following line:<programlisting>&lt;import resource="spring-messaging-context.xml"/&gt;</programlisting></para>
+
+      <para>Uncommenting the line will re-enable the JMS integration
+      features.</para>
+    </simplesect>
   </section>
+
+  <section>
+    <title>Sportsclub and JBoss Developer Studio</title>
+
+    <para>The easiest way to understand how the application works is by
+    looking at its sources. This guide will show you how you can import the
+    application in JBoss Developer Studio.</para>
+
+    <para>Sportsclub is Maven-based, therefore you will need to create the
+    Eclipse project structure for it. You can do by using the Maven Eclipse
+    plugin:</para>
+
+    <informalexample>
+      <programlisting>mvn eclipse:eclipse -Dwtpversion=2.0</programlisting>
+
+      <para>Alternately, you can install the m2eclipse Maven Eclipse plugin,
+      and use it to import the application.</para>
+    </informalexample>
+  </section>
 </chapter>

Modified: projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/Modules.xml
===================================================================
--- projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/Modules.xml	2010-05-19 05:35:53 UTC (rev 104968)
+++ projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/Modules.xml	2010-05-19 05:42:58 UTC (rev 104969)
@@ -8,16 +8,17 @@
   <title>Using JBoss and Spring together</title>
 
   <para>This chapter will describe the various Spring and JBoss integration
-  use cases covered by the application and will describe how are they
-  implemented in the various application modules.</para>
+  use cases covered by the application and how are they implemented in the
+  various application modules.</para>
 
-  <para>As a Spring application that consists of multiple modules, our
-  strategy is to provide fragments of Spring configuration in each artifact
-  produced by a module, leaving to the upper layer components to aggregate
-  them. This strategy has multiple benefits: for one, it allows to separate
-  concerns between components - the Spring wiring of certain components is
-  left at the level where the components are defined, so that it can be
-  changed easily if the implementations change.</para>
+  <para>As a Spring application that consists of multiple modules, the main
+  strategy of constructing the global Spring configuration is to provide
+  Spring bean definition fragments in each artifact produced by a module,
+  leaving to the upper layer components to aggregate them by importing. This
+  strategy has multiple benefits: for one, it allows to separate concerns
+  between components - the Spring wiring of certain components is left at the
+  level where the components are defined, so that it can be changed easily if
+  the implementations change.</para>
 
   <section>
     <title>A look at the JBoss/Spring integration use cases</title>
@@ -178,7 +179,7 @@
 
         <listitem>
           <para>the repository interfaces that provide persistence services
-          for the application</para>
+          for the application;</para>
         </listitem>
       </itemizedlist>A relevant note regarding the domain module is the use of
     the term "repository" for the components that are used for retrieving
@@ -188,6 +189,32 @@
     the persistence and entity lookup functions are part of the domain, rather
     than simple persistence implementation strategies (as it is the case with
     the fairly similar Data Access Objects).</para>
+
+    <figure>
+      <title>Domain entities of the application and their connections</title>
+
+      <mediaobject>
+        <imageobject>
+          <imagedata fileref="images/domain-entities.png" />
+        </imageobject>
+      </mediaobject>
+    </figure>
+
+    <para>Figure 3.1 shows the domain entities of the application. A few
+    non-entity domain objects have been ommitted from the diagram. Figure 3.2
+    shows a more detailed overview of the entities involved in the
+    Account/Person relationshiop, including the non-entity domain
+    objects.</para>
+
+    <para><figure>
+        <title>The Account and Person entities</title>
+
+        <mediaobject>
+          <imageobject>
+            <imagedata fileref="images/account-person.png" />
+          </imageobject>
+        </mediaobject>
+      </figure></para>
   </section>
 
   <section>
@@ -314,15 +341,18 @@
       <title>The JPA implementation</title>
 
       <para>The JPA implementation is, in many respects, very similar to the
-      Hibernate implementation, in that it provides a parametrized superclass
-      that is Spring-agnostic. Besides the fact that it is using the JPA API -
-      for example an EntityManager instead of the SessionFactory, the JPA
-      Persistence Unit (and subsequent EntityManager) are created by the
-      application server and not created by Spring (the EntityManager is
-      injected by Spring, but acquired from JNDI). The persistence unit is
-      deployed from within the JPA repository jar, in order to allow the
-      spring-domain jar to be deployed in non-JPA scenarios (e.g. Hibernate)
-      without triggering a persistence unit deployment.</para>
+      Hibernate implementation (therefore we won't provide a code example for
+      it). It provides a parametrized superclass that is Spring-agnostic as
+      well (except for the usage of the autowiring annotation - which can be
+      replaced by a simple setter if any reference to Spring needs to be
+      removed). Besides the fact that it is using the JPA API - for example an
+      EntityManager instead of the SessionFactory, the JPA Persistence Unit
+      (and subsequent EntityManager) are created by the application server and
+      not created by Spring (the EntityManager is injected by Spring, but
+      acquired from JNDI). The persistence unit is deployed from within the
+      JPA repository jar, in order to allow the spring-domain jar to be
+      deployed in non-JPA scenarios (e.g. Hibernate) without triggering a
+      persistence unit deployment.</para>
 
       <para>The Spring application context configuration fragments are very
       similar to the ones encountered in the Hibernate module:</para>
@@ -380,10 +410,10 @@
    /* */
 }
 </programlisting>This configuration reuses the 'application-specific' context
-        configuration fragment, as well as two specific context configuration
-        fragments to create an Spring context in isolation. Thus, the
-        functionality provided by the repositories can be tested outside the
-        running application.</para>
+        configuration fragment, as well as two test-specific (or otherwise
+        said local) context configuration fragments in order tos to create a
+        Spring context in isolation. Thus, the functionality provided by the
+        repositories can be tested outside the running application.</para>
       </informalexample>
     </section>
   </section>
@@ -394,7 +424,14 @@
     <para>On top of the domain and persistence layer sits the service layer of
     the application. Its role is to co-ordinate the domain objects and
     repositories in order to perform higher level operations. This is also the
-    layer which provides transaction demarcation.</para>
+    layer which provides transaction demarcation. One consideration for which
+    transaction demarcation should be done at service level is to ensure that
+    the changes made by service operations are atomic. Otherwise, concurrent
+    operations may leave the application data in an inconsistent state.
+    Demarcating transactions at the repository/DAO level should be done
+    carefully, taking into consideration that multiple repository/DAO
+    invocations that are not surrounded by a wrapping transactions will
+    execute in separate transactional contexts.</para>
 
     <para>In the Sportsclub application, there are two variants of
     implementing the service layer:</para>
@@ -420,8 +457,12 @@
       <title>The Spring-based service layer</title>
 
       <para>The Spring-based service layer exposes a number of service beans
-      that can be consumed by the UI. The service beans are injected with the
-      beans defined in the persistence layer.</para>
+      that can be consumed by the UI, which are injected with the beans
+      defined in the persistence layer. Given how this is a fairly
+      straightforward Spring configuration, we will non insist any more on
+      this topic, except for outlining that this is the level where
+      transaction demarcation is provided by the use of the appropriate Spring
+      annotations. </para>
     </section>
 
     <section>
@@ -518,16 +559,14 @@
 
       <para>The Subscriptions application uses Richfaces and JSF for the
       presentation layer and EJB for the business layer, so this part of the
-      application is not Spring-related. The only Spring-related feature at
-      this level is the fact that the repositories used by the EJBs are Spring
-      beans.</para>
+      application is not Spring-related. </para>
 
       <para>Although this is somewhat out of the Spring topic, it is worth
       mentioning for the benefit of the reader that we recommend using Seam
       for building applications that integrate JSF and EJB in Java EE 5. This
       type of integration is, however, beyond the scope of the current demo
-      application, so we are mentioning it here, although this example is not
-      demonstrating it.</para>
+      application, so this example is not demonstrating it. Please consult the
+      Seam documentation for detai.</para>
     </section>
 
     <section>
@@ -832,6 +871,12 @@
     <section>
       <title>Payment processing: JMS integration through JCA</title>
 
+      <para>JMS integration can be enabled or disabled in the application, in
+      order to allow it to run in environments that dot have a message broker,
+      like for example the Web Profile of JBoss Application Server. For
+      details on how to do that, please consult section 1.1 of the current
+      guide. </para>
+
       <para>Besides displaying the current status of invoices and payments for
       a given account and generating invoices through the web interface, the
       Sportsclub application can also process payments for various accounts.
@@ -845,16 +890,18 @@
       <para>The component that processes JMS messages is a POJO:</para>
 
       <para><informalexample>
-          <para><programlisting>@Component
-public class PaymentNotificationProcessor
+          <para><programlisting>public class PaymentNotificationProcessor
 {
+   private static final Log LOG = LogFactory.getLog(PaymentNotificationProcessor.class);
 
    @Autowired
    private PaymentProcessor paymentProcessor;
 
    public void processPaymentNotification(PaymentNotification paymentNotification)
    {
+      LOG.info(paymentNotification + " received");
       paymentProcessor.processPayment(paymentNotification.getAccountNumber(), paymentNotification.getAmount());
+      LOG.info(paymentNotification + " processed");
    }
 
 }</programlisting></para>
@@ -871,9 +918,45 @@
       PaymentNotificationService web service implementation (whose contract
       does not depend on the PaymentNotification entity). </para>
 
+      <para>The arrival of messages and their processing can be traced by
+      examining the application log.</para>
+
       <para>Spring will instantiate a bean named
       "paymentNotificationProcessor" which will be registered as a processor
       for JMS message as follows:</para>
+
+      <para><informalexample>
+          <para><programlisting>&lt;jms:jca-listener-container resource-adapter="resourceAdapter" acknowledge="auto"
+                                activation-spec-factory="activationSpecFactory"&gt;
+  &lt;jms:listener destination="/queue/sportsclub" ref="paymentNotificationProcessor"
+                      method="processPaymentNotification"/&gt;
+&lt;/jms:jca-listener-container&gt;</programlisting></para>
+        </informalexample>This type of configuration uses the JCA
+      infrastructure to deliver messages to the listener, as opposed to the
+      DefaultMessageListenerContainer which is effectively polling the
+      destination for incoming messages. Using JCA will ensure better
+      performance, as well as the ability to integrate with the JTA
+      transaction manager out of the box.</para>
+
+      <para>In order to be able to test this feature, messages have to be sent
+      to the message queue. This can be done by using a special MBean defined
+      by the application, accessible from the JBoss AS JMX console. The name
+      of the bean is "sportsclub:name=paymentNotificationTrigger" and has an
+      operation called 'sendPaymentNotification' with two arguments:</para>
+
+      <itemizedlist>
+        <listitem>
+          <para>a long valuem which is the accountId for making the
+          payment;</para>
+        </listitem>
+
+        <listitem>
+          <para>a double value, which represents the amount to be paid;</para>
+        </listitem>
+      </itemizedlist>
+
+      <para>Once the JMX operation is invoked, a message is sent to the queue
+      and a confirmation message will be displayed in the JBoss log.</para>
     </section>
 
     <section>
@@ -939,19 +1022,23 @@
       definition for the PaymentAuditor is:</para>
 
       <para><informalexample>
-          <para><programlisting>@ManagedResource(objectName = "sportsclub:name=paymentAuditor", description = "Payment Auditor", logFile = "log-sportsclub-auditor-jmx.log")
+          <para><programlisting>@ManagedResource(objectName = "sportsclub:name=paymentAuditor", description = "Payment Auditor")
 @Component
 public class PaymentAuditor
 {
+
+   private static final Log LOG = LogFactory.getLog(PaymentAuditor.class);
+
    private boolean enabled = true;
 
-   @ManagedAttribute
+   @ManagedAttribute(description = "Audit enabled")
    public void setEnabled(boolean enabled)
    {
+      LOG.info("Audit " +  (enabled ? "enabled":"disabled"));
       this.enabled = enabled;
    }
 
-   @ManagedAttribute
+   @ManagedAttribute(description = "Audit enabled")
    public boolean getEnabled()
    {
       return this.enabled;
@@ -961,12 +1048,8 @@
    {
       if (this.enabled)
       {
-         System.out.println("AUDIT ENABLED! A payment has been made to account " + accountId + " for the amount of " + amount);
+         LOG.info("A payment has been made to account " + accountId + " for the amount of " + amount);
       }
-      else
-      { 
-         System.out.println("AUDIT DISABLED!"); 
-      }
    }
 }</programlisting>The annotations ManagedResource and ManagedAttribute are
           using to indicate what classes and properties are JMX-managed. In
@@ -992,7 +1075,12 @@
         </informalexample></para>
 
       <para>As a result, you can turn this functionality on and off directly
-      from the JBoss AS JMX administration console.</para>
+      from the JBoss AS JMX administration console, using the
+      "sportsclub:name=paymentAuditor" bean to interact with the payment
+      auditor.</para>
+
+      <para>As explained in the JMS section, a separate MBean is set up for
+      setting messages to the payment notifications message queue. </para>
     </section>
 
     <section>
@@ -1040,7 +1128,9 @@
        &lt;servlet-name&gt;PaymentNotificationService&lt;/servlet-name&gt;
        &lt;url-pattern&gt;/ws/payment&lt;/url-pattern&gt;
    &lt;/servlet-mapping&gt;</programlisting>As a result, the a JAX-WS web
-        service can be accessed at http://localhost:8080/ws/payment.</para>
+        service can be accessed at http://localhost:8080/ws/payment. The
+        service can be tested using a free SOAP testing tool such as SOAP
+        UI.</para>
       </informalexample>
     </section>
   </section>

Modified: projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/UseCases.xml
===================================================================
--- projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/UseCases.xml	2010-05-19 05:35:53 UTC (rev 104968)
+++ projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/UseCases.xml	2010-05-19 05:42:58 UTC (rev 104969)
@@ -5,29 +5,21 @@
 %BOOK_ENTITIES;
 ]>
 <chapter id="chap-guide-usecases">
-  <title>A general overview of the application</title>
+  <title>Understanding the application structure</title>
 
   <para>This chapter describes the business use cases covered by the
   application, and how is the functionality distributed across the
   modules.</para>
 
   <section>
-    <title>The Business Domain of the example application</title>
+    <title>The application structure and its use cases</title>
 
-    <para>The goal of the Sportsclub application is to provide a few examples
-    of real-world applications based on the Spring Framework that integrate
-    with Java EE 5 and JBoss. It consists of not one, but three different
-    applications sharing the same domain model, packaged and deployed
-    together. The latter is done for simplicity reasons, but also for
-    demonstrating a few different technologies working side by side. In the
-    following sections, we will discuss the technologies used in the
-    applications.</para>
+    <para>The Sportsclub example consists of three different applications
+    sharing the same domain model, packaged and deployed together. This is
+    done for simplicity reasons, but also for demonstrating a few different
+    technologies and configuration options working side by side. </para>
 
-    <para>The business domain of the application is a Sports Club. The
-    employees of the club need to be able to perform the following
-    scenarios:</para>
-
-    <para><itemizedlist>
+    <para>The application supports the following scenarios:<itemizedlist>
         <listitem>
           <para>maintaining informations about the subscribers, creating new
           subcriptions and closing existing accounts;</para>
@@ -43,72 +35,51 @@
           for accounts that do not have a current invoice and updating the
           account whenever a payment has been received.</para>
         </listitem>
-      </itemizedlist>As the concerns are different, we have three different
-    applications, each covering one piece of functionality.</para>
-  </section>
+      </itemizedlist></para>
 
-  <section>
-    <title>The Technologies</title>
+    <para>Each of these scenarios is covered by a separate web application,
+    and all three applications are packaged in a single EAR file.</para>
 
-    <para>The Reservations application is using the following
-    stack:<itemizedlist>
-        <listitem>
-          <para>UI layer implemented using Richfaces</para>
-        </listitem>
+    <para>Figure 2.1 shows how the application is structured:</para>
 
-        <listitem>
-          <para>Business layer implemented using EJB</para>
-        </listitem>
+    <figure>
+      <title>Structure of the Sportsclub application</title>
 
-        <listitem>
-          <para>Persistence layer using Spring-based DAOs
-          (Hibernate/JPA)</para>
-        </listitem>
-      </itemizedlist>The Subscriptions application is using the following
-    stack:</para>
+      <mediaobject>
+        <imageobject>
+          <imagedata fileref="images/application-modules.png" scale="80%" />
+        </imageobject>
+      </mediaobject>
+    </figure>
 
-    <itemizedlist>
-      <listitem>
-        <para>UI layer implemented using Richfaces</para>
-      </listitem>
+    <para>All three applications share a common domain model and a common
+    DAO/repository layer, implemented using Spring. The application includes
+    both Hibernate and JPA implementations for the repository layer (using the
+    Hibernate and JPA support provided by JBoss AS, respectively). The
+    application is built in two different variants, each using one of the two
+    DAO implementation alternatives. </para>
 
-      <listitem>
-        <para>Business layer implemented using Spring</para>
-      </listitem>
+    <para>Apart from that, each web application uses a different combination
+    of technologies, illustrating one or more integration use cases.</para>
 
-      <listitem>
-        <para>Persistence layer implemented using Spring-based DAOs
-        (Hibernate/JPA)</para>
-      </listitem>
-    </itemizedlist>
+    <para>The Subscriptions application uses an EJB-based service layer and a
+    JSF-based front-end, using Richfaces components. </para>
 
-    <para>The Invoicing application is using the following stack:<itemizedlist>
-        <listitem>
-          <para>UI layer implemented using Spring MVC and JSP</para>
-        </listitem>
+    <para>The Reservations application uses a Spring-based business layer and
+    a JSF-based front-end, also using Richfaces components.</para>
 
-        <listitem>
-          <para>Business layer implemented using EJB</para>
-        </listitem>
-
-        <listitem>
-          <para>Persistence layer implemented using Spring-based DAOs
-          (Hibernate/JPA)</para>
-        </listitem>
-      </itemizedlist></para>
-
-    <para>In all three cases, the persistence layer is implemented using
-    Spring. In fact there are two alternative implementations: one using
-    Hibernate directly and one using JPA (and Hibernate as the provider).
-    Building the application creates two different EAR files, one using the
-    JPA-based DAOs and one using the Hibernate-based DAOs.</para>
+    <para>The Invoicing application uses an EJB service layer and a Spring
+    MVC-based front-end (using JSP and Spring form tags). Apart from that, it
+    demonstrates the creation of JAX-WS based web services injected with
+    Spring beans, JCA-based Spring JMS integration, auditing by using the
+    Spring AOP configuration and Spring JMX integration.</para>
   </section>
 
   <section>
-    <title>The project modules</title>
+    <title>A comparative look of the project modules</title>
 
-    <para>The modules (Maven artifacts) of the project are outlined in the
-    following table:<table>
+    <para>All the modules (Maven artifacts) of the project, as well as the
+    functionality that they cover are outlined in the following table:<table>
         <title>Modules of the Sportsclub project</title>
 
         <tgroup cols="3">
@@ -132,7 +103,7 @@
             <row>
               <entry>snowdrop-domain</entry>
 
-              <entry>Domain classes and interfaces for repositories.</entry>
+              <entry>Domain classes and repository interfaces.</entry>
 
               <entry>jar</entry>
             </row>

Added: projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/images/account-person.png
===================================================================
(Binary files differ)


Property changes on: projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/images/account-person.png
___________________________________________________________________
Name: svn:mime-type
   + application/octet-stream

Added: projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/images/application-modules.png
===================================================================
(Binary files differ)


Property changes on: projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/images/application-modules.png
___________________________________________________________________
Name: svn:mime-type
   + application/octet-stream

Added: projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/images/domain-entities.png
===================================================================
(Binary files differ)


Property changes on: projects/snowdrop/examples/trunk/sportsclub/docs/guide/en-US/images/domain-entities.png
___________________________________________________________________
Name: svn:mime-type
   + application/octet-stream




More information about the jboss-cvs-commits mailing list