WEB SERVICES
Web services are typically application programming interfaces (API) or web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services.
In common usage the term refers to clients and servers that communicate over the Hypertext Transfer Protocol (HTTP) protocol used on the web. Such services tend to fall into one of two camps: Big Web Services[1] and RESTful Web Services.
"Big Web Services" use Extensible Markup Language (XML) messages that follow the Simple Object Access Protocol (SOAP) standard and have been popular with traditional enterprise. In such systems, there is often a machine-readable description of the operations offered by the service written in the Web Services Description Language (WSDL). The latter is not a requirement of a SOAP endpoint, but it is a prerequisite for automated client-side code generation in many Java and .NET SOAP frameworks (frameworks such as Spring, Apache Axis2 and Apache CXF being notable exceptions). Some industry organizations, such as the WS-I, mandate both SOAP and WSDL in their definition of a web service.
Web services in a service-oriented architecture.
More recently, REpresentational State Transfer (REST) (RESTful web services are those conforming to the REST constraints) the REST web services have been regaining popularity, particularly with Internet companies. By using the PUT, GET and DELETE HTTP methods, alongside POST, these are often better integrated with HTTP and web browsers than SOAP-based services. They do not require XML messages or WSDL service-API definitions.
Web API is a development in web services (in a movement called Web 2.0) where emphasis has been moving away from Simple Object Access Protocol (SOAP) based services towards more direct Representational State Transfer (REST) style communications.[2] Web APIs allow the combination of multiple web services into new applications known as mashups.[3]
When used in the context of web development, web API is typically a defined set of Hypertext Transfer Protocol (HTTP) request messages along with a definition of the structure of response messages, usually expressed in an Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format.
When running composite web services, each sub service can be considered autonomous. The user has no control over these services. Also the web services themselves are not reliable; the service provider may remove, change or update their services without giving notice to users. The reliability and fault tolerance is not well supported; faults may happen during the execution. Exception handling in the context of web services is still an open research issue.
USE OF WEB SERVICE :
Web services are a set of tools that can be used in a number of ways. The three most common styles of use are RPC, SOA and REST.
[edit] Remote procedure calls
Architectural elements involved in the XML-RPC.
RPC Web services present a distributed function (or method) call interface that is familiar with many developers. Typically, the basic unit of RPC Web services is the WSDL operation.
The first Web services tools were focused on RPC, and as a result this style is widely deployed and supported. However, it is sometimes criticized for not being loosely coupled, because it was often implemented by mapping services directly to language-specific functions or method calls. Many vendors felt this approach to be a dead end, and pushed for RPC to be disallowed in the WS-I Basic Profile.
Other approaches with nearly the same functionality as RPC are Object Management Group's (OMG) Common Object Request Broker Architecture (CORBA), Microsoft's Distributed Component Object Model (DCOM) or Sun Microsystems's Java/Remote Method Invocation (RMI).
[edit] Service-oriented architecture
Web services can also be used to implement an architecture according to Service-oriented architecture (SOA) concepts, where the basic unit of communication is a message, rather than an operation. This is often referred to as "message-oriented" services.
SOA Web services are supported by most major software vendors and industry analysts. Unlike RPC Web services, loose coupling is more likely, because the focus is on the "contract" that WSDL provides, rather than the underlying implementation details.
Middleware Analysts use Enterprise Service Buses which combine message-oriented processing and Web Services to create an Event-driven SOA. One example of an open-source ESB is Mule, another one is Open ESB.
[edit] Representational state transfer
Representational State Transfer (REST) attempts to describe architectures which use HTTP or similar protocols by constraining the interface to a set of well-known, standard operations (like GET, POST, PUT, DELETE for HTTP). Here, the focus is on interacting with stateful resources, rather than messages or operations.
An architecture based on REST (one that is 'RESTful') can use WSDL to describe SOAP messaging over HTTP, can be implemented as an abstraction purely on top of SOAP (e.g., WS-Transfer), or can be created without using SOAP at all.
WSDL version 2.0 offers support for binding to all the HTTP request methods (not only GET and POST as in version 1.1) so it enables a better implementation of RESTful Web services.[8] However, support for this specification is still poor in software development kits, which often offer tools only for WSDL 1.1.
What is a Web service?
Many people and companies have debated the exact definition of Web services. At a minimum, however, a Web service is any piece of software that makes itself available over the Internet and uses a standardized XML messaging system.
XML is used to encode all communications to a Web service. For example, a client invokes a Web service by sending an XML message, then waits for a corresponding XML response. Because all communication is in XML, Web services are not tied to any one operating system or programming language--Java can talk with Perl; Windows applications can talk with Unix applications.
Beyond this basic definition, a Web service may also have two additional (and desirable) properties:
First, a Web service can have a public interface, defined in a common XML grammar. The interface describes all the methods available to clients and specifies the signature for each method. Currently, interface definition is accomplished via the Web Service Description Language (WSDL). (See FAQ number 7.)
Second, if you create a Web service, there should be some relatively simple mechanism for you to publish this fact. Likewise, there should be some simple mechanism for interested parties to locate the service and locate its public interface. The most prominent directory of Web services is currently available via UDDI, or Universal Description, Discovery, and Integration. (See FAQ number 8.)
Web services currently run a wide gamut from news syndication and stock-market data to weather reports and package-tracking systems. For a quick look at the range of Web services currently available, check out the XMethods directory of Web services.
What is new about Web services?
People have been using Remote Procedure Calls (RPC) for some time now, and they long ago discovered how to send such calls over HTTP.
So, what is really new about Web services? The answer is XML.
XML lies at the core of Web services, and provides a common language for describing Remote Procedure Calls, Web services, and Web service directories.
Prior to XML, one could share data among different applications, but XML makes this so much easier to do. In the same vein, one can share services and code without Web services, but XML makes it easier to do these as well.
By standardizing on XML, different applications can more easily talk to one another, and this makes software a whole lot more interesting.
Web services make possible the exchange of data in the form of XML messages between heterogeneous systems. Although remote access of data and application logic is not a new concept, doing so in a loosely coupled fashion is. Previous attempts, such as DCOM, IIOP, and Java/RMI, required tight integration between the client and the server and used platform and implementation specific binary data formats. While such protocols require a particular component technology or object-calling convention, Web services do not. The only assumption made between the client and the server is that recipients will understand the messages they receive. In other words, the client and server agree to a contract, in this case described using WSDL and XSD, and then communicate by generating messages that honor the contract over a specified transport like HTTP. As a result, programs written in any language, using any component model, and running on any operating system can access Web services. Furthermore, the flexibility of using a text format like XML makes possible the message exchange to evolve over time in a loosely coupled way. This loose coupling is mandatory in environments where the simultaneous updating of all parties in the message exchange is not possible.
You create Web services using the ASP.NET page framework, enabling these Web services to access the many features of the .NET Framework, such as authentication, caching, and state management. Because ASP.NET and the .NET Framework are the basis for Web services in managed code, developers can focus on creating or accessing Web services without needing to write infrastructure code.
In the ASP.NET application model, Web pages intended for the browser use the .aspx extension. To differentiate Web services from regular ASP.NET pages, Web services use the .asmx extension.
There are two fundamental roles when working with Web services:
*
Creating a Web service — When you create an XML Web service, you are creating an application that exposes functionality to XML Web service clients.
*
Accessing a Web service — When you access a Web service, your client application locates, references, and uses the functionality contained within a separate Web service. The client of an XML Web service is typically an application that is able to send, receive, and process messages to and from the Web service. However, the minimum requirement is that the client must be able to send messages to the Web service. This includes all applications using the .NET Framework.
Web services can be either stand-alone applications or sub-components of a larger Web application. For example, suppose you are creating a Web application that sells books online. Your Web application might interact with Web services as follows:
*
Creating Web service — Your application exposes its order processing logic as a Web service, which your affiliate Web sites can in turn use in their Web applications to sell books through your online store without requiring their customers to visit your site.
*
Accessing Web service — Your application accesses Web service provided by another online company that specializes in writing and supplying book reviews for online booksellers. When a visitor to your online store views the details of a particular book, they also see the reviews of that book on the same page.
Remember, Web services are accessible from just about any other kind of application, including other Web services, Web applications, Windows applications, and console applications. The minimum requirement is that the client must be able to send messages to the Web service.
