Merge pull request #30 from ghillert/INTSAMPLES-42

INTSAMPLES-42 - Convert all ReadMe files to MarkDown
This commit is contained in:
Gary Russell
2012-01-18 07:57:28 -08:00
54 changed files with 751 additions and 822 deletions

View File

@@ -1,27 +1,27 @@
Cafe Demo - Scripted Implementation
===================================
This is the scripted implementation of the classic **cafe** sample application. You can choose among **javascript**,
**groovy**, **ruby**, and **python** scripting languages. The functionality is basically identical in all cases to the
original cafe demo.
This is the scripted implementation of the classic **cafe** sample application. You can choose among **javascript**, **groovy**, **ruby**, and **python** scripting languages. The functionality is basically identical in all cases to the original cafe demo.
# Instructions for running the CafeDemo sample
The script language is passed as a command line argument. This may be run directly from maven:
>mvn clean compile
>mvn exec:exec -Dlang=[language]
$ mvn clean compile
$ mvn exec:exec -Dlang=[language]
## Groovy Control Bus
This sample also demonstrates the use of Spring Integration's **groovy control bus** which accepts
Groovy scripts as control messages. These scripts may invoke lifecycle operations on adapters or
operations on managed beans.
This sample also demonstrates the use of Spring Integration's **groovy control bus** which accepts Groovy scripts as control messages. These scripts may invoke lifecycle operations on adapters or operations on managed beans.
To demonstrate the control bus, while the CafeDemoApp is running, execute in a separate window:
>mvn exec:exec -Pcontrol-bus
$ mvn exec:exec -Pcontrol-bus
This will use groovy scripts to
* Query the waiter for the total number of orders delivered
* If the total orders > 3, stop the inbound adaptor on the cafe (the order flow). The Cafe application
will continue to run, but eventually the output will stop when all pending orders have completed.
* If the total orders > 3, stop the inbound adaptor on the cafe (the order flow). The Cafe application will continue to run, but eventually the output will stop when all pending orders have completed.

View File

@@ -0,0 +1,65 @@
Cafe Sample Application
=======================
The Cafe sample emulates a simple operation of the Coffee shop when modeled using Enterprise Integration Patterns (EIP). It is inspired by one of the samples featured in Gregor Hohpe's Ramblings. The domain is that of a Cafe, and the basic flow is depicted in the following diagram:
Barista
hotDrinks ____________________
|==========| -->| |
orders drinks / | prepareHotDrink() |
Place Order ->Cafe->|======|->OrderSplitter->|======|->DrinkRouter | |
\ coldDrinks | prepareColdDrink() |
|==========| -->| |
|____________________|
Legend: |====| - channels
The Order object may contain multiple OrderItems. Once the order is placed, a **Splitter** will break the composite order message into a single message per drink. Each of these is then processed by a **Router** that determines whether the drink is hot or cold (checking the OrderItem object's 'isIced' property). The Barista prepares each drink, but hot and cold drink preparation are handled by two distinct methods:
* prepareHotDrink
* prepareColdDrink
The prepared drinks are then sent to the Waiter where they are aggregated into a Delivery object.
## Instructions for running the CafeDemo sample
1. The example comes with two identical configurations. One is ANNOTATION-based another is XML-based
2. To run this sample simply execute the CafeDemoApp test classes in the **org.springframework.integration.samples.cafe.xml** or **org.springframework.integration.samples.cafe.annotation** package.
3. The example also provides an alternative configuration that uses AMQP channels to distribute the components in the **CafeDemo** sample. To run this alternative configuration of the sample, be sure to have a RabbitMQ broker started on localhost:5672 configured with the default guest|guest client credentials on the / vHost, then execute the following test classes in order:
1. **cafeDemoAppBaristaColdAmqp** - starts the Cold Drink Barista
2. **cafeDemoAppBaristaHotAmqp** - starts the Hot Drink Barista
3. **cafeDemoAppAmqp** - starts the Cafe Storefront (Places 100 orders on the orders queue)
4. **cafeDemoAppOperationsAmqp** - starts the Cafe Operations (OrderSplitter, DrinkRouter, PreparedDrinkAggregator)
**Note**: All AMQP exchanges, queues, and bindings needed for this sample are defined within the different xml config files that support the above test classes.
Upon running any of the alternatives, you should see the output similar to this:
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #1 for order #1: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #2 for order #2: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #3 for order #3: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #4 for order #4: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-2 prepared hot drink #1 for order #1: hot 2 shot LATTE
-----------------------
Order #1
Iced MOCHA, 3 shots.
Hot LATTE, 2 shots.
-----------------------
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #5 for order #5: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #6 for order #6: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #7 for order #7: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #8 for order #8: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #9 for order #9: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-2 prepared hot drink #2 for order #2: hot 2 shot LATTE
-----------------------
Order #2
Iced MOCHA, 3 shots.
Hot LATTE, 2 shots.
-----------------------
Happy integration :-)

View File

@@ -1,70 +0,0 @@
The Cafe sample emulates a simple operation of the Coffee shop shop when modeled using EIP
It is inspired by one of the samples featured in Gregor Hohpe's Ramblings.
The domain is that of a Cafe, and the basic flow is depicted in the following diagram:
Barista
hotDrinks ____________________
|==========| -->| |
orders drinks / | prepareHotDrink() |
Place Order ->Cafe->|======|->OrderSplitter->|======|->DrinkRouter | |
\ coldDrinks | prepareColdDrink() |
|==========| -->| |
|____________________|
Legend: |====| - channels
The Order object may contain multiple OrderItems. Once the order is placed, a Splitter will break the
composite order message into a single message per drink. Each of these is then processed by a Router that
determines whether the drink is hot or cold (checking the OrderItem object's 'isIced' property). The Barista
prepares each drink, but hot and cold drink preparation are handled by two distinct methods: 'prepareHotDrink'
and 'prepareColdDrink'. The prepared drinks are then sent to the Waiter where they are aggregated into a
Delivery object.
Instructions for running the CafeDemo sample
-------------------------------------------------------------------------------
1. The example comes with two identical configurations. One is ANNOTATION-based anther is XML-based
2. To run this sample simply execute the CafeDemoApp test classes
in the org.springframework.integration.samples.cafe.xml or
org.springframework.integration.samples.cafe.annotation package.
3. The example also provides an alternative configuration that uses AMQP channels to distribute the components
in the CafeDemo sample. To run this alternative configuration of the sample, be sure to have a RabbitMQ broker
started on localhost:5672 configured with the default guest | guest client credentials on the / vHost,
then execute the following test classes in order:
1. cafeDemoAppBaristaColdAmqp - starts the Cold Drink Barista
2. cafeDemoAppBaristaHotAmqp- starts the Hot Drink Barista
3. cafeDemoAppAmqp - starts the Cafe Storefront (Places 100 orders on the orders queue)
4. cafeDemoAppOperationsAmqp - starts the Cafe Operations (OrderSplitter, DrinkRouter, PreparedDrinkAggregator)
* Note: All AMQP exchanges, queues, and bindings needed for this sample are defined within the different xml
config files that support the above test classes.
Upon running any of the alternatives, you should see the output similar to this:
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #1 for order #1: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #2 for order #2: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #3 for order #3: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #4 for order #4: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-2 prepared hot drink #1 for order #1: hot 2 shot LATTE
-----------------------
Order #1
Iced MOCHA, 3 shots.
Hot LATTE, 2 shots.
-----------------------
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #5 for order #5: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #6 for order #6: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #7 for order #7: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #8 for order #8: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-1 prepared cold drink #9 for order #9: iced 3 shot MOCHA
INFO : org.springframework.integration.samples.cafe.annotation.Barista - task-scheduler-2 prepared hot drink #2 for order #2: hot 2 shot LATTE
-----------------------
Order #2
Iced MOCHA, 3 shots.
Hot LATTE, 2 shots.
-----------------------
Happy integration :-)

View File

@@ -0,0 +1,41 @@
Loan Broker Application
=======================
The Loan Broker sample is distributed as a Maven project, so you can run it in two ways.
### Maven (command line):
Execute **mvn install**. You should see output that looks similar to this:
. . . . .
INFO : org.springframework.integration.loanbroker.demo.LoanBrokerDemo -
********* Best Quote:
====== Loan Quote =====
Lender: StubBank-11
Loan amount: $270,279
Quotation Date: Fri Mar 12 02:19:35 EST 2010
Expiration Date: Tue Mar 16 02:19:35 EDT 2010
Term: 17 years
Rate: 5.9092593%
=======================
. . . . .
### Eclipse/STS (with m2eclipse plug-in)
1. Import project into Eclipse/STS. If the m2eclipse plugin is installed, the dependencies will be downloaded automatically.
2. Run the **org.springframework.integration.sample.loanbroker.demo.LoanBrokerDemo** class located in **src/test/java**.
# Loan Shark Extension
This extension to the loan broker sample shows how to exchange messages between Spring Integration applications (and other technologies) using UDP. Any loan quotes over 5.2% will be sent to the loanshark application.
* Deploy the **loanshark** sample to a web container (e.g. **mvn tomcat:run**); or
* run the perl (**udps.pl**) or groovy (**udps.groovy**) scripts from the command line.
Run the **LoanBrokerSharkDetectorDemo** test case. You can see the banks that were detected as loan sharks in the **loanshark web UI**.
If you use multicast (the default), messages will be received by the Roo UI war, the perl script, and the groovy script. If not using multicast, only one of the receivers can be used.
To change from multicast to unicast, change the udpOut adapter in **shark-detector-config.xml** to set **host** to **localhost** and multicast to **false**. Refer to the **README.md** file in the loanshark sample project to change it from multicast to unicast for either the Roo application or the groovy script.

View File

@@ -1,45 +0,0 @@
The Loan Broker sample is distributed as a valid Eclipse/Maven project, so you can run it in two ways.
Maven (command line):
1. Execute 'mvn install'
You should see output that looks similar to this:
. . . . .
INFO : org.springframework.integration.loanbroker.demo.LoanBrokerDemo -
********* Best Quote:
====== Loan Quote =====
Lender: StubBank-11
Loan amount: $270,279
Quotation Date: Fri Mar 12 02:19:35 EST 2010
Expiration Date: Tue Mar 16 02:19:35 EDT 2010
Term: 17 years
Rate: 5.9092593%
=======================
. . . . .
Eclipse/STS (with m2eclipse plug-in)
1. Import project into Eclipse/STS. If the m2eclipse plugin is installed, the dependencies will be downloaded automatically.
2. Run the 'org.springframework.integration.sample.loanbroker.demo.LoanBrokerDemo' class located in 'src/test/java'.
Loan Shark Extension
====================
This extension to the loan broker sample shows how to exchange messages between Spring Integration
applications (and other technologies) using UDP.
Any loan quotes over 5.2% will be sent to the loanshark application.
Deploy the loanshark sample in a web container (e.g. mvn tomcat:run); or run the perl (udps.pl)
or groovy (udps.groovy) scripts from the command line.
Run the LoanBrokerSharkDetectorDemo test case.
You can see the banks that were detected as loan sharks in the loanshark web UI.
If you use multicast (the default), messages will be received by the Roo UI war, the perl script,
and the groovy script. If not using multicast, only one of the receivers can be used.
To change from multicast to unicast, change the udpOut adapter in shark-detector-config.xml to set
'host' to "localhost" and multicast to "false". Refer to the ReadMe in loanshark to change it
from multicast to unicast for either the Roo application or the groovy script.

View File

@@ -0,0 +1,14 @@
Loan Shark Application
======================
See **README.txt** in the **loan-broker sample** for information about this sample.
To change the multicast code in **udps.groovy** to rely on unicast instead, simply change the *MulticastSocket* type to *DatagramSocket* and remove the next 2 lines that deal with joining the multicast group. Then, in the configuration of the actual adapter, set:
host="127.0.0.1" and multicast="false".
For the Roo/Spring Integration application:
* Edit the **integrationContext.xml** file
* On the udpIn adapter, set **multicast** to false and
* Remove the **multicast-address** attribute.

View File

@@ -1,10 +0,0 @@
See README.txt in loan-broker sample for information about this sample.
To change the multicast code in udps.groovy to rely on unicast instead, simply
change the MulticastSocket type to DatagramSocket and remove the next 2 lines
that deal with joining the multicast group. Then, in the configuration of the
actual adapter, set: host="127.0.0.1" and multicast="false".
For the Roo/Spring Integration application, edit the integrationContext.xml
file, on the udpIn adapter, set multicast to false and remove the
multicast-address attribute.