User:Mahesh.kurelly
''''Web service''''
A Web Service is a software interface that describes a collection of operations that can be accessed over the network through standardized XML messaging. It uses protocols based on the XML language to describe an operation to execute or data to exchange with another Web service.
A Web Service is a standards-based, language-agnostic software entity, which accepts specially formatted requests from other software entities on remote machines via vendor and transport neutral communication protocols, producing application specific responses.
Web service is a technology that allows applications to communicate with each other in a platform- and programming language-independent manner.
A Web service is a method of communication between two electronic devices over the World Wide Web.
A Web service is a software function provided at a network address over the web or the cloud, it is a service that is "always on" as in the concept of utility computing.
Web Services are software applications that can be discovered, described, and accessed based on XML and standard Web protocols over intranets, extranets, and the Internet.
"Web services are a new breed of Web application. They are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web. Web services perform functions, which can be anything from simple requests to complicated business processes. Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service.”
Benefits of Web Services
Loosely Coupled: Each service exists independently of the other services that make up the application. Individual pieces of the application to be modified without impacting unrelated areas. Ease of Integration: Data is isolated between applications creating ’silos’. Web Services act as glue between these and enable easier communications within and across organizations. Service Reuse: Takes code reuse a step further. A specific function within the domain is only ever coded once and used over and over again by consuming applications.
Web Services Architectures The simplest Web Service System: The simplest Web service system has two participants: A service producer (provider). A service consumer (requester).
The provider presents the interface and implementation of the service, and the requester uses the Web service.
A Service Oriented Architecture (SOA):
A more sophisticated system:
A registry, acts as a broker for Web services.
A provider, can publish services to the registry.
A consumer, can then discover services in the registry.
Working of Web Services The W3C (The World Wide Web Consortium (W3C) is the main international standards organization for the World Wide Web) 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-process able 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.
Three major operations surround web services are, Publishing – making a web service available Finding – locating web services Binding – using web services In order for someone to use your service they have to know about it. To allow users to discover a service it is published to a registry (UDDI). To allow users to interact with a service you must publish a description of its interface (methods & arguments). This is done using WSDL. Once you have published a description of your service you must have a host set up to serve it. A web server is often used to deliver services (although custom application – application communication is also possible). This is functionality which has to be added to the web server. In the case of the web server a ‘container’ application can be used to make the application available to deploying. There are two major categories of web services 1. SOAP Web Service 2. REST Web Service Soap Web Service Simple Object Access Protocol (SOAP) is a standard protocol specification for message exchange based on XML. Communication between the web service and client happens using XML messages. SOAP defines the rules for communication like what are all the tags that should be used in XML and their meaning. REST Web Service REST web service uses architectures that use HTTP or similar protocols by restricting the interface to use standard operations like GET, POST, PUT, DELETE for HTTP. Based on my experience REST is easier to develop.
'Simple Object Access Protocol (SOAP)' SOAP, originally defined as Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of Web Services in computer networks. It relies on Extensible Markup Language (XML) for its message format, and usually relies on other Application Layer protocols, most notably Hypertext Transfer Protocol(HTTP) and Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission. SOAP is an XML-based protocol to exchange messages between a requester and a provider of a Web Service. The provider publishes the WSDL to UDDI and the requester can join to it using SOAP. History: SOAP was designed as an object-access protocol in 1998 by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein for Microsoft, where Atkinson and Al-Ghosein were working at the time. The SOAP specification is currently maintained by the XML Protocol Working Group of the World Wide Web Consortium. After SOAP was first introduced, it became the underlying layer of a more complex set of Web Services, based on Web Services Description Language (WSDL) and Universal Description Discovery and Integration (UDDI). These services, especially UDDI, have proved to be of far less interest, but an appreciation of them gives a more complete understanding of the expected role of SOAP compared to how web services have actually evolved.
Characteristics: SOAP has three major characteristics: Extensibility - security and WS-routing are among the extensions under development. Neutrality - SOAP can be used over any transport protocol such as HTTP, SMTP, TCP, or JMS. Independence - SOAP allows for any programming model. SOAP is used to communicate with the Web Service. Both the request and the response are SOAP messages. The body of the message (whose grammar is defined by the WSDL) is contained within a SOAP “envelope”. “Binds” the client to the web service. Specification: The SOAP specification defines the messaging framework which consists of: • The SOAP processing model defining the rules for processing a SOAP message • The SOAP extensibility model defining the concepts of SOAP features and SOAP modules • The SOAP underlying protocol binding framework describing the rules for defining a binding to an underlying protocol that can be used for exchanging SOAP messages between SOAP nodes • The SOAP message construct defining the structure of a SOAP message
SOAP messages:
SOAP provides a standard ‘envelope’ within which a message can be delivered. SOAP is mechanism (protocol) for transferring information (messages) between applications which may be widely distributed. SOAP says nothing about the content of the message – the sender and the receiver must understand the message for themselves. SOAP is part of a communication stack.
SOAP Structure: Each SOAP message will have:
An Envelope A Header (optional) A Body The Body may contain a Fault element
'Description:'
The SOAP architecture consists of several layers of specifications for: message format, Message Exchange Patterns (MEP), underlying transport protocol bindings, message processing models, and protocol extensibility. SOAP is the successor of XML-RPC, though it borrows its transport and interaction neutrality and the envelope/header/body from elsewhere.
SOAP Envelope
The envelope wraps the entire soap document.
SOAP Header
The header contains allows additional information to be passed as well as the body of the document – e.g. authentication.
SOAP Body
The body element contains the core of the SOAP document – this will contain either the RPC call or the XML message itself. The fault information will contain any exception information.
SOAP RPC
SOAP RPC messages contain XML that represents a method call or method response. The SOAP XML will be converted into a method call on the server and the response will be encoded into SOAP XML to be returned to the client.
SOAP Faults
SOAP errors are handled using a specialised envelope known as a Fault Envelope. A SOAP Fault is a special element which must appear as an immediate child of the body element. Fault code and fault strings are required.
SOAP Attachment
Large quantities or binary data may not fit well into a XML SOAP message. In which case it can be sent ‘out of band’ by attaching it to a SOAP message. Analogy: email attachments.
'Processing model:' The SOAP processing model describes a distributed processing model, its participants, the SOAP nodes, and how a SOAP receiver processes a SOAP message. The following SOAP nodes are defined: • SOAP sender: A SOAP node that transmits a SOAP message. • SOAP receiver: A SOAP node that accepts a SOAP message. • SOAP message path: The set of SOAP nodes through which a single SOAP message passes. • Initial SOAP sender (Originator): The SOAP sender that originates a SOAP message at the starting point of a SOAP message path. • SOAP intermediary: A SOAP intermediary is both a SOAP receiver and a SOAP sender and is targetable from within a SOAP message. It processes the SOAP header blocks targeted at it and acts to forward a SOAP message towards an ultimate SOAP receiver. • Ultimate SOAP receiver: The SOAP receiver that is a final destination of a SOAP message. It is responsible for processing the contents of the SOAP body and any SOAP header blocks targeted at it. In some circumstances, a SOAP message might not reach an ultimate SOAP receiver, for example because of a problem at a SOAP intermediary. An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message. Advantages: • SOAP is versatile enough to allow for the use of different transport protocols. The standard stacks use HTTP as a transport protocol, but other protocols such as JMS and SMTP are also usable. • Since the SOAP model tunnels fine in the HTTP get/response model, it can tunnel easily over existing firewalls and proxies, without modifications to the SOAP protocol, and can use the existing infrastructure. Disadvantages: • Because of the verbose XML format, SOAP can be considerably slower than competing middleware technologies such as CORBA or ICE. This may not be an issue when only small messages are sent. To improve performance for the special case of XML with embedded binary objects, the Message Transmission Optimization Mechanism was introduced. • When relying on HTTP as a transport protocol and not using WS-Addressing or an ESB, the roles of the interacting parties are fixed. Only one party (the client) can use the services of the other. Developers must use polling instead of notification in these common cases.
'WSDL (web services description language)
Describes the Web Service and defines the functions that are exposed in the Web Service Defines the XML grammar to be used in the messages Uses the W3C Schema language The Web Services Description Language is an XML-based language that is used for describing the functionality offered by a Web service. A WSDL description of a web service (also referred to as a WSDL file) provides a machine-readable description of how the service can be called, what parameters it expects, and what data structures it returns. It thus serves a roughly similar purpose as a method signature in a programming language. The current version of WSDL is WSDL 2.0. The meaning of the acronym has changed from version 1.1 where the D stood for Definition.
Description: The WSDL describes services as collections of network endpoints, or ports. The WSDL specification provides an XML format for documents for this purpose. The abstract definitions of ports and messages are separated from their concrete use or instance, allowing the reuse of these definitions. A port is defined by associating a network address with a reusable binding, and a collection of ports defines a service. Messages are abstract descriptions of the data being exchanged, and port types are abstract collections of supported operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding, where the operations and messages are then bound to a concrete network protocol and message format. In this way, WSDL describes the public interface to the Web service. WSDL is often used in combination with SOAP and an XML Schema to provide Web services over the Internet. A client program connecting to a Web service can read the WSDL file to determine what operations are available on the server. Any special data types used are embedded in the WSDL file in the form of XML Schema. The client can then use SOAP to actually call one of the operations listed in the WSDL file using XML or HTTP.
'Universal Description Discovery and Integration(UDDI)' Universal Description, Discovery and Integration (UDDI, pronounced Yu-diː) is a platform-independent, Extensible Markup Language (XML)-based registry by which businesses worldwide can list themselves on the Internet, and a mechanism to register and locate web service applications. UDDI is an open industry initiative, sponsored by the Organization for the Advancement of Structured Information Standards (OASIS), for enabling businesses to publish service listings and discover each other, and to define how the services or software applications interact over the Internet. UDDI was originally proposed as a core Web service standard. It is designed to be interrogated by SOAP messages and to provide access to Web Services Description Language (WSDL) documents describing the protocol bindings and message formats required to interact with the web services listed in its directory. Structure: A UDDI business registration consists of three components: • White Pages — address, contact, and known identifiers; • Yellow Pages — industrial categorizations based on standard taxonomies; • Green Pages — technical information about services exposed by the business. White Pages White pages give information about the business supplying the service. This includes the name of the business and a description of the business - potentially in multiple languages. Using this information, it is possible to find a service about which some information is already known (for example, locating a service based on the provider's name). Contact information for the business is also provided - for example the businesses address and phone number; and other information such as the Dun & Bradstreet Universal Numbering System number. Yellow Pages Yellow pages provide a classification of the service or business, based on standard taxonomies. These include the Standard Industrial Classification (SIC), the North American Industry Classification System (NAICS), or the United Nations Standard Products and Services Code (UNSPSC). NAICS - pronounced "nakes" is used by business and government to classify business establishments according to type of economic activity (process of production) in Canada, Mexico and the United States. UNSPSC - was jointly developed by the United Nations Development Programme (UNDP) and Dun & Bradstreet Corporation in 1998 and is currently managed by GS1 US, which is responsible for overseeing code change requests, revising the codes and issuing regularly scheduled updates to the code, as well as managing special projects and initiatives. Because a single business may provide a number of services, there may be several Yellow Pages (each describing a service) associated with one White Page (giving general information about the business). Green Pages Green pages are used to describe how to access a Web Service, with information on the service bindings. Some of the information is related to the Web Service - such as the address of the service and the parameters, and references to specifications of interfaces. Other information is not related directly to the Web Service - this includes e-mail, FTP, CORBA and telephone details for the service. Because a Web Service may have multiple bindings (as defined in its WSDL description), a service may have multiple Green Pages, as each binding will need to be accessed differently. UDDI Nodes & Registry UDDI nodes are servers which support the UDDI specification and belong to a UDDI registry while UDDI registries are collections of one or more nodes..
'XML (Extensible Mark-up Language)'
What is XML
XML stands for extensible mark-up language It is a hierarchical data description language It is a sub set of SGML a general document mark-up language designed for the American military. It is defined by w3c.
How does XML differ from HTML?
HTML is a presentation mark-up language – provides no information about content. There is only one standard definition of all of the tags used in HTML. XML can define both presentation style and give information about content. XML relies on custom documents defining the meaning of tags.
What is a Schema?
A schema is the definition of the meaning of each of the tags within a XML document. Analogy: A HTML style sheet can be seen as a limited schema which only specifies the presentational style of HTML which refers to it. Example: in HTML the tag pre-defined. In XML you would need to define this in the context of your document.