Web services and SOAP

Web applications with Web services,

Web Applications

Web application are defined by being interactive. You're supposed to use a web application in order to perform a function and use some of the web applications features. Lots of web applications don't even have real informative content or data exactly. People are just supposed to use them in order to perform additional tasks, using their features to accomplish something. You use a web application to check your incoming messages, for instance, or play a game.

The browser capabilities involved with web applications are significantly more high-tech, which is one reason why it's usually harder for people to design a web application than a website. Websites are all about getting more data, and web applications are all about doing things. One of your actions is probably going to be getting more information or learning more information, but the web application helped you perform that action. You got the information from a website.

The user interface of a web application is also usually much more complicated than the user interface of a website. Websites might have tags and categories that you need to understand, but you don't have to go through and learn any potentially complicated tasks in order to use websites. Web applications often require step-by-step guides, or you're not going to be able to complete them.

The setup of websites are completely different from web applications in most cases. The rhythm of typing in the address, loading websites, and going back and forth between websites is often absent with web applications.

Web applications, unsurprisingly, are usually harder to design and create than websites. Lots of people have their own websites today, and this was the case even ten years ago. The people who are able to create their own web applications can more easily make money off of them because it takes more work to learn how to code and create a web application.

Web Services

Web service is a technology by which two or more remote web applications interact with each other over network/internet. It can be implemented using Java, .net, PHP etc. Web pages allow people to communicate and collaborate with each other while web services allow programs to communicate and collaborate with each other.

A web service is essentially a collection of open protocols and standards used for exchanging data between applications or systems. Software applications written in various programming languages and running on various platforms can use web services to exchange data over computer networks like the Internet in a manner similar to inter-process communication on a single computer. This interoperability (e.g., between Java and Python, or Windows and Linux applications) is due to the use of open standards (XML, SOAP, HTTP).

All the standard Web Services works using following components:

SOAP (Simple Object Access Protocol)UDDI (Universal Description, Discovery and Integration)WSDL (Web Services Description Language)

It works somewhat like this:

The client program bundles the account registration information into a SOAP message.This SOAP message is sent to the Web Service as the body of an HTTP POST request.The Web Service unpacks the SOAP request and converts it into a command that the application can understand.

WEB SERVICE DESCRIPTION LANGUAGE - WSDL

•WSDL is an XML vocabulary for describing Web services allowing developers to describe Web Services and their capabilities, in a standard manner.

•standard format to describe a Web Service (description stack)

•specifies three fundamental properties:

•What a service does - operations (methods) provided by the service

• How a service is accessed - data format and protocol details

•Where a service is located - Address (URL) details

•The document written in WSDL is also simple called a WSDL (or WSDL document)

•WSDL is a contract between the XML(SOAP) Web service and the client who wishes to use this service

•The service provides the WSDL document and the Web service client uses the WSDL document to create the stub (or to dynamically decode messages)

WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate, however, the only bindings described in this document describe how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.

The Web Services Description Language (WSDL) is an XML-based interface description language that is used for describing the functionality offered by a web service. The acronym is also used for any specific WSDL description of a web service (also referred to as a WSDL file), which provides a machine-readable description of how the service can be called, what parameters it expects, and what data structures it returns. Therefore, its purpose is roughly similar to that of a type signature in a programming language.

WSDL ELEMENTS TYPE :

•use the XML schema language to declare

complex data types and elements that are used

elsewhere in the WSDL document

•serve as a container for defining any data types that are not described by the XML schema builtin

types: complex types and custom simple

types,

• the data types and elements defined in the types element are used by message definitions when declaring the parts (payloads) of messages

• any WSDL interface is the set of messages that the service behind the interface expects to send and

receive

•messages are abstractions of request and response messages that clients and web services exchange

partitioned into a number of logical parts to ease access to its contents

•messages are constructed from a number of XML Schema typed part elements, which can come from

the types part of the description or an external schema that has been imported into the same WSDL document

• they contain types of other schemas and user defined types into input, output and fault messages that the web service will consume and produce

WSDL ELEMENTS PORT TYPE

• define web service functionality at abstract level grouping sets of message exchanges into operations

• contain a set of operations that incorporates input, output and fault messages and parameter order

•WSDL supports at least a single input and output message, but permits the declaration of an arbitrary

number of faults

• portType element may have one or more operation elements, each of which defines an RPC- or documentstyle Web service method

• Java equivalence:

• portType -> java interface

• operation -> method name

WSDL ELEMENTS BINDING

•map a PortType to a specific protocol, typically

SOAP over http, using a specific data

encoding style

•one portType can be bound to several

different protocols by using more than one

port

•bindings refer back to portTypes by name,

just as operations point to messages.

•binding styles may be either “RPC” or

“Document”(SOAP).

•also specify SOAP encoding

The <binding> element provides specific details on how a portType operation will actually be transmitted over the wire.

The bindings can be made available via multiple transports including HTTP GET, HTTP POST, or SOAP.

The bindings provide concrete information on what protocol is being used to transfer portType operations.

The bindings provide information where the service is located.

For SOAP protocol, the binding is <soap:binding>, and the transport is SOAP messages on top of HTTP protocol.

You can specify multiple bindings for a single portType.

The binding element has two attributes : name and type attribute.

<binding name = "Hello_Binding" type = "tns:Hello_PortType">

The name attribute defines the name of the binding, and the type attribute points to the port for the binding, in this case the "tns:Hello_PortType" port.

WSDL ELEMENTS SERVICE

• it binds the Web service to a specific network-addressable location, i.e. it takes the bindings declared previously and ties them to a port, which is a physical network endpoint to which clients bind over the specified protocol,

• contain one or more port elements, each of which represents a different Web service and the port element assigns the URL to a specific binding,

• reference a particular binding, and along with addressing information is wrapped together into a service element to form the final physical, network addressable Web service,

• access point for each port

• port type - The operations performed by the web service.

• message - The messages used by the web service.

• types - The data types used by the web service.

• binding - The communication protocols used by the web service.

SOAP- SIMPLE OBJECT ACCESS PROTOCOL

• SOAP supports both functional oriented and message oriented communication

• SOAP messages are carried as the payload of some other network protocol, for example

via HTTP or SMTP (Simple Mail Transfer Protocol) or FTP (File Transfer Protocol) or TCP/IP

(Transmission Control Protocol/Internet Protocol),

•Web services use SOAP as the logical transport mechanism for moving messages between services

described by WSDL interfaces

SOAP specifies the overall structure of a message, together with rules for wrapping SOAP messages with transport protocols.

SOAP combines the data capabilities of XML with the transport capability of HTTP.

SOAP MESSAGING MODES

• RPC enables SOAP messages to model calls to procedures or method calls with parameters and return

values

• in document mode, the document is placed directly as a child of the Body element

•SOAP messages

• consistent envelope - header and body

• consistent data encoding - based on XML Schema type system

•protocol binding framework

•has encoding rules

•defines a serialization mechanism that can be used to exchange instances of application-defined objects

• Envelope

• wraps entire message and contains

header and body

• defines an overall framework for

expressing what is in a message; who

should deal with it, and whether it is

optional or mandatory

• Header

• optional element with additional info

such as security or routing

• Body

• application-specific message content

being communicated as arbitrary XML

payloads in the request and response

messages

• fault element provides information

about errors that occurred while

processing the message

SOAP ELEMENTS ENVELOPE

•envelope is a root (or top-level) XML element

that acts as a container for the header and body

elements and is associated with the namespace

• the envelope tag indicates the start and end of

the message to the receiver

• reaching the </Envelope> tag, the node knows

the message has ended and can start processing

it, or picking up the attachments, if any

SOAP ELEMENTS HEADER (OPTIONAL)

• headers are really just extension points where elements from other

namespaces can be included, i.e., headers can contain arbitrary

XML

• header is optional but, if present, it must be the immediate child of

the Envelope element, and precede the Body element

• header adds meta-data about the content of a SOAP message and

extends it with extra information, such as routing, security,

transactions, etc. to support the transfer of the application content

in the body section

• SOAP allows header blocks to be targeted at specific SOAP nodes

for processing as the message travels along its message path

(SOAP headers control and process a message as it moves along a

message path)

• SOAP defines rules by which header blocks must be processed in

the message path (route that a SOAP message takes from the

initial sender to the ultimate receiver)

• headers may be processed independently of the body

SOAP ELEMENTS BODY

• it is the only mandatory part of the envelope and contains the

actual XML application payload intended for the ultimate

recipient of the message

• it must either follow the SOAP header or, if the header is

omitted, be the first element in the envelope

• the Body element contains the actual message sent for the

final recipient and ultimate recipient must understand the

content of the message

• the SOAP specification states the only constraints the SOAP

specification places on the SOAP body are that it is implicitly

targeted at the ultimate Recipient of the application content

and that the ultimate recipient must understand its contents

SOAP ELEMENTS ATTACHMENTPART

•SOAP messages may have one or more attachments

• each AttachmentPart object has a MIME header to indicate the type of data it contains.

• it may also have additional MIME headers to identify it or to give its location, which can be useful when there are multiple attachments

•when a SOAP message has one or more AttachmentPart objects, its SOAPPart object may or may not contain message content

IMPLEMENT SOAP SERVICES

•JAX-WS (Java API for XML Web Services) is a java package/library for developing web services

•It supports both Functional oriented and message oriented communication via SOAP

•JAX-WS API hides the complexity of SOAP from the application developer.

•JAX-WS uses the javax.jws package

•It uses annotations

•@WebService

•@WebMethod

•@OneWay

•@WebParam

•@WebResult

•Etc…