UDDI Implementation – Part #1

UDDI is the acronym of Universal Description, Discovery and Integration; this is an industry specification that defines a SOAP-based web service for locating Web services and programmable resources on a network, you can find all information related to this standard on UDDI.org web site.

On Microsoft’s world, UDDI is a Windows Component included in Windows Server 2003 (except on Web version). So you can implement a UDDI environment without to buy any additional software license; all software components needed are included in your Windows 2003 license: IIS 6.0, ASP.NET, .NET Runtime and, of course, UDDI services. For the database side you can use MSDE or SQL Server 2000/2005.

UDDI is one of the components that you need to implement in your ESB system (if you are implementing the Microsoft’s ESB offering).

The most recommended implementation is to install the web UI and API’s in a machine and the database in other one. In this case the UDDI services have to be installed on both boxes and we have to ensure that the communication between them across RPC protocol is enabled. UDDI uses RPC dynamic port allocation to randomly select port numbers above 1024, so it makes very difficult to configure your Firewall to enable the communication between both boxes, the best way to do it is configure your servers to use a static range of ports instead of a dynamic one. To know how to do it you can find the steps to follow on this other post on my blog.

In resume, we have to implement the following Firewall rules in our environment:

- TCP 1433 & UDP 1434. From web server to SQL one in unidirectional mode to enable the communication between web front-end and the databases on the SQL back-end box.

- TCP 135. In bidirectional mode to ensure the communication across RPC protocol.

- TCP 5000-5200. From web server to SQL one in unidirectional mode to enable the RPC protocol communication.

Other important thing to keep in mind is related to the platform that we want to use to build our servers because UDDI IS NOT COMPATIBLE WITH 64x BITS PLATFORMS. At least on Windows 2003 Server platforms, because Microsoft has announced that Windows 2008 64x Bits platform will includes UDDI Services as a Windows Component.

Continue Reading...

UDDI Implementation – Part #2

During our last implementation we received an error when we tried to install UDDI component on the web server; as you know you have to install UDDI on the SQL server first, and this was executed without problems but when we tried to do the same on the web box, just when we provide the SQL server name and installer tries to open the UDDI database hosted on it, we received the following error:

One of the resource that you have use to troubleshoot an UDDI installation is the uddisetup.log file that you can find on C:\windows\ path. Reading it we could see the following entry:

04/28/08 09:50:52: Looking for UDDI databases on machine BKDTESTSQL01
04/28/08 09:50:53: ----------------------------------------------------------
04/28/08 09:50:53: An error occurred during installation. Details follow:
04/28/08 09:50:53: Action: Unable to open the UDDI\Setup\DBServer regkey
04/28/08 09:50:53: Message: Access is denied.

And using the WireShark tool we could check that the problem appeared when the web server tried to talk with SQL one across port 445, the “SMB (Server Message Block”) over IP” port.

In fact UDDI use this port to access to the Registry information in SQL server and know what is the database name that it can use (and other information) so we could think that we have to open this port to enable the communication in a “standard” UDDI environment, but as you know we have to try to avoid the port 445 opening for security reasons, and UDDI is not an unsecure application.

In this scenario, UDDI is trying to use port 445 because it is trying to contact with SQL across Named Pipes via NetBIOS instead to use the TCP/IP protocol. This is because Named Pipes is enabled on the SQL server so we have to force to both machines to use TCP/IP protocol to talk between them and avoid the use of port 445. Forcing the TCP/IP communication, our web server will use port 1433 (the SQL standard one) to talk with the SQL box.

The best way to force to use TCP/IP protocol is to create an alias on the web server to point to SQL one across TCP/IP protocol. To do it, follow these steps:

• Click Start , click Run , type cliconfg , and then click OK . 

• In the SQL Server Client Network Utility dialog box, click the Alias tab, and then click Add . 

• In the Add Network Library Configuration dialog box, under Network libraries , click TCP/IP . 

• In the Server alias box, type the IP address of the computer or the name of the computer that is running SQL Server, and then click OK . 

So the port list that we provide on the first part of this lesson learned post is correct: 1433 (TCP) and 1434 (UDP) for SQL communication, and 135 and 5000-50xx for RPC communication.

Continue Reading...