Part IV in a three part series 😉

In Part II I went into a little bit of detail on how the echo service gateway and node work, in collaboration with the actual echo server. Or rather, in this case, how the node does not work with the echo server at all.  The echo_node implementation simply looks up some metadata values from it’s config file and returns them, via the gateway, to the requesting party (the dea).  You might question why the node was in there at all.  The answer is that in this case you don’t really need it.

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.  Recall from part I 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.  So really, you can think of it as a server running external to cloud foundry.

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.  In this case, the gateway implementation simply offers a metadata registry with entries for each of the brokered services. In a “normal” cloud foundry service implementation, 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.  In the case of the service_broker there is no node and hence no need to dispatch messages onto NATS.  The web services of the gateway simply look up  the values in its registry and return them.  This 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.  You can either issue those service invocations yourself or you can use the service broker cli.

So here’s what I did to go through the exercise of deploying the echo server as a brokered service:

Step 1: Start with a vcap devbox, following the instructions you find in the vcap repsitory, EXCEPT that you also need to start up the service broker; see this stackoverflow thread for how to do that.

Step 2: Register the echo service with the service_broker.  I used the service_broker_cli which will already be on the devbox you set up in step 1.  Running the cli with no arguments will register what is found in the services.yml file found in the config directory, so I ran it as follows:

bin/service_broker_cli -c config/echobrokeredservice.yml

with the contents of the echobrokeredservice.yml as follows:

---
service_broker: http://service-broker.vcap.me
token: "changebrokertoken"
service:
  name: echo
  description: cloud foundry sample service
  version: "1.0"
  options:
    - name: service
      acls:
        users: []
        wildcards: [*@emc.com]
      credentials:
        host: 192.168.1.150
        port: 5002

Notice the “credentials” section – there are the same values that were in the echo_node.yml file in part I 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.

When you now run a

vmc info --services

you should see the echo service listed.

Step 3: Deploy your client app and bind to the echo_service.

Seriously.  That’s it.

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.  A very valuable part of the cloud foundry services story.  That said, there is clearly value in brokering external services and that’s why you have this bonus track. 🙂

The Echo Client

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 is a bit rigid.  It 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.”  This 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.  It 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.  So in an updated version of the echo client source code that you can find here, 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.  Oh, 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.