A Web service (also Web Service) is defined by the W3C as “a software system designed to support interoperable machine-to-machine interaction over a network”. [1] Web services are frequently just Internet 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. Other approaches with nearly the same functionality as web services are Object Management Group’s (OMG) Common Object Request Broker Architecture (CORBA), Microsoft’s Distributed Component Object Model (DCOM) or SUN’s Java/Remote Method Invocation (RMI).

The W3C Web service definition encompasses many different systems, but in common usage the term refers to clients and servers that communicate over the HTTP protocol used on the Web. Such services tend to fall into one of two camps: Big Web Services 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 Architecture

Abstract

This document defines the Web Services Architecture. It identifies the functional components and defines the relationships among those components to effect the desired properties of the overall architecture.

The Architectural Models

This architecture has four models, illustrated in Figure 1. Each model in Figure 2 is labeled with what may be viewed as the key concept of that model.

The four models are:

• The Message Oriented Model focuses on messages, message structure, message transport and so on — without particular reference as to the reasons for the messages, nor to their significance.
  Figure 2-3. Simplified Message Oriented Model

  

  The essence of the message model revolves around a few key concepts illustrated above: the agent that sends and receives messages, the structure of the message in terms of message headers and bodies and the mechanisms used to deliver messages. Of course, there are additional details to consider: the role of policies and how they govern the message level model. The abridged diagram shows the key concepts; the detailed diagram expands on this to include many more concepts and relationships.

• The Service Oriented Model focuses on aspects of service, action and so on. While clearly, in any distributed system, services cannot be adequately realized without some means of messaging, the converse is not the case: messages do not need to relate to services.
  Figure 2-4. Simplified Service Oriented Model

  

  The Service Oriented Model is the most complex of all the models in the architecture. However, it too revolves around a few key ideas. A service is realized by an agent and used by another agent. Services are mediated by means of the messages exchanged between requester agents and provider agents.

  A very important aspect of services is their relationship to the real world: services are mostly deployed to offer functionality in the real world. We model this by elaborating on the concept of a service’s owner — which, whether it is a person or an organization, has a real world responsibility for the service.

  Finally, the Service Oriented Model makes use of meta-data, which, as described in 3.1 Service Oriented Architecture, is a key property of Service Oriented Architectures. This meta-data is used to document many aspects of services: from the details of the interface and transport binding to the semantics of the service and what policy restrictions there may be on the service. Providing rich descriptions is key to successful deployment and use of services across the Internet.

• The Resource Oriented Model focuses on resources that exist and have owners.
  Figure 2-5. Simplified Resource Oriented Model

  

  The resource model is adopted from the Web Architecture concept of resource. We expand on this to incorporate the relationships between resources and owners.

• The Policy Model focuses on constraints on the behavior of agents and services. We generalize this to resources since policies can apply equally to documents (such as descriptions of services) as well as active computational resources.
  Figure 2-6. Simplified Policy Model

  

  Policies are about resources. They are applied to agents that may attempt to access those resources, and are put in place, or established, by people who have responsibility for the resource.

  Policies may be enacted to represent security concerns, quality of service concerns, management concerns and application concerns.

You can read complete article here:- http://www.w3.org/TR/ws-arch/