Web Services
From Computing and Software Wiki
(New page: A '''Web service'''[http://en.wikipedia.org/wiki/Web_service 1] is defined by the W3C [http://www.w3.org W3C] as "a software system designed to support interoperable Machine to Machine in...)
Newer edit →
Revision as of 03:32, 15 April 2008
A Web service1 is defined by the W3C W3C as "a software system designed to support interoperable Machine to Machine interaction over a network." Web services are frequently just Web APIs that can be accessed over a network, such as the Internet, and executed on a remote system hosting the requested services.
The term Web services 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 used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available. Used primarily as a means for businesses to communicate with each other and with clients, Web services allow organizations to communicate data without intimate knowledge of each other's IT systems behind the firewall.
Unlike traditional client/server models, such as a Web server/Web page system, Web services do not provide the user with a GUI. Web services instead share business logic, data and processes through a programmatic interface across a network. The applications interface, not the users. Developers can then add the Web service to a GUI (such as a Web page or an executable program) to offer specific functionality to users. 6
Web services allow different applications from different sources to communicate with each other without time-consuming custom coding, and because all communication is in XML, Web services are not tied to any one operating system or programming language. For example, Java can talk with Perl, Windows applications can talk with UNIX applications.
Web services do not require the use of browsers or HTML.
Web services are sometimes called application services.
Contents |
Introduction
Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. This document (WSA) is intended to provide a common definition of a Web service, and define its place within a larger Web services framework to guide the community. The WSA provides a conceptual model and a context for understanding Web services and the relationships between the components of this model.
The architecture does not attempt to specify how Web services are implemented, and imposes no restriction on how Web services might be combined. The WSA describes both the minimal characteristics that are common to all Web services, and a number of characteristics that are needed by many, but not all, Web services.
The Web services architecture is an interoperability architecture: it identifies those global elements of the global Web services network that are required in order to ensure interoperability between Web services.
The principles behind web services are stunningly simple, and are nothing new in the world of distributed computing and the Internet:
- the web service provider defines a format for requests for its service and the response the service will generate
- a computer makes a request for the web services across the network
- the web service performs some action, and sends the response back
This action might be retrieving a stock quote, finding the best price for a particular product on the net, saving a new meeting to a calendar, translating a passage of text to another language, or validating a credit card number.
Specifications
To improve interoperability of Web Services, the WS-I publishes profiles. A profile is a set of core specifications (SOAP 3, WSDL, ...) in a specific version (SOAP 1.1, UDDI 2, ...) with some additional requirements to restrict the use of the core specifications. The WS-I also publishes use cases and test tools to help deploying profile compliant Web Service.
Additional specifications, WS
Some specifications have been developed or are currently being developed to extend Web Services capabilities. These specifications are generally referred to as WS-*. Here is a non-exhaustive list of these WS-* specifications.
WS-Security Defines how to use XML Encryption and XML Signature in SOAP to secure message exchanges, as an alternative or extension to using HTTPS to secure the channel. WS-Reliability An OASIS standard protocol for reliable messaging between two Web services. WS-ReliableMessagingA protocol for reliable messaging between two Web services, issued by Microsoft, BEA and IBM it is currently being standardized by the OASIS organization. WS-AddressingA way of describing the address of the recipient (and sender) of a message, inside the SOAP message itself. WS-TransactionA way of handling transactions.
Some of these additional specifications have come from the W3C. There is much discussion around the organization's participation, as the general Web and the Semantic Web story appear to be at odds with much of the Web Services vision. This has surfaced most recently in February 2007, at the Web of Services for the Enterprise workshop. Some of the participants advocated a withdrawal of the W3C from further WS-* related work, and a focus on the core Web.
In contrast, OASIS has standardized many Web service extensions, including Web Services Resource Framework and WSDM.
How does it work
when would I use a web service?
Let’s imagine I’m a developer and I have been asked to provide a new feature on my company’s website: I have to include a postal code validation facility to check that postal codes are correct as customers submit a registration form.
The validation will have to check postal codes for all 30 countries where we do business, and it should also check if the city entry corresponds to the postal code. I don’t have this data, and I suspect it will cost me some serious money to get it.
Rather than buy the data, write the code myself, maintain the data and tune performance of my code, I am going to investigate the UDDI and see if anyone provides a web service that does this sort of work. Navigating to www.uddi.org, I perform a search and find the perfect service from XYZ Corp.
I prudently examine the web service definition (written in the Web Services Description Language, an XML syntax for defining web services) so I am certain the web service does what I need. I then check with my industry buddies that XYZ Corp is solid, and get in touch with XYZ to talk dollars. After finding the pricing within my budget, I write some hasty code that calls the XYZ service from my JSP page, and voila, instant postal code validation. 5
Run Time messaging
The design work of web services is divided between the run time protocols and the descriptions of services.
The W3C work at runtime based on HTTP transport of XML-encoded messages, using the SOAP protocol. (Here by SOAP we mean SOAP 1.2, previous versions including early proprietory submissions which are not standards or guaranteed to interoperate) . There is a bifurcation in the design at this point, as SOAP operates basically in two modes.
In one, the XML message is used to encode the parameters to a remote operation in much the same way as remote method invokation in for example, Corba, DCOM, or RMI. In this mode, XML is used as the marshalling style, but the system is a distributed using remote procedure call in a fairly traditional way.
- There is a standard marshalling syntax
Interfaces between software modules have well-defined functions, which in turn have well-defined and typed input and output parameters
Stubs (dummy routines which similate the remote procedure by a local one which communcates with the remote one) can be generated directly from the WSDl definition
- The remoteness can be transparent, making the design of a distributed system similar to the design of a program.
In the other mode, SOAP carries an XML document, and the task of the receiver is seen more as a document processing operation. This is less rigid than the RPC style.
- The interface a service provides is defined just by the XML schema. This defines the acceptable document types, which can allwo extension in many ways, using XML namespaces.
The communication is more apparent to the application writer, who deals with the document object model (DOM) of the recived message, rather than having parameters unmkarshalled automatically.
XML tools such as XSLT and XML-Query, and XML encryption and so on can be used.
It is simpler to use message exchange patterns other than the request/response.
The document mode of SOAP seems to be getting the most traction in the ecommerce stack. This is not an accident. The XML mode is more flexible than the RPC mode. It is easier in principle to extend an XML-based message system to include more information as a system grows. In fact, RDF is especially powerful in this area, as new information can be parsed into an entity-relationship form by old agents, and it becomes logically clear which parts can be ignored by those who do not understand them.
Functionality which has been mentioned as required above the basic layer at runtime includes:
- Routing. Routine data within message for processing bu different agents; defining workflow path of message. Black box or white box patterns of design.
- Security. Prolfiling existing security technologies for use in ebusiness applications using web sevices. Authentication and key management.
- Packaging of attachments to messages. XML Packaging.
- Reliable messaging (delivery, non-duplication, ordering) for the case in which the transport layer (such as TCP under the HTTP) doesnot provide this. (TCP does provide this reliability but (a) systems are not designed to keep TCP connections open for the weeks or years over which a web service may run, and (b) TCP does not provide accountability so you can show the tax man the acknowledgement of receipt 7 years later.)
Description
The descriptions of services are made at various different models and different levels of abstraction in different specs proposed as part of the stack, though there is agreement on WSDL as the modelling of the lowest level, the message or request/response interaction, and the binding to the specific HTTP (say) port at which it happens.
Lots of concepts interconnected
Higher layers in the description above WSDL are known variously as coordination, orchestration, choreography, composition.
They involve (compared with basic WSDL), for example:
- Protocols involving more than two messages
- Protocols having a common shared state over a long period
- Protocols having more than two parties involved;
- The protocols as business protocols, in terms of common business functions
- The relationship between allowed transitions in the protocol and the content of messages. For example, the requirement for a transaction ID to match across a transaction, or for possible responses to be a function of a request code.
Overview of Engaging a Web Service
There are many ways that a requester entity might engage and use a Web service. In general, the following broad steps are required, as illustrated in Figure 1-1: (1) the requester and provider entities become known to each other (or at least one becomes know to the other); (2) the requester and provider entities somehow agree on the service description and semantics that will govern the interaction between the requester and provider agents; (3) the service description and semantics are realized by the requester and provider agents; and (4) the requester and provider agents exchange messages, thus performing some task on behalf of the requester and provider entities. (I.e., the exchange of messages with the provider agent represents the concrete manifestation of interacting with the provider entity's Web service.) These steps are explained in more detail in 3.4 Web Service Discovery. Some of these steps may be automated, others may be performed manually.
Technologies within the Web Servcies
There is a mass of different pieces being bolted onto the foundations of Web Services provided by WSDL and SOAP 1.2 and th diagram implies things considerably. The management layer is a supervisory layer allowing the conrol of the many agents involved in a web services-based operation. The "Application semantics" layer indicates the necessity, for any useful interoperability, to have
The Architetural Model
This architecture has four models, illustrated on the figure below. Each model is labeled with what may be viewed as the key concept of that model. 4
Message Oriented Model
It focuses on messages, message structure, message transport and so on without particular reference as to the reason for the messages nor their significance.
The essence of the message model revolves around a few key concepts illustrated above as 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 as 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.
Service Oriented Model
It 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.
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.
Resource Oriented Model
It focuses on resources that exist and have owners.
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
It 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.
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.
See Also
References
- Web Services. Retrieved on March 9th, from <http://en.wikipedia.org/wiki/Web_service>
- W3C. Retrieved on March 10th 2008, from <http://www.w3.org>
- SOAP. Retrieved on March 11th 2008, from <http://pt.wikipedia.org/wiki/SOAP>
- Architeture Web Service.Retrieved on March 11th 2008, from <http://www.w3.org/TR/ws-arch>
- Web Services.Retrieved on March 11th 2008,from <http://www.alistapart.com/articles/webservices>
- Definition of Web Service.Retrieved on March 11th 2008, from <http://www.webopedia.com/TERM/W/Web_services.html>
External Links
W3C Web Services Activity home page
Secure, Reliable, Transacted Web Services
--Gallb 23:32, 14 April 2008 (EDT)
