While building a Web Service (WS), you will design a Consumer Class and an Implementation Class.

An Implementation Class contains code/methods that are to be shared with different Consumers. Easiest way to go about the design would be a create an Interface for the Implementation Class and any Consumer would consume the Implementation Class through the Interface i.e. they will call the implementation through the interface, they get to know the contract, and the methods of the implementation through the interface. An Interface is a standard way in which you can share any contract like this with a Consumer.

When you plan to wrap your Implementation Class into a Web Service, an Interface in the middle would not work. Eliminate the Interface when you create a Web Service.
e.g. A C++ Consumer may not like a Java Interface. An Interface should be technology independent, but since a Java WS can only have a Java Interface, a C++ consumer cannot consume the Java WS through this incompatible Java Interface.

When you create a Web Service and you want to share the contract of the Web Service, you actually share the contract of the Web Service as an XML document. This XML document is actually called a WSDL (Web Services Description Language). The WSDL document contains the contract to your Web Service. When you create a WS, you share the WSDL document off that WS with the Consumers. You can generate the WSDL either manually or using tools that generate the WSDL for the WS.

The content of the WSDL is similar to what an interface does viz. a WSDL will contain the method signatures (operations) or the list of methods that can be called from the Web Service, what are the arguments, what is the return type.

UDDI (Universal Description and Discovery Integration) is the directory that contains information about the Web Service. UDDI is like the Yellow Pages of Web Services, the directory of the Web Services. UDDI is the registry where Web Services are registered. Anybody who wants to consume the Web Service can query the UDDI and can find the Web Service, get the WSDL and then use the Web Service.

Say you have queried the UDDI and have retrieved the WSDL and your Client Application now calls the Web Service. Whenever you are sending any info. from the Client App over the network to a WS and info. from the WS back to the Client App it has to be in an XML format. Info. has to be sent back and forth in a language neutral format and i.e. XML. The XML protocol is called SOAP (Simple Object Access Protocol).

e.g.

Client App (Java String to be sent to the WS)
XML protocol (SOAP message)
WS (written in C++ which accepts a String and returns a list)

Now, how is the Java String converted into a SOAP message? This conversion is done by SEI (Service Endpoint Interface) sitting within the Client App.

SEI acts as an Interface to your WS endpoint. SEI translates the WS call into a SOAP message and the WS is then able to understand this SOAP message. SEI can be automatically created and generated for us. You can have a SEI pertaining to your Client App, meaning you can have a SEI for your Java App which converts the WS call into an appropriate SOAP message.

In a nutshell-

* WSDL describes what a WS is in an XML format
* UDDI is a registery of WS
* SOAP is a protocol, a language, an XML format which is used to encode and decode messages sent between the Client App and the WS
* SEI is an interface to the WS end point that provides a way for your Client App to call the WS. Depending on the Client App technology you can generate the SEI e.g. a Java Client app can have a Java SEI, a .NET Client App can have a .NET SEI