Does NuSOAP support UDDI?

Question

Maybe I don't fully understand what UDDI is all about, but I'm thinking a technique for publishing all offered services on one server?

By "server" should I understand a physical address (like www.example.com) or just the programmed tool (e.g. speaking about NuSOAP a PHP file including nusoap.php)?

So if the server is just the PHP file, appending ?wsdl to the file would give me a listing of all registered functions. Is this already what is called UDDI?

And finally, does NuSOAP support UDDI?

Answer 1

It seems you have some things mixed up so let's try to clear some of the confusion. First some definitions!

A web service is a way of allowing machine to machine communication. When you expose some operations over the network, you create a web service. Other machines "talk" to your machine using these operations and they become clients of your web service. The clients request information from your web service and it's said that they "consume" your web service. And of course you can't have a consumer without a provider so you have a web service "provider".

But how do the machines know how to talk to each other?

SOAP is a protocol for exchanging information. It defines a common ground of discussion (machines talk the same language) by wrapping a message in a standard envelope + header + body request.

But how about the message itself? How is that defined? When you expose a web service you have to tell others how to implement a client (i.e. document your operations, and messages to send or expect back). You could do this using a PDF for example where you detail the operations, the message formats, the type of parameters etc. But there is a better way, one that allows you to generate clients on the fly: a WSDL (by convention accessible from adding ?wsdl on the web service endpoint address).

A WSDL provides a machine-readable description of how the service can be called, what parameters it expects, and what it return (basically what contract you must respect to be able to call it). There are tools that can read a WSDL and either create code for your web service client or provide utility functions that make it easier for you to call the web service without resorting to low level manipulations of messages.

NuSOAP is such a tool. It's a set of PHP classes that allows you to consume SOAP web services.

But after you have everything you need to be able to perform a call, how do you know where the web service address is for you to make that call?

As a hint, you can find it inside the WSDL but that can't always be reliable so you have to get it from the web service provider. You then use that address to call the web service again and again and again.

But what if the provider does some changes to its infrastructure and now the web service is exposed on another address? Your client no longer works because it connects at the old address. You again have to get an address from the provider. Wouldn't it be easier if you could somehow discover this address at runtime and then connect to the web service?

What if the provider has the same service exposed multiple times at different addresses (as backup)? You could connect to one and if something went wrong you could search for another web service exposing the same contract.

But if we are talking about contracts why limit yourself to a single provider? Why not search for a service that exposes a certain contract no matter the provider? .... and things kinda got out of hand at this point as people imagined a world where services will spontaneously connect with each other by using a registry acting as the yellow (three colors actually) pages of web services.

UDDI is a registry where producers register their web services while consumers query the registry to find web services with a certain contract and later connect to what they found. The interaction is like this:

http://juddi.apache.org/docs/3.x/userguide/html/chap-UDDI_Registry.html

This idea works well inside an enterprise that defines the contracts and creates the implementations and all web services are of known quality and functionality. But online it doesn't work.

Without proper a priory tests and verifications and something that guaranties that the web service won't evolve in an unwanted direction or stop evolving at all for that matter, there is no proper way of verifying if a service is actually doing what it advertises it does.

As a result of all that, (public) UDDI isn't actually used in the wild but is somewhat used in enterprises because enterprises sign contracts that define the rules that guaranty that what you get back from the (private) UDDI is the real thing.

In conclusion (to make sure I fully addressed your questions) a UDDI is a place where providers publish information about their web services. This includes specifications, interfaces etc, and also the endpoint address. It's just information about the web service, it's not the web service itself so nusoap.php will not get published to the registry.

As for NuSOAP supporting UDDI, it's not clear what you understand by that. UDDI is accessible with a SOAP API so you can use NuSOAP to simplyfy access to it, if that's what you are asking.