WEBSERVICES
1. INTRODUCTION
Web Services are self-contained modular applications that can be
- Described
- Published
- Located &
- Invoked
A Web Service is a standard platform for building interoperable distributed applications. It allows you as a developer, to interact with other information providers without worrying about what they are running either at the backend or even their front end.
Web Services enable computer systems on any platform to communicate over corporate intranets, extranets, and across the Internet with support for end-to-end security, reliable messaging, distributed transactions, and more.
Web Services are based on a core set of standards that describe the syntax and semantics of software communication: XML provides the common syntax for representing data; the Simple Object Access Protocol (SOAP) provides the semantics for data exchange; and the Web Services Description Language (WSDL) provides a mechanism to describe the capabilities of a Web service. Additional specifications, collectively referred to as the WS-* architecture, define functionality for Web Services discovery, eventing, attachments, security, reliable messaging, transactions, and management.
What are Web Services?
Web Services are application components
Web Services communicate using open protocols
Web Services are self-contained and self-describing
Web Services can be discovered using UDDI
Web Services can be used by other applications
XML is the basis for Web Services
The basic Web Services platform is XML + HTTP.
The HTTP protocol is the most used Internet protocol.
XML provides a language which can be used between different platforms and programming languages and still express complex messages and functions.
Web Services platform elements
SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery and Integration)
WSDL (Web Services Description Language)
Why Web Services?
Using Web Services your application can publish its function or message to the rest of the world. Web Services use XML to code and decode your data and SOAP to transport it using open protocols. With Web Services your accounting departments Win 2k servers billing system can connect with your IT suppliers UNIX server.
Web Services can offer application components like currency conversion, weather reports or even language translation as services. Ideally, there will only be one type of each application component, and anyone can use it in their application.
Connect existing software
Web Services help solve the interoperability problem by giving different applications a way to link their data. Using Web Services you can exchange data between different applications and different platforms.
- Web Services Platform Elements
- Web Services have three basic platform elements.
These are called SOAP, WSDL and UDDI.
2. SOAP (SIMPLE OBJECT ACCESS PROTOCOL)
Introduction to SOAP
Why SOAP?
It is important for application development to allow Internet communication between programs. Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic.
A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers. SOAP was created to accomplish this. SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.
What is SOAP?
- SOAP stands for Simple Object Access Protocol
- SOAP is a communication protocol
- SOAP is for communication between applications
- SOAP is a format for sending messages
- SOAP is designed to communicate via Internet
- SOAP is platform independent
- SOAP is language independent
- SOAP is based on XML
- SOAP is simple and extensible
- SOAP allows you to get around firewalls
- SOAP will be developed as a W3C standard
- SOAP Building Blocks
A SOAP message is an ordinary XML document containing the following elements:
- A required Envelope element that identifies the XML document as a SOAP message
- An optional Header element that contains header information
- A required Body element that contains call and response information
- An optional Fault element that provides information about errors that occurred while processing the message
SOAP is a standard that specifies the format of messages used in Web services. SOAP messages are messages formatted in XML - the SOAP standard specifies what XML elements must be present, in what order, and what data types they can contain.
SOAP Syntax
Syntax Rules
Here are some important syntax rules:
- A SOAP message MUST be encoded using XML
- A SOAP message MUST use the SOAP Envelope namespace
- A SOAP message MUST use the SOAP Encoding namespace
- A SOAP message must NOT contain a DTD reference
- A SOAP message must NOT contain XML Processing Instructions.
- A SOAP message is comprised of the following parts:
- A SOAP Envelope,
An optional SOAP Header, and The SOAP Body and (optional) Header are contained within the SOAP Envelope, as shown in the diagram to the left. As aforementioned, a SOAP Header is an optional piece of a SOAP message, and for simple Web Services is rarely used. We'll save a discussion on SOAP Headers for a later article. For now, let's focus on the SOAP Envelope and SOAP Body.
The SOAP Envelope merely consists of the XML root element, which specifies the namespaces used in the SOAP message. The root element of a SOAP message is .
Realize that in a Web service interaction there is a total of two messages: first, the client sends a SOAP message to the server, invoking some method. After this method has executed, the server returns a response, which includes the return value of the method. For the first message, sometimes referred to as the SOAP request message, the SOAP Body contains the name of the method the client wishes to call, along with the method's input parameters. In the second message, the SOAP response message, the server sends back in the body the return value of the method. (Even if there is no return value, a message is still sent back if, nothing else, to verify that the method executed.) The SOAP Body is signified by the element.
SOAP Envelop
The mandatory SOAP Envelope element is the root element of a SOAP message.
The SOAP Envelope Element
The required SOAP Envelope element is the root element of a SOAP message. It defines the XML document as a SOAP message.The SOAP-ENV: Envelope element has two sub-elements,
SOAP-ENV:Header and SOAP-ENV:Body.
Note the use of the xmlns:soap namespace. It should always have the value of:
http://www.w3.org/2001/12/soap-envelope and it defines the Envelope as a SOAP Envelope:
Note the use of the xmlns:soap namespace. It should always have the value of:
http://www.w3.org/2001/12/soap-envelope and it defines the Envelope as a SOAP Envelope:
The xmlns:soap Namespace
A SOAP message must always have an Envelope element associated with the "http://www.w3.org/2001/12/soap-envelope" namespace.
If a different namespace is used, the application must generate an error and discard the message.
The encodingStyle Attribute
The SOAP encodingStyle attribute is used to define the data types used in the document. This attribute may appear on any SOAP element, and it will apply to that element's contents and all child elements. A SOAP message has no default encoding.
Syntax
soap:encodingStyle="URI"
Example
...Message information goes here...
SOAP Header
The optional SOAP Header element contains header information.
The optional SOAP Header element contains header information.
The SOAP Header Element
The optional SOAP Header element contains application specific information (like authentication, payment, etc) about the SOAP message. If the Header element is present, it must be the first child element of the Envelope element.
The optional SOAP Header element contains application specific information (like authentication, payment, etc) about the SOAP message. If the Header element is present, it must be the first child element of the Envelope element.
Note: All immediate child elements of the Header element must be namespace-qualified. 234......
The example above contains a header with a "Trans" element, a "mustUnderstand" attribute value of "1", and a value of 234.
SOAP defines three attributes in the default namespace ("http://www.w3.org/2001/12/soap-envelope"). These attributes are: actor, mustUnderstand, and encodingStyle. The attributes defined in the SOAP Header defines how a recipient should process the SOAP message.
The actor Attribute
A SOAP message may travel from a sender to a receiver by passing different endpoints along the message path. Not all parts of the SOAP message may be intended for the ultimate endpoint of the SOAP message but, instead, may be intended for one or more of the endpoints on the message path.
The SOAP actor attribute may be used to address the Header element to a particular endpoint.
Syntax
soap:actor="URI"
A SOAP message may travel from a sender to a receiver by passing different endpoints along the message path. Not all parts of the SOAP message may be intended for the ultimate endpoint of the SOAP message but, instead, may be intended for one or more of the endpoints on the message path.
The SOAP actor attribute may be used to address the Header element to a particular endpoint.
Syntax
soap:actor="URI"
Example 234...... The mustUnderstand Attribute
The SOAP mustUnderstand attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to process.
If you add "mustUnderstand="1" to a child element of the Header element it indicates that the receiver processing the Header must recognize the element. If the receiver does not recognize the element it must fail when processing the Header.
Syntax
soap:mustUnderstand="01"
The SOAP mustUnderstand attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to process.
If you add "mustUnderstand="1" to a child element of the Header element it indicates that the receiver processing the Header must recognize the element. If the receiver does not recognize the element it must fail when processing the Header.
Syntax
soap:mustUnderstand="01"
Example 234......
SOAP Body
The mandatory SOAP Body element contains the actual SOAP message.
The mandatory SOAP Body element contains the actual SOAP message.
The SOAP Body Element
The required SOAP Body element contains the actual SOAP message intended for the ultimate endpoint of the message. Immediate child elements of the SOAP Body element may be namespace-qualified. SOAP defines one element inside the Body element in the default namespace ("http://www.w3.org/2001/12/soap-envelope"). This is the SOAP Fault element, which is used to indicate error messages.
The required SOAP Body element contains the actual SOAP message intended for the ultimate endpoint of the message. Immediate child elements of the SOAP Body element may be namespace-qualified. SOAP defines one element inside the Body element in the default namespace ("http://www.w3.org/2001/12/soap-envelope"). This is the SOAP Fault element, which is used to indicate error messages.
Apples
The example above requests the price of apples. Note that the m:GetPrice and the Item elements above are application-specific elements. They are not a part of the SOAP standard.
A SOAP response could look something like this:
1.90
SOAP Fault
The optional SOAP Fault element is used to hold error and status information for a SOAP message.
The SOAP Fault Element
An error message from a SOAP message is carried inside a Fault element.
If a Fault element is present, it must appear as a child element of the Body element. A Fault element can only appear once in a SOAP message.
The SOAP Fault element has the following sub elements:
The example above requests the price of apples. Note that the m:GetPrice and the Item elements above are application-specific elements. They are not a part of the SOAP standard.
A SOAP response could look something like this:
1.90
SOAP Fault
The optional SOAP Fault element is used to hold error and status information for a SOAP message.
The SOAP Fault Element
An error message from a SOAP message is carried inside a Fault element.
If a Fault element is present, it must appear as a child element of the Body element. A Fault element can only appear once in a SOAP message.
The SOAP Fault element has the following sub elements:
Sub Element
Description
A code for identifying the fault
A human readable explanation of the fault
Information about who caused the fault to happen
Holds application specific error information related to the Body element
SOAP Fault Codes
The fault code values defined below must be used in the fault code element when describing faults:
- Error
- Description
- Version Mismatch
- Found an invalid namespace for the SOAP Envelope element
- Must Understand
- An immediate child element of the Header element, with the must Understand attribute set to "1", was not understood
- Client
- The message was incorrectly formed or contained incorrect information
- Server
- There was a problem with the server so the message could not proceed
SOAP HTTP Binding
The HTTP Protocol
HTTP communicates over TCP/IP. An HTTP client connects to an HTTP server using TCP. After establishing a connection, the client can send an HTTP request message to the server:
POST /item HTTP/1.1Host: 189.123.345.239Content-Type: text/plainContent-Length: 200
The server then processes the request and sends an HTTP response back to the client. The response contains a status code that indicates the status of the request:
200 OKContent-Type: text/plainContent-Length: 200
In the example above, the server returned a status code of 200. This is the standard success code for HTTP.
If the server could not decode the request, it could have returned something like this:
400 Bad RequestContent-Length: 0
400 Bad RequestContent-Length: 0
SOAP HTTP Binding
A SOAP method is an HTTP request/response that complies with the SOAP encoding rules.
HTTP + XML = SOAP
A SOAP request could be an HTTP POST or an HTTP GET request.
The HTTP POST request specifies at least two HTTP headers: Content-Type and Content-Length.
A SOAP method is an HTTP request/response that complies with the SOAP encoding rules.
HTTP + XML = SOAP
A SOAP request could be an HTTP POST or an HTTP GET request.
The HTTP POST request specifies at least two HTTP headers: Content-Type and Content-Length.
Content-Type
The Content-Type header for a SOAP request and response defines the MIME type for the message and the character encoding (optional) used for the XML body of the request or response.
Syntax
Content-Type: MIMEType; charset=character-encoding
The Content-Type header for a SOAP request and response defines the MIME type for the message and the character encoding (optional) used for the XML body of the request or response.
Syntax
Content-Type: MIMEType; charset=character-encoding
Example POST /item HTTP/1.1Content-Type: application/soap+xml; charset=utf-8
Content-Length
The Content-Length header for a SOAP request and response specifies the number of bytes in the body of the request or response.
The Content-Length header for a SOAP request and response specifies the number of bytes in the body of the request or response.
Syntax
Content-Length: bytes
Content-Length: bytes
Example
POST /item HTTP/1.1Content-Type: application/soap+xml; charset=utf-8Content-Length: 250
POST /item HTTP/1.1Content-Type: application/soap+xml; charset=utf-8Content-Length: 250
The following is a sample SOAP request message:
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
And here is a sample SOAP response message:
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
result value
The elements specific to the SOAP standard are in bold. Notice that the SOAP message begins with a element, which contains a element. Inside the element of the SOAP request message is XML that specifies the Web service method to invoke and its input parameters. Inside the element of the response SOAP message is the XML specifying the method that was called and its response, if one exists.
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
And here is a sample SOAP response message:
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
result value
The elements specific to the SOAP standard are in bold. Notice that the SOAP message begins with a element, which contains a element. Inside the element of the SOAP request message is XML that specifies the Web service method to invoke and its input parameters. Inside the element of the response SOAP message is the XML specifying the method that was called and its response, if one exists.
To help hammer home the concepts, let's imagine that a server contains a Web service method called Add, which takes two integer inputs named a and b and returns their sum (as an integer, of course). Now, imagine that a client wanted to invoke this service passing in values of 5 and 8. To do so, it would need to send the following SOAP message to the server:
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
Note that the sole child element of the element is the element. This specifies what Web service method to call. Furthermore, the element contains two children elements, and , which contain the values we want to add. (A fair question at this point is, "How do we know that we should be using XML elements named , , and ? Why not use some other names?" As we'll see in a future article, when a Web service is created, so is a WSDL document. A WSDL document provides a formal definition of the Web service, which includes information on the required names of the XML elements in the .)
The response SOAP message would look something like:
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
Recall that earlier we saw a very high-level diagram illustrating the interaction between a client and a server participating in a Web service. In this previous diagram, we simply indicated that XML data was passed between the client and server. With a more in-depth understanding of SOAP, we can now enhance that diagram to show more precisely what is passed back and forth for the Add method example:
SOAP Examples
A SOAP Example
In the example below, a GetStockPrice request is sent to a server. The request has a StockName parameter, and a Price parameter will be returned in the response. The namespace for the function is defined in "http://www.example.org/stock" address.
The response SOAP message would look something like:
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
Recall that earlier we saw a very high-level diagram illustrating the interaction between a client and a server participating in a Web service. In this previous diagram, we simply indicated that XML data was passed between the client and server. With a more in-depth understanding of SOAP, we can now enhance that diagram to show more precisely what is passed back and forth for the Add method example:
SOAP Examples
A SOAP Example
In the example below, a GetStockPrice request is sent to a server. The request has a StockName parameter, and a Price parameter will be returned in the response. The namespace for the function is defined in "http://www.example.org/stock" address.
WEB SERVICES DESCRIPTION LANGUAGE [WSDL]
Introduction
WSDL is an XML-based language for describing Web Services and how to access them.
WSDL is an XML-based language for describing Web Services and how to access them.
What is WSDL?
- WSDL stands for Web Services Description Language
- WSDL is written in XML
- WSDL is an XML document
- WSDL is used to describe Web Services
- WSDL is also used to locate Web Services
- WSDL is not yet a W3C standard
- WSDL Describes Web Services
- WSDL stands for Web Services Description Language.
- WSDL is a document written in XML. The document describes a Web service. It specifies the location of the service and the operations (or methods) the service exposes.
- WSDL Development History at W3C
- WSDL 1.1 was submitted as a W3C Note by Ariba, IBM and Microsoft for describing services for the W3C XML Activity on XML Protocols in March 2001.
WSDL Document
A WSDL document is just a simple XML document.
A WSDL document is just a simple XML document.
It contains set of definitions to describe a web service.
The WSDL Document Structure
A WSDL document describes a web service using these major elements:
Element
Defines
Defines
- The operations performed by the web service
- The messages used by the web service
- The data types used by the web service
- The communication protocols used by the web service
For a complete syntax overview go to the chapter WSDL Syntax.
WSDL Ports
The element is the most important WSDL element.
It describes a web service, the operations that can be performed, and the messages that are involved.
The element can be compared to a function library (or a module, or a class) in a traditional programming language.
WSDL Messages
The element defines the data elements of an operation.
Each message can consist of one or more parts. The parts can be compared to the parameters of a function call in a traditional programming language.
The element defines the data elements of an operation.
Each message can consist of one or more parts. The parts can be compared to the parameters of a function call in a traditional programming language.
WSDL Types
The element defines the data type that are used by the web service.
For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.
The element defines the data type that are used by the web service.
For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.
WSDL Bindings
The element defines the message format and protocol details for each port.
The element defines the message format and protocol details for each port.
WSDL Example
This is a simplified fraction of a WSDL document:
In this example the element defines "glossaryTerms" as the name of a port, and "getTerm" as the name of an operation. The "getTerm" operation has an input message called "getTermRequest" and an output message called "getTermResponse".The elements define the parts of each message and the associated data types.Compared to traditional programming, glossaryTerms is a function library, "getTerm" is a function with "getTermRequest" as the input parameter and getTermResponse as the return parameter.
WSDL Ports
A WSDL port describes the interfaces (legal operations) exposed by a web service.
In this example the element defines "glossaryTerms" as the name of a port, and "getTerm" as the name of an operation. The "getTerm" operation has an input message called "getTermRequest" and an output message called "getTermResponse".The elements define the parts of each message and the associated data types.Compared to traditional programming, glossaryTerms is a function library, "getTerm" is a function with "getTermRequest" as the input parameter and getTermResponse as the return parameter.
WSDL Ports
A WSDL port describes the interfaces (legal operations) exposed by a web service.
WSDL Ports
The element is the most important WSDL element.
It defines a web service, the operations that can be performed, and the messages that are involved.
The port defines the connection point to a web service. It can be compared to a function library (or a module, or a class) in a traditional programming language. Each operation can be compared to a function in a traditional programming language.
The element is the most important WSDL element.
It defines a web service, the operations that can be performed, and the messages that are involved.
The port defines the connection point to a web service. It can be compared to a function library (or a module, or a class) in a traditional programming language. Each operation can be compared to a function in a traditional programming language.
Operation Types
The request-response type is the most common operation type, but WSDL defines four types:
The request-response type is the most common operation type, but WSDL defines four types:
- Type
- Definition
- One-way
The operation can receive a message but will not return a response
Request-response
The operation can receive a request and will return a response
Solicit-response
The operation can send a request and will wait for a response
Notification
The operation can send a message but will not wait for a response
One-Way Operation
Request-response
The operation can receive a request and will return a response
Solicit-response
The operation can send a request and will wait for a response
Notification
The operation can send a message but will not wait for a response
One-Way Operation
A one-way operation example:
In this example the port "glossaryTerms" defines a one-way operation called "setTerm". The "setTerm" operation allows input of new glossary terms messages using a "newTermValues" message with the input parameters "term" and "value". However, no output is defined for the operation.
Request-Response Operation
Request-Response Operation
A request-response operation example:
In this example the port "glossaryTerms" defines a request-response operation called "getTerm".
The "getTerm" operation requires an input message called "getTermRequest" with a parameter called "term", and will return an output message called "getTermResponse" with a parameter called "value".
WSDL Binding
In this example the port "glossaryTerms" defines a request-response operation called "getTerm".
The "getTerm" operation requires an input message called "getTermRequest" with a parameter called "term", and will return an output message called "getTermResponse" with a parameter called "value".
WSDL Binding
WSDL bindings defines the message format and protocol details for a web service.
Binding to SOAP
A request-response operation example:
The binding element has two attributes - the name attribute and the type attribute.
The name attribute (you can use any name you want) defines the name of the binding, and the type attribute points to the port for the binding, in this case the "glossaryTerms" port.
The soap:binding element has two attributes - the style attribute and the transport attribute.
The style attribute can be "rpc" or "document". In this case we use document. The transport attribute defines the SOAP protocol to use. In this case we use HTTP.
A request-response operation example:
The binding element has two attributes - the name attribute and the type attribute.
The name attribute (you can use any name you want) defines the name of the binding, and the type attribute points to the port for the binding, in this case the "glossaryTerms" port.
The soap:binding element has two attributes - the style attribute and the transport attribute.
The style attribute can be "rpc" or "document". In this case we use document. The transport attribute defines the SOAP protocol to use. In this case we use HTTP.
The operation element defines each operation that the port exposes.
For each operation the corresponding SOAP action has to be defined. You must also specify how the input and output are encoded. In this case we use "literal".
Since WSDL is a machine-readable language (e.g., it's just an XML file), tools and infrastructure can be easily built around it. Today developers can use WSDL definitions to generate code that knows precisely how to interact with the Web service it describes. This type of code generation hides the tedious details involved in sending and receiving SOAP messages over different protocols and makes Web Services approachable by the masses.
For each operation the corresponding SOAP action has to be defined. You must also specify how the input and output are encoded. In this case we use "literal".
Since WSDL is a machine-readable language (e.g., it's just an XML file), tools and infrastructure can be easily built around it. Today developers can use WSDL definitions to generate code that knows precisely how to interact with the Web service it describes. This type of code generation hides the tedious details involved in sending and receiving SOAP messages over different protocols and makes Web Services approachable by the masses.
The Microsoft® .NET Framework comes with a command-line utility named wsdl.exe that generates classes from WSDL definitions. Wsdl.exe can generate one class for consuming the service and another for implementing the service. (Apache Axis comes with a similar utility named WSDL2Java that performs the same function for Java classes.) Classes generated from the same WSDL definition should be able to communicate with each other through the WSDL-provided interfaces, regardless of the programming languages in use (see Figure 5).
WSDL and code generation
WSDL 1.1 is considered the de-facto standard today because of it's industry-wide support. Most Web Services toolkits support WSDL 1.1, but there have been some interoperability problems across the different implementations. Many developers believe that the extensive flexibility of WSDL (and the resulting complexity) is the fundamental source of these problems. The WS-I has helped resolve some of these issues by encouraging developers to use certain parts of the specification and discouraging them from using others.
WSDL 1.1 is considered the de-facto standard today because of it's industry-wide support. Most Web Services toolkits support WSDL 1.1, but there have been some interoperability problems across the different implementations. Many developers believe that the extensive flexibility of WSDL (and the resulting complexity) is the fundamental source of these problems. The WS-I has helped resolve some of these issues by encouraging developers to use certain parts of the specification and discouraging them from using others.
The W3C is actively working on the next "official" version of WSDL, WSDL 1.2, but it's currently only a Working Draft and not supported by the mainstream toolkits, if any. The remainder of this article discusses the details of a WSDL 1.1 definition and highlights some of the WS-I basic profile suggestions along the way.
4. UDDI
Universal Description, Discovery and Integration (UDDI) is a directory service where businesses can register and search for Web services.
What is UDDI
- UDDI is a platform-independent framework for describing services, discovering businesses, and integrating business services by using the Internet.
- UDDI stands for Universal Description, Discovery and Integration
- UDDI is a directory for storing information about Web Services
- UDDI is a directory of web service interfaces described by WSDL
- UDDI communicates via SOAP
- UDDI is built into the Microsoft .NET platform
What is UDDI Based On?
UDDI uses World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF) Internet standards such as XML, HTTP, and DNS protocols. UDDI uses WSDL to describe interfaces to Web Services Additionally, cross platform programming features are addressed by adopting SOAP, known as XML Protocol messaging specifications found at the W3C Web site.
UDDI uses World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF) Internet standards such as XML, HTTP, and DNS protocols. UDDI uses WSDL to describe interfaces to Web Services Additionally, cross platform programming features are addressed by adopting SOAP, known as XML Protocol messaging specifications found at the W3C Web site.
UDDI Benefits
Any industry or businesses of all sizes can benefit from UDDI
Before UDDI, there was no Internet standard for businesses to reach their customers and partners with information about their products and services. Nor was there a method of how to integrate into each other's systems and processes.
Any industry or businesses of all sizes can benefit from UDDI
Before UDDI, there was no Internet standard for businesses to reach their customers and partners with information about their products and services. Nor was there a method of how to integrate into each other's systems and processes.
Problems the UDDI specification can help to solve:
- Making it possible to discover the right business from the millions currently online
- Defining how to enable commerce once the preferred business is discovered
- Reaching new customers and increasing access to current customers
- Expanding offerings and extending market reach
Solving customer-driven need to remove barriers to allow for rapid participation in the global Internet economy.Describing services and business processes programmatically in a single, open, and secure environment
How can UDDI be Used
If the industry published an UDDI standard for flight rate checking and reservation, airlines could register their services into an UDDI directory. Travel agencies could then search the UDDI directory to find the airline's reservation interface. When the interface is found, the travel agency can communicate with the service immediately because it uses a well-defined reservation interface.
Who is Supporting UDDI?
5. AN EXAMPLE ASP.NET WEB SERVICE
In this example we use ASP.NET to create a simple Web Service.
In file menu Select for New Project select ASP.NET WebService.
using System;using System.Web;
In this example we use ASP.NET to create a simple Web Service.
In file menu Select for New Project select ASP.NET WebService.
using System;using System.Web;
using System.Web.Services;
WebService1
{
public class Service1 : System.Web.Services.WebService
{
public Service1()
{
//CODEGEN: This call is required by the ASP.NET Web Services Designer
InitializeComponent();
}
[WebMethod]
public string HelloWorld()
{
return "Hello World";
}
}
}
public class Service1 : System.Web.Services.WebService
{
public Service1()
{
//CODEGEN: This call is required by the ASP.NET Web Services Designer
InitializeComponent();
}
[WebMethod]
public string HelloWorld()
{
return "Hello World";
}
}
}
6. WEB SERVICES ATTRIBUTE CLASS
The Webservice attribute allows additional information to be added to a webservice. The WebService attribute is optional
The Webservice attribute allows additional information to be added to a webservice. The WebService attribute is optional
[WebService(PropertyName = Value)]
The Property Names are
Descripton
Assigns a descriptive message to the webservice. The webservice description will be displayed in the webservice help page when the page is tested in a browser and also made available in the SOAP message to any potential consumers of the webservice Name
It’s the name of the class implementing the webservice. The Web Service attributes name property allows the name to be changed.
Namespace each webservice has an XML namespace associated with it. An XML namespace allows you to create names in an XML document that are uniquely identified by a Uniform Resource Identifier(UDI).
Ex:
Ex:
[WebService(Namespace:="http://hsweb/WebService1/nsAndWebService1", Name:="CWebService", Description:="Demo on webservices")]
Web Method
The web method attribute has properties that are used to configure the behavior of the specific web method. They are
The web method attribute has properties that are used to configure the behavior of the specific web method. They are
- The Buffer Response
- The Cache Duration
- The Description
- The Enable Session
- The Message Name
- The Transaction Option
Buffer Response
The BufferResponse property of the WebMethod attribute enables buffering of responses for a Web Service method.
When set to true (default Setting), the default setting, ASP.NET buffers the entire response before sending it down to the client. Serializes the response of the Web Service method into a memory buffer until either the response is completely serialized or the buffer is full. Once the response is buffered, it is returned to the Web Service client over the network.
When set to FalseASP.NET buffers the response in chunks of 16KB. Typically, you would set this property to false only if you did not want the entire contents of the response in memory at once. The response to the Web Service method is sent back to the client as it is serialized. For smaller amounts of data, Web Service performance is better with BufferResponse to true.
When set to FalseASP.NET buffers the response in chunks of 16KB. Typically, you would set this property to false only if you did not want the entire contents of the response in memory at once. The response to the Web Service method is sent back to the client as it is serialized. For smaller amounts of data, Web Service performance is better with BufferResponse to true.
Example:
public class Service1 : System.Web.Services.WebService
{
[WebMethod(BufferResponse:= False)]
public void GetBigData
{
//implementation code
}
}
public class Service1 : System.Web.Services.WebService
{
[WebMethod(BufferResponse:= False)]
public void GetBigData
{
//implementation code
}
}
Cache Duration
The CacheDuration property of the WebMethod attribute enables caching of the results for a Web Service method
The CacheDuration property of the WebMethod attribute enables caching of the results for a Web Service method
[WebMethod(CacheDuration:= Property Value)]
Where Property Value The number of seconds the response should be held in the cache. The default is 0, which means the response is not cached. ASP.NET will cache the results for each unique parameter set.
Example:
[WebMethod(CacheDuration:=60)]
Public double ConvertTemperature(double dFahrenheit)
{
return ((dFahrenheit - 32) * 5) / 9 ;
}
[WebMethod(CacheDuration:=60)]
Public double ConvertTemperature(double dFahrenheit)
{
return ((dFahrenheit - 32) * 5) / 9 ;
}
Description
The Description property of the WebMethod attribute supplies a description for a Web Service method that will appear on the Service help page. Unless otherwise specified, the default value is an empty string.
Example:
[WebMethod(Description:="This method converts a temperature in degrees Fahrenheit to a temperature in degrees Celsius.")]
Public double ConvertTemperature(double dFahrenheit)
{
ConvertTemperature = ((dFahrenheit - 32) * 5) / 9 ;
}
[WebMethod(Description:="This method converts a temperature in degrees Fahrenheit to a temperature in degrees Celsius.")]
Public double ConvertTemperature(double dFahrenheit)
{
ConvertTemperature = ((dFahrenheit - 32) * 5) / 9 ;
}
Enable Session
The EnableSession property of the WebMethod attribute enables session state for a Web Service method. If session state is not needed for a Web Service method, then disabling it may improve performance.
The default is false
Ex:
[WebMethod(EnableSession:=True)]
public int SessionHitCounter()
{
If (Session("HitCounter")==null )
Session("HitCounter") = 1;
Else
Session("HitCounter") = CInt(Session("HitCounter")) + 1 ;
Return CInt(Session("HitCounter"));
}
Message Name
The MessageName property of the WebMethod attribute enables the Web Service to uniquely identify overloaded methods using an alias. Unless otherwise specified, the default value is the method name. When specifying the MessageName, the resulting SOAP messages will reflect this name instead of the actual method name.
The EnableSession property of the WebMethod attribute enables session state for a Web Service method. If session state is not needed for a Web Service method, then disabling it may improve performance.
The default is false
Ex:
[WebMethod(EnableSession:=True)]
public int SessionHitCounter()
{
If (Session("HitCounter")==null )
Session("HitCounter") = 1;
Else
Session("HitCounter") = CInt(Session("HitCounter")) + 1 ;
Return CInt(Session("HitCounter"));
}
Message Name
The MessageName property of the WebMethod attribute enables the Web Service to uniquely identify overloaded methods using an alias. Unless otherwise specified, the default value is the method name. When specifying the MessageName, the resulting SOAP messages will reflect this name instead of the actual method name.
Ex:
[WebMethod(MessageName:="AddDoubles")]
public double Add(double dValueOne, double dValueTwo )
{
return dValueOne + dValueTwo ;
}
Transaction
The TransactionOption property of the WebMethod attribute enables the Web Service method to participate as the root object of a transaction.
[WebMethod(MessageName:="AddDoubles")]
public double Add(double dValueOne, double dValueTwo )
{
return dValueOne + dValueTwo ;
}
Transaction
The TransactionOption property of the WebMethod attribute enables the Web Service method to participate as the root object of a transaction.
Transaction Option has the following values
- Disabled
- Not Supported
- Supported
- Required
- Requires New
- Disabled
Indicates that the Web Service method does not run within the scope of a transaction. When a request is processed, the Web Service method is executed without a transaction. [WebMethod(TransactionOption=TransactionOption.Disabled)]
Not Supported
Indicates that the Web Service method does not run within the scope of a transaction. When a request is processed, the Web Service method is executed without a transaction.
[WebMethod(TransactionOption= TransactionOption.NotSupported)]
Supported
Run within the scope of transactions. When a request is processed, the Web Service is created without a transaction.
[WebMethod(TransactionOption= TransactionOption.Supported)]
Not Supported
Indicates that the Web Service method does not run within the scope of a transaction. When a request is processed, the Web Service method is executed without a transaction.
[WebMethod(TransactionOption= TransactionOption.NotSupported)]
Supported
Run within the scope of transactions. When a request is processed, the Web Service is created without a transaction.
[WebMethod(TransactionOption= TransactionOption.Supported)]
Required
Indicates that the Web Service method requires a transaction. Since Web Service methods, can only participate as the root object in a transaction, a new transaction will be created for the Web Service method.
[WebMethod(TransactionOption= TransactionOption.Required)]
RequiresNew
Indicates that the Web Service method requires a new transaction. When a request is processed, the Web Service is created within a new transaction.
[WebMethod(TransactionOption= TransactionOption.RequiresNew)]
Namespaces related to WebServices
Ø System.Web.Services
Ø System.Web.Description
Ø System.Web.Services.Discovery
Ø System.Web.Services.Protocols
No comments :
Post a Comment