Web service: Difference between revisions

Content deleted Content added
No edit summary
m Reverted edits by JohnnyApplesauce234 (talk) (AV)
 
Line 1:
{{Short description|Service offered between electronic devices via the internet}}
{| class= "rimage"
A '''web service''' ('''WS''') is either:
|[[Image:webservices.png]]
* a service offered by an electronic device to another electronic device, communicating with each other via the [[Internet]], or
|}
* a server running on a computer device, listening for requests at a particular port over a network, serving web documents ([[HTML]], [[JSON]], [[XML]], images).{{cn|date=March 2023}}
The [[W3C]] defines a '''Web service'''<ref>Many sources also capitalize the second word, as in Web '''S'''ervices</ref> as a software system designed to support [[interoperability|interoperable]] machine-to-machine interaction over a [[computer network|network]]. Web services are frequently just [[Application programming interface|application programming interfaces]] (API) that can be accessed over a network, such as the [[Internet]], and executed on a remote system hosting the requested services.
 
In a web service, a web technology such as [[HTTP]] is used for transferring machine-readable file formats such as [[XMLHttpRequest|XML]] and JSON.
The [[W3C]] Web service definition encompasses many different systems, but in common usage the term refers to those services that use [[SOAP]]-formatted [[XML]] envelopes and have their [[Interface (computer science)|interfaces]] described by [[Web Services Description Language|WSDL]]. For example, [[WS-I]] only recognizes Web services in the context of these specifications.
 
In practice, a web service commonly provides an [[Object database|object-oriented]] web-based interface to a database server, utilized for example by another web server, or by a [[Mobile app development|mobile app]], that provides a user interface to the end-user. Many organizations that provide data in formatted HTML pages will also provide that data on their server as XML or JSON, often through a Web service to allow [[Web syndication|syndication]]. Another application offered to the end-user may be a [[Mashup (web application hybrid)|mashup]], where a Web server consumes several Web services at different machines and compiles the content into one user interface.
== Core specifications ==
The specifications that define '''Web services''' are intentionally modular, and as a result there is no one document that defines it. Instead, there are a few "core" specifications that are supplemented by others as the circumstances and choice of technology dictate. The most common are:
 
==Web services (generic)==
* [[SOAP]]: An [[XML]]-based, extensible message envelope format, with "bindings" to underlying protocols (e.g., [[HTTP]], [[Simple Mail Transfer Protocol|SMTP]] and [[Extensible Messaging and Presence Protocol|XMPP]]).
===Asynchronous JavaScript and XML===
*[[Web Services Description Language|WSDL]]: An [[XML]] format that allows service interfaces to be described, along with the details of their bindings to specific protocols. Typically used to generate server and client code, and for configuration.
{{Main Article | Ajax (programming)}}
*[[UDDI]]: A protocol for publishing and discovering metadata about Web services, to enable applications to find Web services, either at design time or runtime.
*[[WS-Security]]: Defines how to use [[XML Encryption]] and [[XML Signature]] in [[SOAP]] to secure message exchanges.
*[[WS-ReliableMessaging]]: A protocol for reliable messaging between two Web services.
 
Asynchronous JavaScript and XML (AJAX) is a dominant technology for Web services. Developing from the combination of HTTP servers, JavaScript clients and [[Plain Old XML]] (as distinct from [[SOAP]] and W3C Web Services), now it is frequently used with [[JSON Web Token|JSON]] as well as, or instead of, XML.
Most specifications are standardized at [[OASIS (organization)|OASIS]] and the [[World Wide Web Consortium|W3C]]. Additionally, [[WS-I]] develops profiles, sample applications and test tools to further promote Web services interoperability.
 
===REST===
See [[List of Web service specifications]] for a more complete listing.
{{Main Article | REST}}
Representational State Transfer (REST) is an architecture for well-behaved Web services that can function at Internet scale.
 
In a 2004 document, the W3C sets following REST as a key distinguishing feature of Web services:
==Styles of use==
{{Quote | text = 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 resource]]<nowiki>s</nowiki> using a uniform set of [[Stateless protocol|stateless]] operations; and
*arbitrary Web services, in which the service may expose an arbitrary set of operations. | author = W3C | source = Web Services Architecture<ref>{{cite web |url=https://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#relwwwrest |title=Web Services Architecture § Relationship to the World Wide Web and REST Architectures |website=[[World Wide Web Consortium|W3C]] |access-date=11 November 2017}}</ref>|title=}}
 
===Technologies and protocols related to web services using markup languages===
Web services is 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.
There are a number of Web services that use markup languages:
* [[JSON-RPC]].
* [[JSON-WSP]]
* [[Representational state transfer]] (REST) versus [[remote procedure call]] (RPC)
* [[Simple Object Access Protocol]]
* [[Web Services Conversation Language]] (WSCL)
* [[Web Services Description Language]] (WSDL), developed by the [[World Wide Web Consortium|W3C]]
* [[Web Services Flow Language]] (WSFL), superseded by [[Business Process Execution Language|BPEL]]
* [[Web template]]
* [[WS-MetadataExchange]]
* [[XML Interface for Network Services]] (XINS), provides a [[Plain Old XML|POX]]-style web service specification format
 
===RemoteWeb Procedure CallsAPI===
{{Main Article| Web API}}
[[Image:webservice_xrpc.png|thumb|Architectural elements involved in the XML-RPC.]]
A [[Web API]] is a development in Web services where emphasis has been moving to simpler [[representational state transfer]] (REST) based communications.<ref>{{cite journal |last1=Benslimane |first1=D. |last2=Dustdar |first2=S. |last3=Sheth |first3=A. |author3-link=Amit Sheth |year=2008 |title=Services Mashups: The New Generation of Web Applications |url=https://works.bepress.com/amit_sheth/292/download/ |journal=[[IEEE Internet Computing]] |language=en-US |volume=10 |issue=5 |pages=13–15 |doi=10.1109/MIC.2008.110 |s2cid=8124905}}</ref> Restful APIs do not require XML-based Web service protocols ([[SOAP]] and WSDL) to support their interfaces.
'''[[Remote_procedure_call|RPC]] Web services''' present a distributed function (or method) call interface that is familiar to many developers. Typically, the basic unit of RPC Web services is the WSDL operation.
 
==W3C Web services==
The first Web services tools were focused on RPC, and as a result this style is widely deployed and supported. However, it is sometimes criticised for not being [[Loose coupling|loosely coupled]], because it was often implemented by mapping services directly to language-specific function 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]].
In relation to W3C Web services, the [[W3C]] defined a Web service as:
{{Quote | text = A web service is 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|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. | author = W3C | source = Web Services Glossary<ref name=W3WSG>{{cite web |url=https://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#webservice |title=Web Services Glossary § Web service |date=11 February 2004 |website=[[World Wide Web Consortium|W3C]] |access-date=24 January 2017}}</ref>
}}
 
W3C Web Services may use SOAP over HTTP protocol, allowing less costly (more efficient) interactions over the Internet than via proprietary solutions like EDI/B2B. Besides SOAP over HTTP, Web services can also be implemented on other reliable transport mechanisms like [[File Transfer Protocol|FTP]]. In a 2002 document, the [https://www.w3.org/2002/ws/arch/ Web Services Architecture Working Group] defined a Web services architecture, requiring a standardized implementation of a "Web service."
===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.
 
===Explanation===
SOA Web services are espoused 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.
[[File:Webservices-en.svg|thumb|right|Web services architecture: the service provider sends a WSDL file to UDDI. The service requester contacts UDDI to find out who is the provider for the data it needs, and then it contacts the service provider using the SOAP protocol. The service provider validates the service request and sends structured data in an XML file, using the SOAP protocol. This XML file would be validated again by the service requester using an XSD file.]]
 
The term "Web service" describes a standardized way of integrating Web-based applications using the [[XML]], SOAP, WSDL and UDDI open standards over an [[Internet Protocol]] backbone. XML is the data format used to contain the data and provide metadata around it, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI lists what services are available.
===Representational State Transfer===
Finally, '''[[REST]]ful Web services''' attempt to emulate HTTP and similar protocols by constraining the interface to a set of well-known, standard operations (e.g., GET, PUT, DELETE). Here, the focus is on interacting with stateful resources, rather than messages or operations.
 
A Web service is a method of communication between two electronic devices over a network. It is a software function provided at a [[network address]] over the Web with the service ''always-on'' as in the concept of utility computing.
RESTful Web services can use WSDL to describe SOAP messaging over HTTP, which defines the operations, or can be implemented as an abstraction purely on top of SOAP (e.g., WS-Transfer).
 
Many organizations use multiple software systems for management.{{citation needed|date=August 2015}} Different software systems often need to exchange data with each other, and a Web service is a method of communication that allows two software systems to exchange this data over the Internet. The software system that requests data is called a ''service requester'', whereas the software system that would process the request and provide the data is called a ''[[service provider]]''.
==Criticisms==
 
Different software may use different programming languages, and hence there is a need for a method of [[data exchange]] that doesn't depend upon a particular programming language. Most types of software can, however, interpret XML tags. Thus, Web services can use XML files for data exchange.
Critics of non-RESTful Web services often complain that they are too complex <ref>http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research</ref> and biased towards large software vendors or integrators, rather than [[Open_source|open source]] implementations.
 
Rules for communication with different systems need to be defined, such as:
There are also concerns about performance, because of Web services' use of XML as a message format.
* How one system can request data from another system.
* Which specific parameters are needed in the data request.
* What would be the structure of the data produced. (Normally, data is exchanged in XML files, and the structure of the XML file is validated against a .xsd file.)
* What error messages to display when a certain rule for communication is not observed, to make [[troubleshooting]] easier.
 
All of these rules for communication are defined in a file called [[Web Services Description Language|WSDL]] (Web Services Description Language), which has a <code>.wsdl</code> extension. (Proposals for '''Autonomous Web Services''' ('''AWS''') seek to develop more flexible Web services that do not rely on strict rules.{{efn|1=Compare: {{harvnb|Oya|2008}}, "Under the current Web Services, […] stakeholder systems must follow the predefined rules for a particular business service including those about business protocols to send/receive messages and about system operation. […] More flexible mechanism is desired where freely built and autonomously running systems can exchange business messages without pre-agreed strict rules. We call it Autonomous Web Services (AWS) and proposed the framework called Dynamic Model Harmonization (DMH) with its algorithm, which dynamically adjusts different business process models between systems […]."<ref>
==Similar efforts==
{{cite book | last1 = Oya | first1 = Makoto | chapter = Autonomous Web Services Based on Dynamic Model Harmonization | editor1-last = Oya | editor1-first = Makoto | editor2-last = Uda | editor2-first = Ryuya | editor3-last = Yasunobu | editor3-first = Chizuko | title = Towards Sustainable Society on Ubiquitous Networks: The 8th IFIP Conference on E-Business, E-Services, and E-Society (I3E 2008), September 24 – 26, 2008, Tokyo, Japan | url = https://books.google.com/books?id=__WWduWBk7IC | series = IFIP Advances in Information and Communication Technology | volume = 286 | publisher = Springer Science & Business Media | publication-date = 2008 | page = 139 | isbn = 9780387856902 | access-date = 2015-08-19 | date = 2008-09-02 }}</ref>}})
 
A directory called [[Universal Description Discovery and Integration|UDDI]] (Universal Description, Discovery, and Integration) defines which software system should be contacted for which type of data. So when one software system needs one particular report/data, it would go to the UDDI and find out which other systems it can contact for receiving that data. Once the software system finds out which other systems it should contact, it would then contact that system using a special protocol called [[SOAP]] (Simple Object Access Protocol). The service provider system would first validate the data request by referring to the WSDL file, and then process the request and send the data under the SOAP protocol.
There are several other approaches to the set of problems that Web services attempts to address, both preceding and contemporary to it. [[Java remote method invocation|RMI]] was one of many [[Middleware|middleware]] systems that have seen wide deployment. More ambitious efforts like [[CORBA]] and [[Distributed Component Object Model|DCOM]] both attempted to effect distributed [[object oriented programming|objects]], which Web services implementations sometimes try to mimic.
 
===Automated design methods{{anchor|Design methods}}===
More basic efforts include [[XML-RPC]], a precursor to SOAP that was only capable of RPC, and various forms of using [[HTTP]] without SOAP.
[[File:SOA Detailed Diagram.png|thumb|right|upright=2|Web services in a [[service-oriented architecture]].]]
 
Automated tools can aid in the creation of a Web service. For services using WSDL, it is possible to either automatically generate WSDL for existing classes (a bottom-up model) or to generate a class skeleton given existing WSDL (a top-down model).
==See also==
* A developer using a bottom-up model writes implementing classes first (in some programming language) and then uses a WSDL generating tool to expose methods from these classes as a Web service. This is simpler to develop but may be harder to maintain if the original classes are subject to frequent change.<ref>{{cite web |url=http://help.eclipse.org/kepler/index.jsp?topic=/org.eclipse.jst.ws.doc.user/concepts/cwsbtmup.html |title=Creating bottom-up Web services |website=[[Eclipse (software)|Eclipse]] |access-date=11 November 2017}}</ref>
*[[List of Web service Frameworks]]
* A developer using a top-down model writes the WSDL document first and then uses a code generating tool to produce the class skeleton, to be completed as necessary. This model is generally considered more difficult but can produce cleaner designs and is generally more resistant to change. As long as the message formats between the sender and receiver do not change, changes in the sender and receiver themselves do not affect the Web service. The technique is also referred to as ''contract first'' since the WSDL (or contract between sender and receiver) is the starting point.<ref>{{cite web |url=http://help.eclipse.org/kepler/index.jsp?topic=/org.eclipse.jst.ws.doc.user/concepts/cwstopdown.html |title=Creating top-down Web services |website = [[Eclipse (software)|Eclipse]] |access-date=11 November 2017}}</ref>
* A developer using a Subset WSDL (SWSDL)<ref name=SWSDL>{{cite conference |doi=10.1109/CloudCom.2014.149 |conference=2014 IEEE 6th International Conference on Cloud Computing Technology and Science |title=Subset WSDL to Access Subset Service for Analysis |pages=688 |year=2014 |last=Chaturvedi |first=Animesh |isbn=978-1-4799-4093-6}}</ref> (i.e. a WSDL with the subset operation in the original WSDL) can perform Web service testing and top-down development.
 
==External links=Criticism===
*[http://www.w3.org/2002/ws/ W3C Web Services Activity home page]
*[http://www.w3.org/TR/ws-arch/ Web Services Architecture] (W3C Working Group Note)
*[http://msdn.microsoft.com/webservices/webservices/understanding/advancedwebservices/default.aspx?pull=/library/en-us/dnwebsrv/html/introwsa.asp An Introduction to the Web Services Architecture and its Specifications] (Microsoft white paper)
*[http://www-128.ibm.com/developerworks/webservices/library/ws-securtrans/ Secure, Reliable, Transacted Web Services] (IBM/Microsoft white paper)
 
Critics of non-RESTful Web services often complain that they are too complex<ref>{{cite web |last=Bray |first=Tim |author-link=Tim Bray |date=2004-10-28 |title=WS-Pagecount |url=http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research |access-date=2011-04-22 |publisher=TBray.org |language=en-US}}</ref> and based upon large software vendors or integrators, rather than typical [[Open-source model|open source]] implementations.
<!-- ==============================({{NoMoreLinks}})============================== -->
<!-- DO NOT ADD MORE LINKS TO THIS ARTICLE. WIKIPEDIA IS NOT A COLLECTION OF LINKS -->
<!-- If you think that your link might be useful, instead of placing it here, put -->
<!-- it on this article's discussion page first. Links that have not been verified -->
<!-- WILL BE DELETED -->
<!-- ============================================================================= -->
 
There are also concerns about performance due to Web services' use of XML as a message format and SOAP/HTTP in enveloping and transporting.<ref>{{cite journal |url=http://ro.uow.edu.au/infopapers/676/ |title=Performance of Java Middleware – Java RMI, JAX-RPC, and CORBA |last=Gray |first=N. A. B. |journal=[[University of Wollongong]] |pages=31–39 |year=2005 |quote=The results presented in this paper show that the nature of response data has a greater impact on relative performance than has been allowed for in most previous studies.}}</ref>
----
 
===Regression testing of Web services===
Functional and non-functional testing of Web services is done with the help of WSDL parsing. [[Regression testing]] is performed by identifying the changes made to upgrade software. Web service regression testing needs can be categorized in three different ways, namely, changes in WSDL, changes in the code, and selective re-testing of operations. We can capture the above three needs in three intermediate forms of Subset WSDL,<ref name=SWSDL /> namely, Difference WSDL (DWSDL), Unit WSDL (UWSDL), and Reduced WSDL (RWSDL), respectively. These three Subset WSDLs are then combined to form Combined WSDL (CWSDL) that is further used for regression testing of the Web service. This will help in Automated Web Service Change Management (AWSCM),<ref name=AWSCM /> by performing the selection of the relevant test cases to construct a reduced test suite from the old test suite.
<ref>{{cite conference |doi=10.1109/MESOCA.2013.6632734 |conference=2013 IEEE 7th International Symposium on the Maintenance and Evolution of Service-Oriented and Cloud-Based Systems |title=A tool-supported approach to perform efficient regression testing of Web services |pages=50 |year=2013 |last1=Chaturvedi |first1=Animesh |last2=Gupta |first2=Atul |isbn=978-1-4673-4889-8}}</ref>
 
Web services testing can also be automated using several test automation tools like [[SoapUI]], [[Oracle Application Testing Suite]] (OATS),<ref>[http://www.oracle.com/technetwork/oem/app-test/etest-101273.html Oracle Application Testing Suite]</ref><ref>[http://www.testingtools.co/automation/web-services-testing-using-oracle-application-testing-suite-oats Web Services Testing using Oracle Application Testing Suite]</ref> Unified Functional Testing, Selenium, etc.
 
===Web service change management===
Work-related to the capture and visualization of changes made to a Web service. Visualization and computation of changes can be done in the form of intermediate artifacts (Subset WSDL).<ref name=SWSDL /> The insight on the computation of change impact is helpful in testing, top-down development and reduce regression testing. AWSCM<ref name=AWSCM>{{cite conference |doi=10.1109/CloudCom.2014.144 |conference=2014 IEEE 6th International Conference on Cloud Computing Technology and Science |title=Automated Web Service Change Management AWSCM - A Tool |pages=715 |year=2014 |last=Chaturvedi |first=Animesh |isbn=978-1-4799-4093-6}}</ref> is a tool that can identify subset operations in a WSDL file to construct a subset WSDL.
 
=== Discovering and Searching for Web Services ===
While UDDI was intended to serve as a service directory and become the means to discovering web services, many vendors discontinued their UDDI solutions or repositories between 2005-2008, including Microsoft, SAP, IBM, among others.<ref>{{Cite web |last=Krill |first=Paul |date=2005-12-16 |title=Microsoft, IBM, SAP discontinue UDDI registry effort |url=https://www.infoworld.com/article/2673442/microsoft--ibm--sap-discontinue-uddi-registry-effort.html |access-date=2022-05-28 |website=InfoWorld |language=en}}</ref><ref>{{Cite web |last=QuinnRadich |title=Removal of UDDI Services from Server Operating System – Win32 apps |url=https://docs.microsoft.com/en-us/windows/win32/win7appqual/removal-of-uddi-services-from-server-os |access-date=2022-05-28 |website=docs.microsoft.com |date=27 April 2021 |language=en-us}}</ref> A key study published in WWW2008 Conference (Beijing, China)<ref>{{Cite web |title=WWW2008 – WWW 2008: 17th International World Wide Web Conference (Welcome) |url=https://archive.thewebconf.org/www2008/ |access-date=2022-05-28 |language=en-US |archive-date=2022-10-04 |archive-url=https://web.archive.org/web/20221004153056/https://archive.thewebconf.org/www2008/ |url-status=dead }}</ref> presented the state of SOAP-based web services and concluded that only 63% of the available SOAP-based web services at the time of the study were actually active or can be invoked. The study also found that search engines were becoming an ideal source for searching for web services compared to that of service registries like the UDDI due its design complexity.<ref>{{Cite book |last1=Al-Masri |first1=Eyhab |last2=Mahmoud |first2=Qusay H. |title=Proceedings of the 17th international conference on World Wide Web |chapter=Investigating web services on the world wide web |date=2008-04-21 |chapter-url=https://doi.org/10.1145/1367497.1367605 |series=WWW '08 |___location=New York, NY, USA |publisher=Association for Computing Machinery |pages=795–804 |doi=10.1145/1367497.1367605 |isbn=978-1-60558-085-2|s2cid=12570844 }}</ref>
 
==See also==
* [[List of web service frameworks]]
* [[List of web service protocols]]
* [[List of web service specifications]]
* [[Middleware]]
* [[Service-oriented architecture]] (SOA)
* [[Web Map Service]]
* [[Web API]]
 
==Notes==
{{Notelist}}
<references />
 
==References==
[[Category:Web services]]
{{Reflist|30em}}
[[Category:Service engineering]]
 
==External links==
[[ca:Serveis web]]
{{Commons category|Web services}}
[[cs:Webová služba]]
{{Wikiversity}}
[[da:Web service]]
* [http://soapatterns.org/candidate_patterns/messaging_design_pattern Messaging Design Pattern] {{Webarchive|url=https://web.archive.org/web/20181009132036/http://soapatterns.org/candidate_patterns/messaging_design_pattern |date=2018-10-09 }} documentation at [http://www.soapatterns.org/ SOA Patterns]
[[de:Web Service]]
* The [https://www.w3.org/2002/ws/ Web Services Activity] page at [[W3C]]
[[es:Servicio Web]]
* [https://www.w3.org/TR/ws-arch/ Web Services Architecture], the W3C Working Group Note (11 February 2004)
[[fa:خدمات وب]]
* [http://www2008.org/papers/pdf/p795-almasriA.pdf Investigating Web Services on the World Wide Web], the analysis presented at the [[International World Wide Web Conference|WWW2008]] conference
[[fr:Service Web]]
* [https://csrc.nist.gov/publications/detail/sp/800-95/final Guide to Secure Web Services] (SP 800-95) at [[National Institute of Standards and Technology|NIST]]
[[ko:웹 서비스]]
 
[[id:Web service]]
{{Web interfaces}}
[[it:Web service]]
{{Authority control}}
[[he:Web service]]
 
[[hu:Webszolgáltatás]]
{{DEFAULTSORT:Web Service}}
[[nl:Webservice]]
[[jaCategory:Webサービス services]]
[[pl:Web service]]
[[pt:Web service]]
[[ru:Веб-служба]]
[[sv:Webbtjänst]]
[[th:เว็บเซอร์วิส]]
[[vi:Dịch vụ web]]
[[uk:Веб-служба]]
[[zh:Web服务]]