Included in the vcap-services repository is an implementation for a service broker which can be used to act as a gateway to services that are running outside of cloud foundry. \u00a0Recall from part I<\/a> in this series that the echo server, the java application that listens on a port and parrots back what it hears there, really doesn’t have anything to do with cloud foundry; again, not even the echo_node communicates with it. \u00a0So really, you can think of it as a server running external to cloud foundry.<\/p>\n The service_broker is a service_gateway implementation that stands up a RESTful web service that implements all of the resources that any service gateway resource does; resources that allow you to create or delete a service instance, bind or unbind it from applications, etc. \u00a0In this case, the gateway implementation simply offers a metadata registry with entries for each of the brokered services. In a “normal” cloud foundry service\u00a0implementation, in response to these web service requests the gateway will dispatch a message to NATS, a node will pick it up, fulfill the request and communicate back to the gateway, which in turn responds to its client. \u00a0In the case of the service_broker there is no node and hence no need to dispatch messages onto NATS. \u00a0The web services of the gateway simply look up \u00a0the values in its registry and return them. \u00a0This begs the question of how things get into that registry; the service_broker gateway offers a RESTful web service resource for the registry itself, supporting POST to add things and DELETE to remove them. \u00a0You can either issue those service invocations yourself or you can use the service broker cli<\/a>.<\/p>\n So here’s what I did to go through the exercise of deploying the echo server as a brokered service:<\/p>\n Step 1<\/strong>: Start with a vcap devbox, following the instructions you find in the vcap repsitory<\/a>, EXCEPT that you also need to start up the service broker; see this stackoverflow thread<\/a> for how to do that.<\/p>\n Step 2<\/strong>: Register the echo service with the service_broker. \u00a0I used the service_broker_cli<\/a> which will already be on the devbox you set up in step 1. \u00a0Running the cli with no arguments will register what is found in the services.yml file found in the config<\/a> directory, so I ran it as follows:<\/p>\n with the contents of the echobrokeredservice.yml as follows:<\/p>\n Notice the “credentials” section – there are the same values that were in the echo_node.yml file in part I<\/a> but now instead of the echo_gateway dispatching to NATS and the echo_node simply returning the values from the echo_node.yml file, the service_broker_gateway just looks those values up in its registry and returns them.<\/p>\n When you now run a<\/p>\n you should see the echo service listed.<\/p>\n Step 3<\/strong>: Deploy your client app and bind to the echo_service.<\/p>\n Seriously. \u00a0That’s it.<\/p>\n But before you think, “why did I go through all of those other hairy steps with the node and gateway and BOSH, etc.?,” remember that this echo server is just a sample, and a very, very simplified one. Servers that run within cloud foundry (and are hopefully deployed with BOSH) benefit from management, monitoring, logging and other cloud foundry capabilities, and the gateway\/node combination is a loosely coupled mechanism for offering lifecycle operations on those services. \u00a0A very valuable part of the cloud foundry services story. \u00a0That said, there is clearly value in brokering external services and that’s why you have this bonus track. \ud83d\ude42<\/p>\n So just a bit more on step 3 from above. The Echo client application that was posted all the way back on the original support forum article<\/a> is a bit rigid. \u00a0It accesses the details of the bound services through the VCAP_SERVICES environmental variable, and that’s fine, but it then looks for a service type named (exactly) “echo” and an instance name of (exactly) “myecho.” \u00a0This hard coding always bugged me but because of the way that brokered services are named as a part of their configuration, I finally did something about it. \u00a0It required some changes to JsonParseUtil.java where I now take in a string and look for a service type name and instance name that contains that string. \u00a0So in an updated version of the echo client source code that you can find here<\/a>, the client will look for a bound service with the type and the instance name containing the string “echo”; so the service type of “echo_service” with a name like “echo_service-a302” fits the bill. \u00a0Oh, and one other slight add to the app – this one now prints the contents of the VCAP_SERVICES environmental variable – helps when you are first getting started with such things.<\/p>\nbin\/service_broker_cli -c config\/echobrokeredservice.yml<\/pre>\n
---\nservice_broker: http:\/\/service-broker.vcap.me\ntoken: \"changebrokertoken\"\nservice:\n name: echo\n description: cloud foundry sample service\n version: \"1.0\"\n options:\n - name: service\n acls:\n users: []\n wildcards: [*@emc.com]\n credentials:\n host: 192.168.1.150\n port: 5002<\/pre>\n
vmc info --services<\/pre>\n
![\"\"](\"https:\/\/i0.wp.com\/corneliadavis.com\/blog\/wp-content\/uploads\/2013\/03\/echosb1-300x94.png?resize=300%2C94\" "\\"echosb1\\"")
<\/a><\/p>\n![\"\"](\"https:\/\/i0.wp.com\/corneliadavis.com\/blog\/wp-content\/uploads\/2013\/03\/echosb2-175x300.png?resize=175%2C300\" "\\"echosb2\\"")
<\/a><\/p>\nThe Echo Client<\/h1>\n
![\"\"](\"https:\/\/i0.wp.com\/corneliadavis.com\/blog\/wp-content\/uploads\/2013\/03\/echosb3-300x136.png?resize=300%2C136\" "\\"echosb3\\"")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"