Cloud Computing & Web Services

Cheatsheet Content

Cloud Computing Basics Serial Computing Processes instructions one by one. Only one instruction executed at a time. Causes waste of hardware resources as only one part of hardware is active. Parallel Computing Uses multiple processing elements simultaneously to solve problems. Problems are broken down into instructions and solved concurrently. Why Parallel Computing? Manages extensive real-world dynamic data. Enables dynamic simulation and modeling. Provides concurrency, saves time and money. Manages complex, large datasets effectively. Ensures effective utilization of resources, unlike serial computing where hardware can be idle. Advantages: Saves time and money; multiple resources reduce time and costs. Solves larger problems impractical for serial computing. Utilizes non-local resources when local ones are finite. Better hardware utilization; serial computing wastes potential power. Applications: Databases and Data mining. Real-time simulation of systems. Science and Engineering. Advanced graphics, augmented reality, and virtual reality. Distributed Computing Multiple autonomous computers appear as a single system to the user. No shared memory; computers communicate via message passing. A single task is divided among different computers. Comparison: Parallel vs. Distributed Computing Parallel Computing Distributed Computing Many operations performed simultaneously System components located at different locations Single computer is required Uses multiple computers Multiple processors perform multiple operations Multiple computers perform multiple operations May have shared or distributed memory Only distributed memory Processors communicate via bus Computers communicate via message passing Improves system performance Improves system scalability, fault tolerance, and resource sharing Web Services in Cloud Computing Definition: A standardized medium to propagate communication between client and server applications on the WWW. A software module designed to perform specific tasks. Can be searched and invoked over the network. Provides functionality to the client upon invocation. Uses open protocols and standards for data exchange between different applications or systems. Enables software programs written in different languages and platforms to exchange data over networks (e.g., Internet). Facilitates inter-process communication on a computer. Types of Web Services Informational (Type I): Support simple request/response operations, always wait for requests, process, and respond. Complex (Type II): Implement coordination between inbound and outbound operations. Type I Op Port WS Request Response Type II WS Op Port Port Op Coordination Request Response Request Response How Web Services Work Client sends requests (web service calls) to the server hosting the web service. Uses Remote Procedure Calls (RPC) to perform requests. Example: Flipkart displaying prices via a web service. Front-end can be built in various languages (.NET, Java); web service communication uses a programming language. XML (Extensible Markup Language): Most important part of web service design. Simple, intermediate language for communication. Programs communicate using XML, forming a common platform. Employs SOAP (Simple Object Access Protocol) to transmit XML data. Data sent using standard HTTP. A SOAP message is XML data sent from a web service to an application. Client applications can be built in any language, as content is XML. Client Internet Server Response from server to the client Request from client to the Server Server Hosting the web Service Web Service Components XML and HTTP are fundamental. Typical web services use: SOAP (Simple Object Access Protocol) UDDI (Universal Description, Search, and Integration) WSDL (Web Services Description Language) SOAP: Simple Object Access Protocol XML-based communication protocol for exchanging messages between computers across different OS, programming environments, or object models. Codifies XML as an encoding scheme for request/response parameters using HTTP transport. A SOAP method is an HTTP request/response complying with SOAP encoding rules. A SOAP endpoint is an HTTP-based URL for method invocation target. Specifies how service-related messages are structured for exchange over the Internet. Uses openly available technologies to define a wire protocol. Commonly uses HTTP to transport XML-encoded serialized method argument data. This data executes client's method calls on remote systems. Design Criteria for Wire Protocols (like SOAP): Compactness: How terse a network package is. Smaller is better. Protocol efficiency: Directly related to compactness. Less overhead to send payload = more efficient. Coupling: Rate at which client application adapts to changes. Loosely coupled protocols are more flexible. Scalability: Ability to work with many recipients (hundreds to millions of clients). Interoperability: Ability to work across various computing platforms. SOAP Message Structure An ordinary XML document with these elements: Envelope: Defines start and end of message. Mandatory. Header: Optional attributes for message processing (intermediary or end-point). Optional. Body: Contains XML data being sent. Mandatory. Fault: Optional element for errors during message processing. <?xml version="1.0"?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <SOAP-ENV:Header> ... </SOAP-ENV:Header> <SOAP-ENV:Body> ... <SOAP-ENV:Fault> ... </SOAP-ENV:Fault> ... </SOAP-ENV:Body> </SOAP_ENV:Envelope> SOAP Envelope Element Root element of a SOAP message. Defines the XML document as a SOAP message. xmlns:soap namespace must be " http://www.w3.org/2003/05/soap-envelope/ ". If a different namespace is used, an error occurs and message is discarded. <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope/" soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding"> ... Message information goes here ... </soap:Envelope> encodingStyle Attribute Defines data types in the document. Can appear on any SOAP element and applies to its contents and child elements. A SOAP message has no default encoding. soap:encodingStyle="URI" SOAP Header Element Optional element for application-specific information (authentication, payment, etc.). If present, it must be the first child of the Envelope element. <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope/" soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding"> <soap:Header> <m:Trans xmlns:m="https://www.w3schools.com/transaction/" soap:mustUnderstand="1">234 </m:Trans> </soap:Header> ... </soap:Envelope> SOAP Fault Element Optional, used to indicate error messages. Holds errors and status information. If present, must be a child of the Body element (only once). Sub-elements: Sub Element Description <faultcode> Code for identifying the fault <faultstring> Human-readable explanation of the fault <faultactor> Information about who caused the fault <detail> Application-specific error information related to the Body SOAP Fault Codes: Error Description VersionMismatch Invalid namespace for SOAP Envelope MustUnderstand Immediate child of Header with mustUnderstand="1" was not understood Client Message was incorrectly formed or contained incorrect information Server Problem with the server preventing message processing SOAP over HTTP SOAP requests are sent via HTTP requests; responses returned in HTTP response content. SOAP requests can use HTTP GET, but specification details focus on HTTP POST. HTTP requests and responses must set Content-Type to text/xml . Client must provide a SOAPAction header; its value depends on SOAP server implementation. Even if full header not required, client must send an empty string ( "" ) or null value for SOAPAction . SOAP responses via HTTP must follow HTTP status codes (e.g., 200 OK for success, 500 Internal Server Error for server error with Fault element). Example SOAP Request (GetStockPrice) POST /InStock HTTP/1.1 Host: www.example.org Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope/" soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding"> <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPrice> <m:StockName>IBM</m:StockName> </m:GetStockPrice> </soap:Body> </soap:Envelope> Example SOAP Response HTTP/1.1 200 OK Content-Type: application/soap+xml; charset=utf-8 Content-Length: nnn <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope/" soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding"> <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPriceResponse> <m:Price>34.5</m:Price> </m:GetStockPriceResponse> </soap:Body> </soap:Envelope> SOAP Communication Model Describes how to invoke Web services using SOAP. Defined by communication style and encoding style. Supports two styles: RPC (Remote Procedure Call) Document (or message) UDDI: Universal Description, Discovery, and Integration Cross-industry initiative for service registration and discovery. Provides a registry standard and facility for publishing/discovering Web services. Enables businesses to: Describe their business and services. Discover other businesses and their services. Integrate (interoperate) with other businesses. Designed for developer tools and applications using SOAP/XML and WSDL. Offers a global, platform-independent, open framework. A registry for relatively lightweight data, primarily providing network addresses for described resources. Core concept: UDDI business registration (an XML document describing business entity and its Web services). UDDI Business Registration Components "White pages": Address, contact, key points of contact. "Yellow pages": Classification by industrial taxonomies. "Green pages": Technical capabilities, service specifications, pointers to discovery mechanisms. Allows applications to determine who a business entity represents, what they do, where services are, and how they can be accessed. UDDI Main Characteristics Mechanism to categorize businesses and services using taxonomies. Service providers use taxonomies to indicate domain standards or geographic service areas. Uses standard taxonomies for discovery based on categorization. UDDI business registration is an XML document describing a business entity and its Web services. UDDI registry Service clients Industry consortia, standard bodies, service providers Service providers 1. Publish service type definitions 2. Build and publish services conforming to a service type definition 3. Find service type definitions and services based on various criteria 4. Get service type definition details 5. Invoke found services UDDI Queries Address: Finding Web services implementations based on common abstract interface definitions. Finding Web service providers classified by known schemes or identifier systems. Searching for services based on general keywords. Determining security and transport protocols supported by a Web service. Caching and updating technical information about a Web service at run-time. UDDI Data Structures Overview businessEntity: Information about the party publishing services. businessService: Descriptive information about a particular service. tModel: Descriptions of specifications for services or taxonomies; basis for technical fingerprints. bindingTemplate: Technical information about a service entry point and construction specifications. These contain references to tModels, designating interface specifications. publisherAssertion: Information about a relationship between two parties. Service Provider Information (UDDI XML Schema) Defines four core types for white/yellow/green page functions: business entities, business services, binding templates, and specifications (tModels). Specifies information about: The business entity ( <businessEntity> ). Services exposed by the business ( <businessService> ). Binding information ( <bindingTemplate> ) to use the service. <businessEntity> element and businessKey attribute: Core XML elements for publishing/discovering business info. <discoveryURLs> element: Optional, contains URLs for alternate Web-addressable discovery documents. <name> element: Common name of the organization; a <businessEntity> can have multiple names. <description> element: Short narrative description; can have multiple descriptions in different languages. <contacts> element: Optional list of contact information. <businessServices> element: Optional list describing logical families of services. <identifierBag> element: Information about enterprises and their services. <categoryBag> element: List of <keyedReference> structures for tagging business entities with classification info (industry, product, geographic codes). RESTful Web Services Lightweight, maintainable, and scalable service built on the REST architecture. Exposes API from applications in a secure, uniform, stateless manner. Calling client performs predefined operations using the RESTful service. Underlying protocol for REST is HTTP. REST: REpresentational State Transfer. RESTful Key Elements Resources: The core element. A resource is an object or data that can be accessed. Example: To access employee record 1 on http://demo.com , use http://demo.com/employee/1 . Request Verbs: Describe the action to perform on the resource. GET: Retrieves data (e.g., a browser issuing a GET for http://demo.com/employee/1 ). Other verbs: POST (create), PUT (update), DELETE . Request Headers: Additional instructions (e.g., response type, authorization). Request Body: Data sent with the request (e.g., in a POST request, the resource details to be added). Response Body: Main body of the response (e.g., an XML document with employee details). Response Status Codes: General codes returned with the response (e.g., 200 OK for no error). RESTful Methods POST: Create a new employee. GET: Get a list of all employees. PUT: Update an employee. DELETE: Delete an employee. Example: Employee Record with ID 1 POST: Not applicable (employee already exists). GET: Get details of employee with ID 1. PUT: Update details of employee with ID 1. DELETE: Delete details of employee with ID 1. Resource /Employee /Employee/1 POST Create Create a new employee GET Read Get All Employee details PUT Update Update relevant Employee details DELETE Delete Delete relevant Employee details RESTful Architecture Principles State and functionality divided into distributed resources: Every resource accessible via HTTP commands (GET, POST, PUT, DELETE). Client/server, stateless, layered, and supports caching: Client-server: Server hosts application, client is simple (e.g., web browser). Stateless: Application state not maintained across requests. No expectation for delete info to pass to next request after a DELETE. Example: REST API for Tutorials Tutorialid TutorialName 0 Arrays 1 Queues 2 Stacks RESTful Verbs Implementation: GET /Tutorial: Returns entire set of available Tutorials. GET /Tutorial/Tutorialid: Returns Tutorial name based on Tutorialid . POST /Tutorial/Tutorialname: Inserts a new Tutorialname into the collection. DELETE /Tutorial/Tutorialid: Deletes Tutorialname based on Tutorialid . Building Web Services with JAX-WS Java API for XML Web Services (JAX-WS). Technology for building web services and clients that communicate using XML. Allows developers to write message-oriented and RPC-oriented web services. Web service operation invocation represented by an XML-based protocol (e.g., SOAP). SOAP defines envelope structure, encoding rules, and conventions for invocations/responses. Calls and responses are transmitted as SOAP messages (XML files) over HTTP. Communication between a JAX-WS Web Service and a Client Client JAX-WS Runtime SOAP Message Web Service JAX-WS Runtime