Wikiversity has learning materials about Web service

Web services architecture.

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."^[1]

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."^[2]

Big Web services[link]

"Big Web services" use Extensible Markup Language (XML) messages that follow the SOAP standard and have been popular with the traditional enterprises. 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 Apache Axis2, Apache CXF, and Spring being notable exceptions). Some industry organizations, such as the WS-I, mandate both SOAP and WSDL in their definition of a Web service.

Web API[link]

Web services in a service-oriented architecture.

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.^[3] REST services do not require XML, SOAP, or WSDL service-API definitions.

Web APIs allow the combination of multiple Web services into new applications known as mashups.^[4]

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, although this can still be handled by responding with an error object to the clients.

Interaction Models[link]

Web services are a set of tools that can be used in a number of ways. The three most common interaction models are RPC, SOA and REST.^[5]

Remote procedure calls[link]

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.

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), Open Software Foundation's (OSF) DCE/RPC, Microsoft's RPC (a part of DCOM) or .NET Remoting and Sun Microsystems's Java/Remote Method Invocation (RMI).

Service-oriented architecture[link]

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 (ESBs) that combine message-oriented processing and Web services to create an event-driven SOA. Examples of open-source ESB are Mule and Open ESB. An alternate approach is the Hub-and-Spoke model, which is server based. An example of this is Enterprise Message Service (EMS, an implementation of JMS).

Representation of concepts defined by WSDL 1.1 and WSDL 2.0 documents.

Representational state transfer (REST)[link]

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). Here, the focus is on interacting with stateless resources, rather than messages or operations. Clean URLs are tightly associated with the REST concept.

An architecture based on REST 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.^[6] However, support for this specification is still poor in software development kits, which often offer tools only for WSDL 1.1.

Automated design methodologies[link]

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 strategy) or to generate a class skeleton given existing WSDL (a top-down strategy).

• A developer using a bottom up method 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.^[7] This is often the simpler approach.
• A developer using a top down method writes the WSDL document first and then uses a code generating tool to produce the class skeleton, to be completed as necessary. This way is generally considered more difficult but can produce cleaner designs ^[8]

Criticisms[link]

Critics of non-REST Web services often complain that they are too complex^[9] and based upon large software vendors or integrators, rather than typical open source implementations. There are open source implementations like Apache Axis and Apache CXF.

One key concern of the REST Web service developers is that the SOAP WS toolkits make it easy to define new interfaces for remote interaction, often relying on introspection to extract the WSDL, since a minor change on the server (even an upgrade of the SOAP stack) can result in different WSDL and a different service interface.^[10] The client-side classes that can be generated from WSDL and XSD descriptions of the service are often similarly tied to a particular version of the SOAP endpoint and can break, if the endpoint changes or the client-side SOAP stack is upgraded. Well-designed SOAP endpoints (with handwritten XSD and WSDL) do not suffer from this, but a custom interface for every service still requires a custom client for every service.

There are also concerns about performance due to Web services' use of XML as a message format and SOAP/HTTP in enveloping and transporting.^[11]

See also[link]

References[link]

External links[link]

• Messaging Design Pattern and a distributed component/service model
• W3C Web Services Activity home page
• Web Services Architecture (W3C Working Group Note)
• Where to find Web Services on the Web: Investigating Web Services on the World Wide Web (2008)

This biographical article needs additional citations for verification. Please help by adding reliable sources. Contentious material about living persons that is unsourced or poorly sourced must be removed immediately, especially if potentially libelous or harmful. (November 2010)

Steve Huffman (born November 12, 1983) is a web developer and co-founder of Reddit.^[1] More recently, he has co-founded the airfare search site Hipmunk.^[2] He graduated from the University of Virginia in 2005 with Alexis Ohanian to start Reddit in Medford, MA after taking funding from Y Combinator.

Steve was named to Inc. Magazine's 30 under 30 list in 2011.^[3] He studied Computer Science at the University of Virginia.

Steve is the course instructor of "CS253 Web Application Engineering" for April 2012 hexamester at Udacity.^[4]

References[link]

This biographical article relating to a computer specialist is a stub. You can help Wikipedia by expanding it. v t e