2. INDEX
• Introduction of Web Services
• Extensible Markup Language (XML)
• Web Service Description Language (WSDL)
• Simple Object Access Protocol (SOAP)
• Universal Description, Discovery, and Integration (UDDI)
• Transactions
• Business Process Execution Language for Web Services
• WS-Security and Web Services Security specifications
• WS-Reliable Messaging
• WS-Policy
• WS-Attachments
• REST-ful web services
• Comparison of REST and SOAP
3. Introduction of Web Services
• Web services are self-contained, modular, distributed, dynamic applications that can be
described, published, located, or invoked over the network to create products, processes,
and supply chains.
• These applications can be local, distributed, or web-based. Web services are built on top
of open standards such as TCP/IP, HTTP, Java, HTML, and XML.
web service is, therefore, any service that −
• Is available over the Internet or private (intranet) networks
• Uses a standardized XML messaging system
• Is not tied to any one operating system or programming language
• Is self-describing via a common XML grammar
• Is discoverable via a simple find mechanism
4. Extensible Markup Language (XML)
XML is a simple tag-based language for describing information in a structured way.
Basic elements:
• Tags
• Attributes
• Text
5. Web Service Description Language
(WSDL)
• Web Service Description Language is a document written in XML, which contains the
description of Web services.
• It specifies the location of the service and the methods the service exposes.
• WSDL describes the services as a collection of communication endpoints capable of
exchanging messages.
• A WSDL document consists of the following six elements:
• Definition
• Data type
• Message
• Port type
• Binding
• Service
6. Simple Object Access Protocol (SOAP)
• SOAP is a technology to support the exchange of XML-coded messages over a
transport protocol, such as HTTP and SMTP. (wire stack)
7. • A SOAP message is a simple well-structured XML document, which always contains a
mandatory envelope and Body element.
• It can also contain a few optional elements, such as the Header element, which contains
the application-specific information, and the fault element, which contains the error and
status of the messages.
• The SOAP message inherits all features of XML, such as platform independence and self
documenting format.
• Elements of SOAP message are:
• Envelope
• Header
• Body
• Fault
8. Universal Description, Discovery, and
Integration (UDDI)
• UDDI refers to a centralized directory where the Web services offered by different
organizations are published.
• UDDI stores information about Web services and communicates with those Web services
using SOAP.
• UDDI also defines how to enable transactions between customers and reach new
customers.
• UDDI Application Programming Interface (API) has the get_businessDetail() method to
retrieve the details of a business. This method is redundant and can be removed from
API.
• UDDI has many get_methods that work on data objects, such as business services. These
data objects can be represented by XML documents.
9. • When a business changes its information, it registers that change in UDDI. In addition to
the get_businessDetail() method, other methods of UDDI can also be removed from the
UDDI API.
• These methods are the delete_business() method that is used to remove a business, the
save_business() method that is used to upload new businesses, and the find_business()
method that is used to search a particular business.
• All methods in UDDI API can be implemented by HTTP-based URIs. This produces
another type of architecture for representing Web services of businesses, called REST.
10. Transactions
• Transaction context management resides in the WS-Coordination (WS-C) (Microsoft,
BEA, IBM,`Web Service Coodination’, 2005), WSAtomicTransaction (WS-AT)
(Microsoft, BEA, IBM, `Web Service Atomic Transaction’, 2005) and WS-
BusinessActivity (WS-BA) (Microsoft, BEA, IBM,`Web Service Business Activity’,
2005) specifications.
• WS-C defines a coordination context, which represents an instance of coordinated
effort, allowing participant services to share a common view.
• WS-AT targets existing transactional systems with short interactions and full ACID
properties.
• WS-BA, on the other hand, is intended for applications involved in business processes
of long duration, whose relaxed properties increase concurrency and suit a wider range
of applications.
11. • Neither the Web services architecture nor any specifications prescribe explicit ways to
implement transactional capabilities, although it is clear that delivering such features
should minimally impact existing applications.
• Some propose approaching the problem of transaction monitoring and support by means
of intermediary (proxy) services (Mikalsen, 2002), while others by providing a
lightweight programming interface requiring minimal application code changes
(Vasquez, Miller, Verma, & Sheth, 2005). Whichever the case, protocol-specific
messages should also be embedded in exchanged messages and propagated though all
participants.
12. Business Process Execution Language for
Web Services
• Business Process Execution Language (BPEL) defines a notation for specifying
business process behavior based on Web Services.
• Business processes can be described in two ways:
• Executable business processes model actual behavior of a participant in a business
interaction.
• Business protocols, in contrast, use process descriptions that specify the mutually
visible message exchange behavior of each of the parties involved in the protocol,
without revealing their internal behavior. The process descriptions for business
protocols are called abstract processes.
13. • BPEL is used to model the behavior of both executable and abstract processes. The
scope includes:
• Sequencing of process activities, especially Web Service interactions
• Correlation of messages and process instances
• Recovery behavior in case of failures and exceptional conditions
• Bilateral Web Service based relationships between process roles
14. WS-Security and Web Services Security
specifications
• The WS-Security specification provides a framework and vocabulary for requesters and
providers to secure messaging as well as communicate information regarding security
and privacy.
• There are other security related specifications like:
• XML-Encryption specifies the process of encrypting data and messages.
• XML-Signature provides a mechanism for messages integrity and authentication,
and signer authentication.
• XACML (Extensible Access Control Markup Language) is an XML representation
of the Role-Based Access Control standard (RBAC). XACML plays an important
function in Web services authorization.
• Security Assertion Markup Language, or SAML, is an OASIS framework for
conveying user authentication and attribute information through XML assertions.
15. WS-Reliable Messaging
• Communication over a public network such as the Internet imposes physical limitations
to the reliability of exchanged messages.
• Even though failures are inevitable and unpredictable, certain techniques increase
message reliability and traceability even in the worst cases.
• At a minimum, senders are interested in determining whether the message has been
received by the partner, that it was received exactly once and in the correct order.
• It is necessary to determine the validity of the received message:
• Has the message been altered on its way to the receiver?
• Does it conform to standard formats?
• Does it agree with the business rules expected by the receiver?
• WS-Reliability and WS-Reliable Messaging have rules that dictate how and when
services must respond to other services concerning the receipt of a message and its
validity.
17. WS-Policy
• WS-Policy is a specification of a framework for defining the requirements and
capabilities of a service.
• In short, a policy is a set of assertions that express the capabilities and requirements of a
service.
• The specification WS-Policy (http://www128.ibm.com/developerworks/library/
specification/ws-polfram/) defines terms that can be used to organize a policy.
• Once a provider has a policy defined in XML, then he must publish that information by
referencing it in the description of the service.
18. WS-Attachments
• It is a method for attaching a policy to a WSDL file so that it can be published to the
UDDI and thus used in deciding on services.
• There are several mechanisms defined for accomplishing this task.
• The simplest method is to write the policy directly into the WSDL file.
• A more complex, and more powerful method is to construct the policy as a stand alone
file that is referenced in the WSDL file as a URI.
• WS-Policy and WS-PolicyAttachment together give us hierarchy based on to which
element the policy is attached and direction for merging policies together to create an
effective policy for an element (WS-PolicyAttachment, 2005).
19. REST-ful web services
• REST stands for Representational State Transfer. REST is an architectural style not a
protocol.
Advantages of RESTful Web Services:
• Fast: RESTful Web Services are fast because there is no strict specification like SOAP.
It consumes less bandwidth and resource.
• Language and Platform independent: RESTful web services can be written in any
programming language and executed in any platform.
• Can use SOAP: RESTful web services can use SOAP web services as the
implementation.
• Permits different data format: RESTful web service permits different data format
such as Plain Text, HTML, XML and JSON.
21. MU Exam Questions
May 2017
• Describe SOAP protocol and message structure briefly. 10 marks
Dec 2018
• Describe SOAP protocol and message structure briefly. 10 marks
May 2019
• Explain in detail WS-Reliable Messaging. 10 marks
• SN: SOAP. 5 marks
• SN: REST-ful web services. 5 marks
