Service Registry sample

Message Generation and Greeter are example applications demonstrating the use of Service Registry for Pivotal Cloud Foundry. (For information on the Service Registry product, please see the documentation.)

Building and Deploying

1. Build the two projects from the root (greeting) directory. If using Maven, run:

   $ mvn package

   If using Gradle, run ./gradlew build (OS X, Linux) or gradlew.bat build (Windows).

   $ ./gradlew build

2. Run the deployment script (if you used Maven, scripts/deploy_mvn.sh or scripts/deploy_mvn.bat; if you used Gradle, scripts/deploy_gradle.sh or scripts/deploy_gradle.bat).

   $ ./scripts/deploy_gradle.sh

   The script will create a Service Registry service instance and then push the applications and bind them to the service.

3. When the script has finished, set the TRUST_CERTS environment variable to the API endpoint of your Elastic Runtime instance (as in api.example.com), then restage the applications so that the changes will take effect. Setting TRUST_CERTS causes Spring Cloud Services to add the the SSL certificate at the specfied API endpoint to the JVM’s truststore, so that the client application can communicate with a Service Registry service instance even if your Elastic Runtime instance is using a self-signed SSL certificate (see the Service Registry documentation).

   $ cf set-env message-generation TRUST_CERTS api.wise.com
   Setting env variable 'TRUST_CERTS' to 'api.wise.com' for app message-generation in org myorg / space development as user...
   OK
   TIP: Use 'cf restage' to ensure your env variable changes take effect
   $ cf restage message-generation

   $ cf set-env greeter CF_TARGET https://api.wise.com
   Setting env variable 'CF_TARGET' to 'https://api.wise.com' for app greeter in org myorg / space development as user...
   OK
   TIP: Use 'cf restage' to ensure your env variable changes take effect
   $ cf restage greeter

   Note	By default, the Spring Cloud Services Starters for Service Registry causes all application endpoints to be secured by HTTP Basic authentication. For more information or if you wish to disable this, see the documentation. (HTTP Basic authentication is disabled in these sample applications.)

Trying It Out

1. Visit [ROUTE]/hello, where [ROUTE] is the route bound to the Greeter application. The Greeter application will use the Service Registry to look up the Message Generation application and get a greeting message, which (to begin with) should be “Hello, Bob!”

   

2. You can see what the Message Generation application is sending back by viewing its logs. Run cf logs message-generation.

   $ cf logs message-generation
   Connected, tailing logs for app message-generation in org myorg / space development as user...
   
   2015-07-16T13:07:35.86-0500 [App/0]      OUT 2015-07-16 18:07:35.861  INFO 29 ---
                        [o-61612-exec-10] message-generation.MessageGenerationApplication
                                                     : Now saying "Hello" to Bob
   2015-07-16T13:07:35.87-0500 [RTR/0]      OUT message-generation.wise.com:80 -
                        [16/07/2015:18:07:35 +0000]
                        "GET /greeting?salutation=Hello&name=Bob HTTP/1.1" 200
                        31 "-" "Apache-HttpClient/4.3.6 (java 1.5)" 10.68.204.250:39929
                        x_forwarded_for:"10.68.204.43, 10.68.204.250"
                        vcap_request_id:66b782b6-9953-45b3-52ab-da369ad81f44
                        response_time:0.016146581
                        app_id:bd594ad5-2653-4949-afc6-e5f1ae568259

3. To get a different greeting message, you can provide salutation and name parameters, as in [ROUTE]/hello?salutation=Hi&name=John. The Greeter application will send those parameters to the Message Generation application and the resulting greeting will be customized to match.

   

For more information about the Service Registry and its use in a client application, see the Service Registry documentation.