This is the first in a series of blog postings regarding various aspects of SOA governance and thoughts around how to leverage various ecosystem components to found a governance methodology that is right for your organization. In this posting we will start with a technique that is part of runtime SOA governance, dynamic endpoint lookup using a service gateway, namely Intel’s SOA Expressway. First we’ll review a little history of where we came from to put this into perspective. A decade or so ago the industry developed a standard known as Universal, Description, Discovery and Integration or UDDI. The focus of this standard was to locate details about internet resources in a standards based way perhaps as a way to move forward from X.500/LDAP based security stores. While it received a good deal of traction in large enterprises for this aspect of SOA governance, connecting and querying a UDDI server isn’t without its own challenges due to version compatibility and perhaps even vendor implementation. The closing of UDDI as an ongoing standards development effort by OASIS has led major enterprise software vendors to focus new efforts on their own Repository solutions. Several of the Repository vendors have formed a new effort called SOA Repository Artifact Model & Protocol ( S-RAMP ) to standardize access to these repositories for development, runtime and monitoring. Just as many vendors used LDAP as a basis to begin their own enterprise security solution most of the Repositories generally synchronize with UDDI and digest web service and other XML metadata in a similar fashion. In addition to this UDDI like functionality, however, there are often hooks to their offerings in other important aspects of SOA governance putting this type of solution at the intersection of the service lifecycle. IBM’s WebSphere Registry and Repository (WSRR) is one such product that we will look at leveraging for dynamic endpoint lookup. We’ll begin with another important aspect of SOA governance, design time. Intel’s SOA Expressway runtime is configured by packages developed in Intel SOA Expressway Services Designer which is an Eclipse based integrated design environment. A great deal of design time governance for writing code in an IDE such as Eclipse centers around a source code control system and in this respect, Services Designer is no different but that’s another topic for another blog. Since these source code management infrastructures tend to be somewhat departmental, we’ll look at UDDI and Repositories as a means for those developing enterprise standard web service definitions to share their code with the SOA developer audience at large. When starting a new project of type ‘Service Proxy’ in Services Designer you have the ability to query a UDDI server or Repository: In this case we’ll look for our WSDL in a UDDI query: If you’d like to test this scenario on your own you don’t need to replicate your IBM WSRR with UDDI you can sign up for an evaluation of Intel SOA Expressway here and we’ll provide a simple WSDL you can use for calling a remote service on the internet. In this case we’ll retrieve the definition of a simple calculator service and use it in our Services Designer which has an Eclipse modeling perspective based on Business Process Execution Language or BPEL. The initial project workflow created from the WSDL will look like this: This is a simple proxy service that will allow you to receive a call on the Intel SOA Expressway service gateway and to invoke a remote function which happens to be a web service, although it could be mediated to one of many protocols supported (see data sheet for list). Notice the bottom of the following screenshot where the remote URL that will call in the ‘Invoke’ step is an un-routable host IP of 255.255.255.255. This could be the IP address of development server perhaps but in this blog we’re focusing on SOA runtime governance so let’s look at how we can dynamically derive the endpoint of the calculator service for its production instantiation using IBM WSRR as the authoritative source. To do this we will put in another ‘Invoke’ to call out to IBM WSRR for this information. The invoke steps have been renamed to WSRR_Lookup and Calculator respectively in the following screen shot: In this IBM WSRR invoke we will configure the parameters we need to be able to execute our dynamic endpoint lookup. Since IBM WSRR requires HTTP Basic Authentication for connections of this type by default we will provide Base64 encoded user name and password in an HTTP header entry. Here is an online utility you can use in order to encode your user name and password in the format of username:password . Once you get the result you would add the string “Basic “ in front of the generated Base64 string. Next we will enter the Path to the RESTful XMLPropertyQuery provided by IBM WSRR. Finally we will enter the Query we want to execute to get the endpoint of the Calculator service we would like to call at runtime. A couple of items to note here are 1) We’ve selected a simple static query string here where we know the name of the SOAP Address we’re looking for. IBM WSRR provides a wealth of governance capabilities for managing how this discovery is exposed in the real world providing far more interesting lookups containing more SOA governance centric parameters and 2) Although we are providing the name of the SOAP Address object that we want the location for from WSRR in the Query string, this could be reflected from the WSDL and passed in to this lookup making it a re-usable template which again, is another matter we will cover in a future posting focusing on SOA governance for development. Once we’ve done this we have one last step to leverage the endpoint we want to dynamically discover from IBM WSRR at runtime and that is to extract the value of the location variable returned using XPath. We do this by selecting our Calculator invoke in our Workflow and then the Routing configuration on the left side vertical tabs. In this case we will leverage ‘Specify dynamic address’ and provide an XPath snippet in order to get the endpoint we want. What we see now on the default Details vertical tab for our Calculator invoke is that the endpoint Service URL now refers to this dynamic location queried and extracted from IBM WSRR. > In order to prepare to deploy our test to the Intel SOA Expressway we need to export the project from Eclipse which essentially rolls up project artifacts into a gzipped TAR file. We can import this file to the Intel SOA Expressway via several mechanisms, some of which will serve our future postings on SOA governance for the development lifecycle. For now we will look at the Web Interface for Intel SOA Expressway as there is one other item we need to accomplish to prepare for connecting to IBM WSRR and that is to import the IBM WSRR certificate and keystore. You can find more specific information in the IBM Redpaper, Integrating WebSphere ServiceRegistry and Repository with WebSphere DataPower , on how to extract these from the IBM WebSphere instance that is hosting the IBM WSRR application. We will put these into an Intel SOA Expressway Security Package which we’ve named WSRR. Notice these items are under Application Configurations on the Configuration tab. In Intel SOA Expressway, an Application Configuration is the container that allows for settings that apply the single active configuration which can be used as part of a ‘develop and deploy’ lifecycle which we will cover in a later blog post. The System Configuration holds settings that apply no matter what Application Configuration is active. Finally we will deploy our application bundle to the configuration: Now we get the structure of our application in the left side hierarchy of the Intel SOA Expressway web interface. Notice there are two Invocation Agents, one for our WSRR lookup and another for the Calculator web service call. Also notice that the WSRR lookup is specified HTTPS. Since IBM WSRR is configured by default to require mutual authentication for HTTP/S the certificate and keystore will need to be presented at the time of connection by the invocation agent. We will apply the WSRR named Security Package to the Invocation Agent that will make the runtime calls to IBM WSRR. Notice that you can specify items like destination IP address and TCP port as well as hardware interface to bind the listener to. Once these steps are complete we can save our (and activate if necessary) our Configuration on the Intel SOA Expressway. Now we’re ready to test our deployment. You can do so with any tool that can post SOAP messages to the IP address and port specified on the Input Servers section. Here’s a sample SOAP message for the Add operation we’ve exposed on Intel SOA Expressway: And the expected response: If you’d like to try this on your own evaluation copy of Intel SOA Expressway you can register here for a download. If you don’t have IBM WSRR and would like to try this integration you may also register for a evaluation session on the Amazon cloud where we have this and many more scenarios you can build and run on a personal instance provisioned for you there for a day. Stay tuned for more blogs that will continue to build on the key tenets of SOA governance and how to put them into practice using Intel SOA Expressway and other SOA solutions in your ecosystem.