Web services are an ever-increasingly popular way of deploying enterprise SOA applications. UDDI is the standard Web services model for locating services. For those applications that are developed and deployed as Web services, UDDI makes a nice, standard way for publishing and locating these Web services.
Enterprise applications may also be built on an SOA without the need for Web services. These applications may also use UDDI as a service registration and discovery mechanism. There are, however, scenarios where the SOA may choose to use something other than UDDI for registration and location of the services.
UDDI provides discovery using XML semantics. This allows the client and service (and SOA) to be implemented in different programming languages. If the SOA, services, and clients are all implemented in the same programming language, then the SOA could provide discovery through language semantics and not XML. This could potentially make it easier for the client to request a service, and perhaps increase performance of the discovery process.
Another drawback of UDDI is that it includes a lot of abstract information. This additional information is valuable where there is many (hundreds or thousands) of services registered and the client can then specify exactly which service is desired. However, where there are few services, this additional information may be overkill.
Whether using UDDI or something else, the key is that the SOA provides the ability to register services, and for clients to be able to locate and call these services without requiring either the client or the service to code location specifics.
Dig Deeper on Topics Archive
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.