Tactical SOA Governance Processes. AKA, where to start?
By Dave Berry on Jun 02, 2009
I was discussing with a solutions consultant recently the perceived complexity of putting in place an initial governance solution. In following up on Mike van Alst’s recent blog on SOA governance processes, I wondered what tactical processes would be approachable for an organization trying to get a handle on SOA asset management. A couple things came to mind that I’ve heard from customers such as loading assets into their repository to discover dependencies with the benefit being more granular deployment bundles and reduced deployment time. But an even more mundane and common process every customer has some processes in place for is the management of endpoints in different environments. I’ll admit up front that this may not be a simple task but it is one that almost every organization has some practical experience with and thus a good starting point.
The basic use case is fairly straightforward and well known. SOA projects checked into source control systems contain files such as WSDL, XSD and BPEL deployment descriptors. These assets import URL’s pointing to hard coded hostnames and ports specific to a particular environment such as dev.company.com, qa.company.com, stage, prod etc. The environments are typically separated from each other using a firewall or physically isolated network to make sure there isn’t any accidental sharing of data across environments. This is a great example by the way of a business requirement driving a data quality and assurance governance process. Anyway, managing these assets as they are deployed to their respective environments and assuring they only interact with other services, assets or infrastructure servers within that environments is not a trivial task. In the JCA adapter world, JNDI is used to create consistent names across different environments for database, JMS connectors and connection pools but this technique is generally not applicable for web service based assets. A service bus proxy service or service registry providing a normalized UDDI serviceKey can help fill this gap.
For this discussion, we will focus on a specific type of URL associated with the location of the web services runtime implementation also known as the WSDL Service Port SOAP location as shown below from an example at http://www.w3.org/TR/wsdl#_soap-e.
<documentation>My first service</documentation>
<port name="StockQuotePort" binding="tns:StockQuoteBinding">
Assuming the external service has an location for each environment, then logically each business process or composite application referring to it needs to ensure it is only calling the service located in the correct environment such as shown below
Endpoint management methodologies seem to come under 2 main camps, automated or manual and I think this also matches customer’s size and SOA adoption maturity level. Customers using a manual process might not be as large or sophisticated enough to worry about using an IDE to manually change the project and redeploy in each environment. Larger more mature shops with more specialized IT operations groups and a much larger service portfolio are looking to automate this process at every stage. They likely make use of Apache Ant deployment scripts with substitution variables to handle WSDL and XSD files that include or import dependent assets using hard coded host and port names. Automation scripts do help a lot but usually do not solve the often-requested request for the ability to change the endpoint location without redeploying the business process or application. This type of solution provides more flexibility and overall IT agility for responding to unpredictable changes in the business.
Two approaches for advanced endpoint management are
1) Virtualize the external endpoints using a service bus proxy service
2) Integrated lookup mechanism such as UDDI in the SOA infrastructure or fabric layer.
Both of these solutions externalize the management of endpoints from the SOA application and can support multiple endpoints for load balancing or high availability failover situations. A service bus implementation provides a true virtualization solution making use of content or context based routing and document transformations in the event an endpoint schema changes. It should also allow for managing and changing endpoint locations in an operations management console. The UDDI lookup mechanism is purely for endpoint management and less robust than a service bus virtualization solution but still effectively enables IT operations to change or add endpoint locations. It should achieve this without affecting runtime performance or redeploying the consuming applications such as business processes or composite applications.
Often customers want a single location to manage all service endpoint locations. To meet this requirement, a service bus should allow it’s own endpoints to be externally managed at runtime without redeployment by using service registry’s UDDI serviceKeys. This is a topic for a future discussion but hopefully it has provided fuel for thought on how to break down seemingly complex governance problems into smaller manageable processes to jump start your overall governance strategy.