Using a service registry that doesn’t suck part I: UDDI is dead
This is the first of a series of posts on which I am hoping to detail some of the most common SOA governance scenarios in the real world, their challenges and the approach we’ve taken to address them in SO-Aware. This series does not intend to be a marketing pitch about SO-Aware. Instead, I would like to use this to foment an honest dialog between SOA governance technologists.
For the starting post I decided to focus on the aspect that was once considered the keystone of SOA governance: service discovery
Scenario
In a real SOA enterprise infrastructure with hundreds of services, it is safe to assume that service endpoints are going to constantly be subjected to changes in areas such as location (URL), policy (security, etc) or contract (WSDL, operations). As SOA developers, we would like to make our applications as resilient to those changes as possible so that they don’t impose any constraints in the natural evolution of our SOA. A common practice to accomplish that is to have client application to resolve service metadata such as endpoints or policies against a service repository like is illustrated in the following figure:
![ServiceRegistry[1]](http://weblogs.asp.net/blogs/gsusx/ServiceRegistry1_3C228D48.png "ServiceRegistry[1]")
The screwed-up traditional solution: The UDDI way
![Looking[1]](http://weblogs.asp.net/blogs/gsusx/Looking1_5A8CCE31.png "Looking[1]") |
In order to address these challenges, the big SOA vendors (read Microsoft, Oracle, IBM etc) created a standard that with the purpose of modeling service metadata information that could be used to enable service discovery capabilities. The standard was baptized as Universal Data Discovery and Integration (UDDI) and, unfortunately, it became the cornerstone of SOA governance products such as SOA Software or Systinet.
|
Despite the several attempts to leverage it as part of SOA governance platforms, UDDI has proven to be an incredibly ineffective mechanism to enable service publishing and discovery. If you’ve ever used a UDDI registry, this shouldn’t come as a surprise.
For instance, the following SOAP message is required to discover a service endpoint using UDDI.
1: <soap:Envelope
2: xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
3: xmlns:xsd=http://www.w3.org/2001/XMLSchema
4: xmlns:soap=
5: "http://schemas.xmlsoap.org/soap/envelope/">
6: <soap:Body>
7: <find_service businessKey="Key1"
8: generic="2.0"
9: maxRows="15"
10: xmlns="urn:uddi-org:api_v2">
11: <findQualifiers>
12: <findQualifier />
13: <findQualifier />
14: </findQualifiers>
15: <name ="" />
16: <name ="" />
17: <categoryBag>
18: <keyedReference tModelKey="tModelKey1"
19: keyName="tModelKey1Name"
20: keyValue="tModelKey1Value" />
21: <keyedReference tModelKey="tModelKey2"
22: keyName="tModelKey2Name"
23: keyValue="tModelKey2Value" />
24: </categoryBag>
25: <tModelBag>
26: <tModelKey>tModelKey3</tModelKey>
27: <tModelKey>tModelKey4</tModelKey>
28: </tModelBag>
29: </find_service>
30: </soap:Body>
31: </soap:Envelope>
And the response is even more confusing:
1: <soap:Envelope
2: xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
3: xmlns:xsd=http://www.w3.org/2001/XMLSchema
4: xmlns:soap=
5: "http://schemas.xmlsoap.org/soap/envelope/">
6: <soap:Body>
7: <serviceList generic="2.0"
8: operator="MyCompany"
9: truncated="false"
10: xmlns="urn:uddi-org:api_v2">
11: <serviceInfos>
12: <serviceInfo serviceKey="ServiceKey1"
13: businessKey="Key1">
14: <name ="CRMSOAPService" />
15: <name ="" />
16: </serviceInfo>
17: </serviceInfos>
18: </serviceList>
19: </soap:Body>
20: </soap:Envelope>
What makes this process ridiculously hard is the complexity of the UDDI API and the model. Just think about what it will take for a client written in a dynamic language like Ruby(aka doesn’t do SOAP very well) to interact with a UDDI repository.
Bottom line, the SOA models created with UDDI are incredibly complex to implement and use and, quite often, end up becoming another bottleneck in your SOA.
A better solution: The SO-Aware way
When we were building SO-Aware, we decided to avoid the complexities of UDDI and instead enable a way simpler mechanism to facilitate the discovery and query of services. We achieved that by implementing a 100% RESTful API based on the OData standard that allows querying the entire service registry using plain HTTP GETs.
In this model, discovering a new service is just a matter of executing an HTTP GET like the following:
GET /SOAware/ServiceRepository.svc/Services('Service Name')
The response is an AtomPub payload with the service details:
1: <feed xml:base=" http://<WebHost>/ServiceRepository"
2: xmlns="http://www.w3.org/2005/Atom">
3: <title type="text">Services</title>
4: <id> http://<WebHost>/ServiceRepository /Services</id>
5: <updated>2010-10-01T02:33:55Z</updated>
6: <link rel="self" title="Services" href="Services" />
7: <entry>
8: <id> http://<WebHost>/ServiceRepository /Services(‘id’')</id>
9: <title type="text">CRMSOAPService</title>
10: <content type="application/xml">
11: <m:properties>
12: <d:Id m:type="Edm.Guid">Service ID</d:Id>
13: <d:Name>CRMSOAPService</d:Name>
14: <d:Description>This is a SOAP
15: endpoint that abstracts a CRM system</d:Description>
16: <d:Namespace>http://soaware.samples.com</d:Namespace>
17: <d:Style>SOAP</d:Style>
18: </m:properties>
19: </content>
20: </entry>
21: </feed>
Compare this approach with the complexity of the UDDI based model and draw your own conclusions. Basically, this model makes abstracts the interaction with the service registry as simple AtomPub HTTP GETs and POSTs messages. Given that the entire model is based on AtomPub, users can subscribe their favorite Atom reader so feeds that describe the relevant service events such as creation, updates, etc.