My blog IRhetoric is hosted elsewhere. It is no longer UDDI-focused, but Longhorn focused instead.
A new version of how to model WSDL in UDDI has been published.
A new version of the UDDI RSS Bootstrap file has been posted. This new version provides the canonical RSS 2.0 tModel. It also removes some extraneous attributes from the tModels themselves.
Now, I just need to get around to updating my feed to support RSS 2.0
Traversing the Tree: Using the get_relatedCategories API in UDDI Services is now available on MSDN. This article discusses how and why to use the get_relatedCategories API for accessing and retrieving a list of values within a given categorization scheme in a Microsoft UDDI node.
Odd Fact #3 - tModelKeys are prefixed with uuid: whereas all other keys in the UDDI specification are simply a GUID, without the prefix . Why, you might ask? Good question. One might speculate that the uuid: acts to highlight the URI nature of tModels: unique constructs or concepts that have been cast with semantic meaning. Nonetheless, are tModelKeys somehow "more unique" than other UDDI keys? Of course not. I suppose the prefix endows tModels with a special characteristic ... and, of course, as we've established, they are special!
Continuing my commentary on tModels...
Odd Fact #2 - Interestingly, tModels are self-referential. In other words, a tModel can refer to itself within itself. For example, consider the granddaddy of tModels: the uddi-org types taxonomy tModel. No UDDI instance can function without this core tModel. It is axiomatic to the functioning of UDDI, as other tModels use this tModel for typing. Take a look at the XML representation of this file:
<uddi:tModel tModelKey="uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4"> <uddi:name>uddi-org:types</uddi:name> <uddi:description xml:lang="en">UDDI Type Taxonomy</uddi:description> <uddi:overviewDoc> <uddi:description xml:lang="en"> Taxonomy used to categorize Service Descriptions. </uddi:description> <uddi:overviewURL> http://www.uddi.org/taxonomies/Core_Taxonomy_OverviewDoc.htm#UDDItypes </uddi:overviewURL> </uddi:overviewDoc> <uddi:categoryBag> <uddi:keyedReference tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" keyName="types" keyValue="categorization"/> </uddi:categoryBag> </uddi:tModel>Notice how the tModelKey is re-used as one of the keyedReference tModelKeys! Semantically, this tModel is categorized with itself. Nice.
I've been thinking a lot about tModels lately and keep noticing peculiarities that endear the structure to me even more. So, I'll be posting some thoughts on the oddities of tModels over the next couple days.
Odd Fact #1 - They can never be deleted. Once you create a tModel, you can't get rid of it. Yes, there is a delete_tModel API message, but calling that API does not delete the tModel (as it purports to do); it "hides" it. We aren't talking about a latency behavior here; we are talking about deceptive semantics for the purpose of preserving referential integrity.
In fact, you can resurrect a deleted tModel from the dead by "re-saving" a deleted tModel. This resurrection behavior, however, is not true for any other entities in UDDI.
All in all, tModels are very persistent critters; you might think you exterminated them, but you didn't.
Stay tuned for other strange facts about tModels...
A recent blog from John Udell suggests that Microsoft's initiative around newsgroup support is a good thing, but bemoans the lack of Microsoft blogs out there. Actually a few of us are blogging, when we find the time... and you can query UDDI to find us...
Just published a paper on using metadata in UDDI. It walks through exactly the thinking behind UDDI's metadata strategy. Perhaps most importantly, it explains how to use checked taxonomies in UDDI Services of Windows Server 2003 -- special support for categorization in UDDI Services that isn't documented anywhere else.
I have published a companion piece to the paper on RSS and UDDI. This new paper addresses the use of UDDI Services in Windows Server 2003 for the registration and discovery of RSS Feeds. This paper shows how behind-the-firewall scenarios can take advantage of UDDI and RSS. For example, imagine each organizational division of a company publishing RSS Feeds on their intranet. UDDI Services can then act as the registry and discovery protocol for all internal RSS Feeds, taking advantage of categorization and modeling as discussed in the first RSS/UDDI paper.
The paper also explains how to update the code sample to point to a private UDDI instance as opposed to the UDDI Business Registry.
Published a white paper and code sample that demonstrates how to publish RSS Feeds to UDDI and how to aggregate RSS Feeds from UDDI. The paper walks through the modeling of RSS in UDDI, identifying some canoncial RSS tModels and clarifying how classificaiton of those feeds works. The code sample is a primitive aggregator and publisher, meant more as a sample than a client application to use regularly. I don't do any caching in the client, so it isn't the most efficient tool.
Probably the trickiest part of the modeling exercise was handling different versions of RSS. At first, I considered creating a different tModel for each version. However, this got to be overkill, as there are a number of RSS 0.9x versions. I then considered using just one tModel for all versions. However, there is such a radical change from RSS 0.9x to RSS 1.0 that I felt they needed to be distinguished. As such, I went with two tModels, one for all RSS 0.9x feeds and one for RSS 1.0 feeds. Feedback on this decision is most definitely welcome, as is feedback on the entire project.
Two recent publications on UDDI Services in Windows Server 2003. First, a synopsis paper goes over the high level features and scenarios. Second, a FAQ is available.
One infrequently discussed aspect the UDDI Business Registry (UBR) Version 2is the implementation of the UDDI Replication specification. It is a shame this gets such little attention, because replication is quite impressive. (Then again, when technology works, nobody pays attention...)
So what is UDDI Replication anyway? When two or more UDDI "nodes" are integrated into a UDDI "registry," the use of the UDDI Replication API allows the registry to be viewed as a single logical entity. A registry designed in this way supports uniform access to a complete set of registry data from any node within the registry. The goal of replication is to facilitate the establishment and maintenance of a single consistent shared set of registry data. Replication latency notwithstanding, all nodes in a registry should at all times contain common content.
In the UBR, replication between the three nodes (SAP, IBM and Microsoft) happens on an hourly basis. Each node polls the other nodes to get change records. The key to the replication topology working is the Originating Update Sequence Number (USN). By maintaining an ever increasing USN, what is known as the high water mark vector can be provided when changes are requested. What does this all mean? Nodes share out their changes so that other nodes are always up to date.
So why does replication rule? First off, the Replication API is entirely SOAP and XML-based and is a prime example of an interoperable Web service. The SAP and IBM implementations work great against Microsoft's .NET implementation. Second, the Replication API is validation of the interoperability between the different UDDI implementations, demonstrating the strength of the UDDI specification across multiple vendors. Third, the Replication API is an example of writing secure Web services. Not only do the SOAP messages use HTTPS, they also use X.509 v3 client certificates with every message.
I would encourage you to check out the replication behavior by saving data to one of the UBR nodes and watching it replicate across to the other two UBR nodes.
Often times, it is quite handy to provide a link for your UDDI entry to someone else. "Check out my tModel at http://..." With the new user interface both on the Microsoft public node and on the UDDI Services in Windows Server 2003, this ability has been complicated by the use of frames.
However, one can still achieve this bevahior of providing a link to a graphic rendering of your UDDI entry. The following patterns can be used for the different entities: in UDDI:
Business Key: http://uddi.microsoft.com/details/businessdetail.aspx?key=Provider GUID
Service Key: http://uddi.microsoft.com/details/servicedetail.aspx?key=Service GUID
Binding Key: http://uddi.microsoft.com/details/bindingdetail.aspx?key=Binding GUID
tModel Key: http://uddi.microsoft.com/details/modeldetail.aspx?key=tModel GUID
In UDDI Services, the pattern holds true, but you would use http://[server name]/uddi or http://[server name]/uddipublic as the root, depending on whether you were using Windows authentication or not.
However, users following these links will lose the ability to navigate, as the navigation frames will be lost.
Of course, to provide an XML representation of the entity, you can use the discoveryURL. The pattern for that syntax is as follows:
http://uddi.microsoft.com/discovery.ashx?businessKey=Provider GUID
or for UDDI Services
http://[server name]/uddipublic/discovery.ashx?businessKey=Provider GUID
Remember, discoveryURLs are only for providers (businessEntity) and this type of HTTP-GET of UDDI XML is not available for tModels.
UDDI.org has just released a new white paper entitled The Evolution of UDDI. This paper walks through how UDDI has morphed in its brief lifetime and gives some insights as to what the v3 authors were attempting to accomplish in v3. This is a great introduction into v3 and recommended reading before diving into the spec itself.
The core of the paper deals with registry interaction -- topologies of mulitple UDDI registries that share common data. The ability to expand UDDI beyond a single registry makes for some compelling scenarios in terms of distributed environments.
If you visited the UDDI.org website recently, you will notice the site got a facelift due to the transition announcement that UDDI has been adopted by OASIS. For the complete press release, see the announcement.
Visiting the v2 Microsoft node of the UBR or installing UDDI Services in RC1, one will discover a new user interface to UDDI. While it may take awhile to get used to (as all new things do), there is a lot to excited about. Here's a list of 5 things I really like about it.
Overall, the new UI is a great example of an ASP.NET web application. The development team took advantage of many features in ASP.NET and the final result rocks.
Two pieces of news around UDDI were recently announced:
First, Release Candidate 1 of Windows Server 2003 shipped. This release contains UDDI Services as a natively available feature of the OS. Lots of improvements and new features have been added to UDDI Services since Beta 3 of .NET Server, including multi-box install, improved UI, Version 2 support and more.
Second, the Universal Business Registry (UBR) officially went into production under v2 of the UDDI Specification. A new operator has been brought on board (SAP) with another joining soon (NTT). All three nodes are replicating hourly. At the Microsoft UBR Node, you will notice that the UI got a facelift, allowing much more of the API to be accessed through the UI.
The convergence of these two pieces of news? The Microsoft UBR node is running on Windows Server 2003!