|only for RuBoard|
XML web services represent the next evolution (revolution?) of distributed computing. Web services are a testament to the fact that often in computing, simplicity can be elegant.
Essentially, a web service is a specialized web server that listens and responds to SOAP messages (of a particular type) over HTTP. The implementation of web services and clients is irrelevant: the client sends a request to a known URL in a predetermined format. A web service only needs to process that message and send back a response. It is as simple as that. As long as an Internet connection is available, the client can be a browser or a background process, or it can have a feature-rich GUI—and it can exist on any platform that supports the HTTP, SOAP, and XML protocols.
The use of industry-standard protocols is not accidental. XML web services are not a Microsoft-centric technology, but rather a global effort involving just about every major player in computing. The driving force behind web services is the need to provide cross-platform services over the Internet.
.NET brings encapsulation to XML web services. The communication details are completely hidden, making it possible to write a web service without any knowledge of HTTP, SOAP, or XML. This feature allows the developer to shift focus toward the application itself and providing services, rather than being caught up in what some would consider tedious implementation details.
For the most part, writing an XML web service under .NET is just like writing any other class. The same can be said for consuming an XML web service. A component that contains web services looks and feels just like any other component to the .NET developer. It just so happens that the method calls are invoked over the Internet. However, web service class design is constrained because web services are inherently stateless, much like a SingleCall object under .NET remoting.
|only for RuBoard|