Distributed Systems Web Services PDF

Distributed Systems Web Services From Coulouris, Dollimore, Kindberg and Blair Distributed Systems: Concepts and Design Edition 5, © Addison-Wesley 2012 1 Introduction  A web service provides a service interface enabling clients to...

Distributed Systems Web Services From Coulouris, Dollimore, Kindberg and Blair Distributed Systems: Concepts and Design Edition 5, © Addison-Wesley 2012 1 Introduction  A web service provides a service interface enabling clients to interact with servers in a more general way than web browsers do  Clients access the operations in the interface of a web service by means of requests and replies formatted in XML and usually transmitted over HTTP  Users require a secure means for creating, storing and modifying documents and exchanging them over the Internet  The secure channels of TLS do not provide all of the necessary requirements 2 Introduction  XML security is intended to breach this gap  Web services provide an infrastructure for maintaining a richer and more structured form of interoperability between clients and server.  They provide a basis whereby a client program in one organization may interact with a server in another organization without human supervision  External data representation and marshalling of messages exchanged between clients and web services is done in XML. 3 Introduction  The SOAP (Simple Object Access Protocol) specifies the rules for using XML to package messages, for example to support a request-reply protocol  Web Services  One of the dominant paradigms for programming distributed systems  Enables business to business integration. (Suppose one organization uses CORBA and another uses.NET) No problem!  Enables Service Oriented Architecture (SOA).  Adopted by the grid computing community.  May exist internally to an organization or externally (in the cloud) 4 Introduction  What are Web Services? ML1  Web Services began life when Bill Gates introduced BizTalk in 1999.  BizTalk was later renamed.NET.  The idea: “to provide the technologies to allow software in different places, written in different languages and resident on different platforms to connect and interoperate.” From “Programming the World Wide” by Sebesta 5 5 ‫الشريحة‬ ML1 My Laptop, 1/2/2025 Service-Oriented Architecture (SOA)  Is a design approach in distributed systems where applications are built by integrating loosely coupled, reusable services.  These services are self-contained, modular, and communicate over a network to perform specific tasks.  SOA emphasizes interoperability, flexibility, and scalability, making it a popular choice for building complex, distributed systems. 6 Service-Oriented Architecture (SOA)  Key Concepts of SOA  Services Services are the core building blocks of SOA. Each service encapsulates a specific business function (e.g., payment processing, user authentication). Services are independent and can be developed, deployed, and maintained separately.  Loose Coupling Services interact with each other through well-defined interfaces (APIs). Changes to one service do not directly impact others, as long as the interface remains consistent. 7 Service-Oriented Architecture (SOA)  Key Concepts of SOA  Interoperability Services communicate using standard protocols (e.g., HTTP, SOAP, REST, messaging queues). This allows services written in different languages or running on different platforms to work together.  Reusability Services are designed to be reusable across multiple applications or systems. This reduces redundancy and promotes efficiency. 8 Service-Oriented Architecture (SOA)  Key Concepts of SOA  Discoverability Services are often registered in a service registry or directory (e.g., UDDI). This allows other components to discover and use them dynamically.  Abstraction The internal implementation of a service is hidden from consumers. Consumers only need to know the service's interface and functionality.  Composability Services can be combined or orchestrated to create complex workflows or business processes. 9 Service-Oriented Architecture (SOA)  Components of SOA  Service Provider The entity that creates and exposes the service. Implements the service logic and makes it available for consumption.  Service Consumer The entity that uses the service. Invokes the service by sending requests and receiving responses.  Service Registry A directory where services are published and discovered. Acts as a central repository for service descriptions. 10 Service-Oriented Architecture (SOA)  Components of SOA  Service Contract Defines the interface, communication protocols, and data formats for interacting with the service.  Enterprise Service Bus (ESB) A middleware component that facilitates communication between services. Handles message routing, transformation, and mediation. 11 Service-Oriented Architecture (SOA)  Communication Protocols in SOA  SOAP (Simple Object Access Protocol) A protocol for exchanging structured information using XML. Often used in enterprise-level SOA implementations.  REST (Representational State Transfer) A lightweight, stateless architecture that uses HTTP methods (GET, POST, PUT, DELETE). Commonly used in modern SOA implementations.  Messaging Queues Used for asynchronous communication between services. Examples: RabbitMQ, Apache Kafka. 12 Service-Oriented Architecture (SOA)  Two types (approaches)  SOAP (Simple Object Access Protocol) Based Web Services  REST style web services 13 SOAP based Web services  Web Services Infrastructure and Components 14 SOAP based Web services  Application o The application represents the software that provides or consumes web services. o It interacts with the web services using SOAP messages for data exchange.  Directory Service o The directory service acts as a repository of web services and their metadata. o It helps clients discover and locate available web services and their endpoints.  Security Choreography o Security choreography defines the sequence of security-related interactions between the parties involved in a web service communication. o It ensures secure authentication, encryption, and data integrity during the exchange of SOAP messages. 15 SOAP based Web services  Web Services Descriptions (in WSDL) o WSDL (Web Services Description Language) is an XML-based language used to describe web service functionalities. o It specifies the operations, messages, and communication protocols supported by the web service.  SOAP (Simple Object Access Protocol) o SOAP is a protocol for exchanging structured information in the implementation of web services. o It defines the format of the XML messages and the rules for their exchange between applications.  URLs (URN, URI) o URLs (Uniform Resource Locators) are used to identify resources on the web. o URIs (Uniform Resource Identifiers) uniquely identify resources, while URNs 16 (Uniform Resource Names) are a subset of URIs used for persistent identification. SOAP based Web services  XML (eXtensible Markup Language) o XML is a markup language used to structure data in a hierarchical format. o It is used to encode the content of SOAP messages and represents data in a machine- readable format.  HTTP (Hypertext Transfer Protocol) o HTTP is a protocol used for transferring data over the web. o It carries SOAP messages between clients and web services, typically over the internet.  SMTP (Simple Mail Transfer Protocol) o SMTP is a protocol used for sending and receiving email messages. o It can be used for transmitting SOAP messages over email, though less common than HTTP in web service communication. 17 SOAP based Web services  SOAP Style Web Services  Provide service interfaces  Communicate using request and reply messages made of SOAP or some other XML document  Have an Interface Definition Language (IDL) called WSDL (Web Service Definition Language)  May be looked up in a web service UDDI registry  UDDI (Universal Directory and Discovery Service)  Are language independent  May be synchronous or asynchronous 18 SOAP based Web services 19 SOAP based Web services  Communication Patterns  In general, web services use either a synchronous request-reply pattern of communication with their clients or they communicate by asynchronous messages.  To allow for a variety of patterns, SOAP is based on the packaging of single one-way messages.  SOAP is used to hold RPC style parameters or entire documents.  Originally, SOAP was based on HTTP, but the current version may be used over different transport protocols (SMTP, TCP, UDP, or HTTP) 20 SOAP based Web services  Service References  URI’s – Uniform Resource Identifiers URL’s  Uniform Resource Locator URI’s that include location information resources pointed to by URL’s are hard to move  URN’s – Uniform Resource Name URI’s that include no location information  A uniform resource identifier (URI) is a uniform resource locator (URL), uniform resource name (URN), or both 21 SOAP based Web services  Examples:  URL: http://www.cmu.edu/service  URN: urn:ISBN:0-273-76059-9  The ‘travel agent service’ combines other web services 22 SOAP based Web services  SOAP  defines a scheme for using XML to represent the contents of request and reply messages as well as a scheme for the communication of documents  The SOAP specification states:  How XML is to be used to represent the contents of individual messages  How a pair of single messages can be combined to produce a request-reply pattern  The rules as to how the recipients of messages should process the XML elements that they contain  How HTTP and SMTP should be used to communicate SOAP messages  A SOAP message is carried in an “envelope”  Inside the envelope there is an optional header and a body  SOAP’s usual protocol – TCP 23 SOAP based Web services  SOAP message in an envelope  Message headers can be used for establishing the necessary context for a service or for keeping a log or audit of operations  The message body carries an XML document for a particular web service  The XML elements envelope, header and body, together with other attributes and elements of SOAP messages are defined as a scheme in the SOAP XML namespace 24 REST  REST, or REpresentational State Transfer, is an architectural style for providing standards between computer systems on the web, making it easier for systems to communicate with each other.  REST-compliant systems, often called RESTful systems, are characterized by how they are stateless and separate the concerns of client and server.  We will go into what these terms mean and why they are beneficial characteristics for services on the Web. Pay close attention: If you’re looking for a career in tech, you may be asked to define rest during an interview. 25 REST  What's REST?  is an architectural style for designing networked applications, particularly web services.  It relies on a stateless, client-server communication model, where interactions are based on standard HTTP methods (GET, POST, PUT, DELETE, etc.).  REST is widely used for building APIs (Application Programming Interfaces) due to its simplicity, scalability, and flexibility.  Statelessness is a key principle that ensures each request from a client to a server is independent and self-contained.  This means the server does not store any client state (data or context) between requests. Instead, every request must include all the information necessary for the server to understand and process it. 26 REST  Separation of Client and Server  In the REST architectural style, the implementation of the client and the implementation of the server can be done independently without each knowing about the other.  This means that the code on the client side can be changed at any time without affecting the operation of the server, and the code on the server side can be changed without affecting the operation of the client.  As long as each side knows what format of messages to send to the other, they can be kept modular and separate.  Separating the user interface concerns from the data storage concerns, we improve the flexibility of the interface across platforms and improve scalability by simplifying the server components. 27 REST  REST Architectural Principles  Consists of constraints: 1. Client - Server 2. Stateless 3. Cache 4. Uniform Interface 5. Layered System 6. Code-On-Demand(Optional) 28 REST  Principle: Addressability  Addressability (not restricted to HTTP)  Each HTTP request uses a URI  The format of a URI is well defined:  scheme://host:port/path?queryString#fragment  The scheme need not be HTTP  may be FTP or HTTPS  The host field may be a DNS name or an IP address  The port may be derived from the scheme  e.g. using HTTP implies port 80  The path is a set of text segments delimited by the “/”  The query String is a list of parameters represented as name=value pairs  Each pair is delimited by an “&”  The fragment is used to point to a particular place in a document  A space is represented with the ‘+’ characters  Other characters use % followed by two hex digits 29 Homework 4  Read chapter 9 and solve of the questions 30