A Web service is a method of communication between two electronic devices over the web (internet).
The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network". It has an interface described in a machine-processable format (specifically Web Services Description Language, known by the acronym WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."
The W3C also states, "We can identify two major classes of Web services, REST-compliant Web services, in which the primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of "stateless" operations; and arbitrary Web services, in which the service may expose an arbitrary set of operations."
The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network". It has an interface described in a machine-processable format (specifically Web Services Description Language, known by the acronym WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards."
The W3C also states, "We can identify two major classes of Web services, REST-compliant Web services, in which the primary purpose of the service is to manipulate XML representations of Web resources using a uniform set of "stateless" operations; and arbitrary Web services, in which the service may expose an arbitrary set of operations."
What are Web Services?
- Web services are application components
- Web services communicate using open protocols
- Web services are self-contained and self-describing
- Web services can be discovered using UDDI
- Web services can be used by other applications
- XML is the basis for Web services
How Does it Work?
The basic Web services platform is XML + HTTP.
XML provides a language which can be used between different platforms and programming languages and still express complex messages and functions.
The HTTP protocol is the most used Internet protocol.
Web services platform elements:
The basic Web services platform is XML + HTTP.
XML provides a language which can be used between different platforms and programming languages and still express complex messages and functions.
The HTTP protocol is the most used Internet protocol.
Web services platform elements:
- SOAP (Simple Object Access Protocol)
- UDDI (Universal Description, Discovery and Integration)
- WSDL (Web Services Description Language)
By using Web services, your application can publish its function or message to the rest of the world.
Web services use XML to code and to decode data, and SOAP to transport it (using open protocols).
With Web services, your accounting department's Win 2k server's billing system can connect with your IT supplier's UNIX server.
Web services can offer application-components like: currency conversion, weather reports, or even language translation as services.
Web services can help to solve the interoperability problem by giving different applications a way to link their data.
With Web services you can exchange data between different applications and different platforms.
Web API is a development in Web services (in a movement called Web 2.0) where emphasis has been moving away from SOAP based services towards representational state transfer (REST) based communications. REST services do not require XML, SOAP, or WSDL service-API definitions.
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.
What is SOAP?
SOAP is an XML-based protocol to let applications exchange information over HTTP.
Or more simple: SOAP is a protocol for accessing a Web Service.
Web services use XML to code and to decode data, and SOAP to transport it (using open protocols).
With Web services, your accounting department's Win 2k server's billing system can connect with your IT supplier's UNIX server.
Web services can offer application-components like: currency conversion, weather reports, or even language translation as services.
Web services can help to solve the interoperability problem by giving different applications a way to link their data.
With Web services you can exchange data between different applications and different platforms.
Web API is a development in Web services (in a movement called Web 2.0) where emphasis has been moving away from SOAP based services towards representational state transfer (REST) based communications. REST services do not require XML, SOAP, or WSDL service-API definitions.
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.
What is SOAP?
SOAP is an XML-based protocol to let applications exchange information over HTTP.
Or more simple: SOAP is a protocol for accessing a Web Service.
- SOAP stands for Simple Object Access Protocol
- SOAP is a communication protocol
- SOAP is a format for sending messages
- SOAP is designed to communicate via Internet
- SOAP is platform independent
- SOAP is language independent
- SOAP is based on XML
- SOAP is simple and extensible
- SOAP allows you to get around firewalls
- SOAP is a W3C standard
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.
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.
Understanding REST (Representational state transfer)
REST is not a protocol like SOAP is; it is an architectural design. An architecture for building services that build on HTTP. REST attempts to describe architectures that use HTTP or similar protocols by constraining the interface to a set of well-known, standard operations (like GET, POST, PUT, DELETE for HTTP).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.
Fundamentally different from SOAP
SOAP defines a transport neutral model focused on custom operations
REST defines transport specific (HTTP) model focused on resources.
What is WSDL?
WSDL is an XML-based language for locating and describing Web services.
- WSDL stands for Web Services Description Language
- WSDL is based on XML
- WSDL is used to describe Web services
- WSDL is used to locate Web services
- WSDL is a W3C standard
Even with a simple protocol like SOAP, web services wouldn’t be much good to us if we had no way of finding them. Luckily IBM, Microsoft, and Ariba stepped in and started the Universal Description, Discovery and Integration (UDDI) project, which they hope will be the definitive directory to services over the web.
The UDDI allows companies to offer their web services to other companies by acting like a telephone book for web services. There are no costs associated with registering your web service in the UDDI, and the founders hope it will provide a central reference listing all the services residing across the net, so that developers looking for a service can simply use the UDDI to locate the most appropriate provider.
What is UDDI?
UDDI is a directory service where companies can register and search for Web services.
The UDDI allows companies to offer their web services to other companies by acting like a telephone book for web services. There are no costs associated with registering your web service in the UDDI, and the founders hope it will provide a central reference listing all the services residing across the net, so that developers looking for a service can simply use the UDDI to locate the most appropriate provider.
What is UDDI?
UDDI is a directory service where companies can register and search for Web services.
- UDDI stands for Universal Description, Discovery and Integration
- UDDI is a directory for storing information about web services
- UDDI is a directory of web service interfaces described by WSDL
- UDDI communicates via SOAP
- UDDI is built into the Microsoft .NET platform
Advantages
Web Services offer many benefits over other types of distributed computing architectures.
Web Services offer many benefits over other types of distributed computing architectures.
- Interoperability - This is the most important benefit of Web Services. Web Services typically work outside of private networks, offering developers a non-proprietary route to their solutions. Services developed are likely, therefore, to have a longer life-span, offering better return on investment of the developed service. Web Services also let developers use their preferred programming languages. In addition, thanks to the use of standards-based communications methods, Web Services are virtually platform-independent.
- Usability - Web Services allow the business logic of many different systems to be exposed over the Web. This gives your applications the freedom to chose the Web Services that they need. Instead of re-inventing the wheel for each client, you need only include additional application-specific business logic on the client-side. This allows you to develop services and/or client-side code using the languages and tools that you want.
- Reusability - Web Services provide not a component-based model of application development, but the closest thing possible to zero-coding deployment of such services. This makes it easy to reuse Web Service components as appropriate in other services. It also makes it easy to deploy legacy code as a Web Service.
- Deployability - Web Services are deployed over standard Internet technologies. This makes it possible to deploy Web Services even over the fire wall to servers running on the Internet on the other side of the globe. Also thanks to the use of proven community standards, underlying security (such as SSL) is already built-in.
Disadvantages
Although the simplicity of Web services is an advantage in some respects, it can also be a hindrance. Web services use plain text protocols that use a fairly verbose method to identify data. This means that Web service requests are larger than requests encoded with a binary protocol. The extra size is really only an issue over low-speed connections, or over extremely busy connections.
Although HTTP and HTTPS (the core Web protocols) are simple, they weren't really meant for long-term sessions. Typically, a browser makes an HTTP connection, requests a Web page and maybe some images, and then disconnects. In a typical CORBA or RMI environment, a client connects to the server and might stay connected for an extended period of time. The server may periodically send data back to the client. This kind of interaction is difficult with Web services, and you need to do a little extra work to make up for what HTTP doesn't do for you.
The problem with HTTP and HTTPS when it comes to Web services is that these protocols are "stateless"—the interaction between the server and client is typically brief and when there is no data being exchanged, the server and client have no knowledge of each other. More specifically, if a client makes a request to the server, receives some information, and then immediately crashes due to a power outage, the server never knows that the client is no longer active. The server needs a way to keep track of what a client is doing and also to determine when a client is no longer active.
Typically, a server sends some kind of session identification to the client when the client first accesses the server. The client then uses this identification when it makes further requests to the server. This enables the server to recall any information it has about the client. A server must usually rely on a timeout mechanism to determine that a client is no longer active. If a server doesn't receive a request from a client after a predetermined amount of time, it assumes that the client is inactive and removes any client information it was keeping. This extra overhead means more work for Web service developers.
How Popular is REST?
All of the major webservices on the Internet now use REST: Twitter, Yahoo’s web services use REST, others include Flickr, del.icio.us, pubsub, bloglines, technorati, and several others. Both eBay and Amazon have web services for both REST and SOAP.
and SOAP?
SOAP is mostly used for Enterprise applications to integrate wide types and no. of applications and another trend is to integrate with legacy systems, etc. On the Internet side of things — Google is consistent in implementing their web services using SOAP, with the exception of Blogger, which uses XML-RPC.
REST vs SOAP
The companies that use REST APIs haven’t been around for very long, and their APIs came out this year or last year mostly. So REST is definitely In-Vogue for creating a web service. But, lets face it — Use SOAP to wash, and you REST when your tired). The main advantages of REST web services are:
Although the simplicity of Web services is an advantage in some respects, it can also be a hindrance. Web services use plain text protocols that use a fairly verbose method to identify data. This means that Web service requests are larger than requests encoded with a binary protocol. The extra size is really only an issue over low-speed connections, or over extremely busy connections.
Although HTTP and HTTPS (the core Web protocols) are simple, they weren't really meant for long-term sessions. Typically, a browser makes an HTTP connection, requests a Web page and maybe some images, and then disconnects. In a typical CORBA or RMI environment, a client connects to the server and might stay connected for an extended period of time. The server may periodically send data back to the client. This kind of interaction is difficult with Web services, and you need to do a little extra work to make up for what HTTP doesn't do for you.
The problem with HTTP and HTTPS when it comes to Web services is that these protocols are "stateless"—the interaction between the server and client is typically brief and when there is no data being exchanged, the server and client have no knowledge of each other. More specifically, if a client makes a request to the server, receives some information, and then immediately crashes due to a power outage, the server never knows that the client is no longer active. The server needs a way to keep track of what a client is doing and also to determine when a client is no longer active.
Typically, a server sends some kind of session identification to the client when the client first accesses the server. The client then uses this identification when it makes further requests to the server. This enables the server to recall any information it has about the client. A server must usually rely on a timeout mechanism to determine that a client is no longer active. If a server doesn't receive a request from a client after a predetermined amount of time, it assumes that the client is inactive and removes any client information it was keeping. This extra overhead means more work for Web service developers.
How Popular is REST?
All of the major webservices on the Internet now use REST: Twitter, Yahoo’s web services use REST, others include Flickr, del.icio.us, pubsub, bloglines, technorati, and several others. Both eBay and Amazon have web services for both REST and SOAP.
and SOAP?
SOAP is mostly used for Enterprise applications to integrate wide types and no. of applications and another trend is to integrate with legacy systems, etc. On the Internet side of things — Google is consistent in implementing their web services using SOAP, with the exception of Blogger, which uses XML-RPC.
REST vs SOAP
The companies that use REST APIs haven’t been around for very long, and their APIs came out this year or last year mostly. So REST is definitely In-Vogue for creating a web service. But, lets face it — Use SOAP to wash, and you REST when your tired). The main advantages of REST web services are:
- Lightweight – not a lot of extra xml markup
- Human Readable Results
- Easy to build – no toolkits required
SOAP also has some advantages:
- Easy to consume – sometimes
- Rigid – type checking, adheres to a contract
- Development tools
source: wikipedia & other references
No comments:
Post a Comment