Cloud Computing: Service-Oriented Architecture (SOA)

• Cloud Computing is a topic covered in Magistrale in informatica.

Service Oriented Architecture (SOA)

• It is an architectural model to provide services over the Internet.
• A service provides features and functions to independent clients.
• Each service should provide a description to be discovered and selected.
• Each service should provide access through well-known protocols.
• Each service should support composition to deliver complex solutions.
• Each service should address client's business needs and domain requirements.

Web Services Basic Architecture

• Consistent with established Service-Oriented Architecture (SOA) principles.
• Web Services Component consists of a service and service description
• Web service roles are service providers, service brokers and service requestors
• Web Services Operations: Publish, Find and Interact

Everything as a Service (XaaS)

• Traditional IT management involves managing applications, runtimes, security & integration, databases, servers, virtualization, server hardware, storage, and networking.
• Infrastructure as a Service (IaaS) has vendor managed server hardware, storage, and networking, with the rest managed by the user.
• Platform as a Service (PaaS) has vendor managed virtualization, server hardware, storage, and networking, with the rest managed by the user.
• Software as a Service (SaaS) has all levels managed by the vendor.

Web APIs

• Most of the existing services provide Web APIs.
• Web APIs use HTTP to tunnel procedure calls.
• Web APIs exhibit unknown semantics of both operations and data exchanged.

Establishing a Common Model

• Distributed systems must be based on a shared model.
• WSDL/SOAP traditional systems must agree on a common API.
• WSDL/SOAP SOA systems must agree on several messages.
• REST simplifies agreement, building around resources (nouns), operations (verbs), and content types (information representations).

Understanding REST

• REST = REpresentational State Transfer.
• REST is an architectural style for distributed systems.
• Architectural style has constraints that affect the roles/features and allowed relationships among architectural elements.
• It's an abstraction/design pattern to discuss architecture.
• Examples of styles include music (Jazz, Blues), building (Baroque, Bauhaus), and programming (object-oriented, functional, procedural).

REST Principles

• REST = REpresentational State Transfer.
• Resources are defined by URIs.
• Resources are manipulated through representations.
• Multiple representations can exist for a resource
• Messages are self-descriptive and stateless.
• Application state is driven by resource manipulations.
• Hypermedia controls application behavior.
• REST fits nicely with Web architectural components: URI & HTTP.

Representational State Transfer

• Key data abstraction is "The Resource".
• A resource is any information that can be named Documents, images, services, people, collections, etc.
• Resources have state that may change over time.
• Resources have identifiers (constraint).
• A resource should be important enough to be referenced.
• Resources expose a uniform interface (constraint).
• It simplifies system architecture and improves visibility.
• It encourages independent evolvability of implementations.
• On request, a resource can transfer a representation of its state to a client.
• It requires client-server architecture (constraint).
• A client can send a proposed representation to a resource.
• Resources are manipulated through representations (constraint).
• Representations returned from servers link to application state, allowing clients to follow links and assume a new state.
• Hypermedia is the engine of application state (constraint):
• Implies that each client-to-server request contains all info to understand the request and cannot use stored context.
• Standard media types, meta-data and control-data are used.
• Uniform interface + Stateless + Self-descriptive = Cacheable (constraint).
• Cacheable necessitates a layered-system (constraint).

Summary of REST Constraints

• Client-Server enables separation of concerns, simplicity, scalability, and evolvability.
• Statelessness enables scalability, reliability and visibility
• Cacheable property enables scalability and performance.
• Uniform Interface allows for simplicity, evolvability and visibility.
• Layered System enhances scalability, security and legacy integration.
• Identification of Resources has simplicity and scalability if required by uniform interface
• Manipulation via representation enhances the Evolvability if Required by uniform interface
• Self-descriptive messages are required by stateless, cacheable, uniform interface, and layered system
• Hypermedia as the engine of application state enables scalability, reliability, evolvability, performance, and the uniform interface

Why have Constraints

• Distributed systems must be based on a shared model
• "There are irreconcilable differences between local and distributed computing"
• The Eight Fallacies of Network Programming:
  • The network is reliable
  • Latency is zero
  • Bandwidth is infinite
  • The network is secure
  • Topology doesn't change
  • There is one administrator
  • Transport cost is zero
  • The network is homogeneous
  • The constrained systems emphasize simplicity and awareness of the system's contect
  • Constraints are the realization of design goals.
  • Unconstrained distributed systems are difficult to use, brittle, unreliable, and of marginal utility

REST: The Answer

• REST is a coordinated set of architectural constraints that attempts to minimize latency and network communication while maximizing independence and scalability of component implementations.
• The caching and reuse of interactions, dynamic substitutability of components, and processing of actions by intermediaries, thereby meets the needs of internet scale distributed hypermedia system.

REST Claims

• REST is simplicity
• Caching improves response time and reduces server load
• Less communication state enables easier load balancing between servers
• Less specialized software can exist because the underlying technologies are simpler
• Identification is done using standard mechanisms, no additional names necessary
• The principles emphasizes the correct and complete use of HTTP protocol to publish services on the Web
• REST over HTTP provides lightweight and layered mechanisms for data and service integration
• REST with HTTP protocol provides a distributed, hypermedia-driven application platform

Conclusions

• REST defines a set of constraints for distributed systems that achieve:
  • Simplicity
  • Scalability
  • Modifiability
  • Performance
  • Visibility (to monitoring)
  • Portability
  • Reliability
• A system that exhibits all defined constraints is RESTful.
• Systems can add or relax constraints but may be more/less RESTful after.
• REST is a style, not laws or specifications

Using HTTP to Build Applications

• Standard protocols involved:
  • HTTP 1.1 aka RFC 2616 or URIs: RFC 3986
  • Media Types (multiple RFCs, IANA)
  • MIME: RFCs 2045/2046

Using HTTP to Build REST applications

• What HTTP is not:
  • Inevitable
  • Archaic
  • Poorly Designed
  • Something to be suffered through
  • A transport protocol
  • The answer to everything
• What HTTP is:
  • Purposefully Designed
  • REST conformant
  • Frequently abused
  • Wildly successful
  • An application protocol

HTTP: A Recap

• Stateless, client/server, request/response application protocol.
• Clients request information, servers respond.
• Clients use four main operations (uniform interface)
  • GET, POST, PUT, DELETE
• HTTP Requests are sent to an addressable URI
• Requests/Responses are envelopes
• Headers are followed by a resource - if any (self-descriptive).

Format of http Messages

• Same format for request and response
• Human readable characters

HTTP Requests

• HTTP requests contain a request line structured in a specific format.
• HTTP requests set a host name.
• May state what type of connections or agent is available.
• It may also express which languages are permitted

HTTP Response

• Responses contain connection information
• The type of server
• A date and the last modified data
• It also states the size and type of sent data

Anatomy of HTTP Get

• The request line contains GET, POST and HEAD methods
• The request line is the status line that contains protocol, status code, and status phrase.
• There are also headers that contain request, response, general and entity types.

The REST Recipe for building REST applications

• Find all the nouns
• Define the formats
• Pick the operations
• Highlight exceptional status codes

Find all the nouns

• Everything in a RESTful system is a resource
• Every resource has a URI
• URIs should be descriptive
• URIs should be opaque
• URIs should be cool

Using HTTP to Build REST Applications Considerations

• Use path variables to encode hierarchies.
• Use other punctuations to avoid implying hierarchies.
• Use query variables to imply inputs into algorithms.
• URIs with query variables are often ignored by caches.
• URI space is infinite but URI length is limited to ~ 4K.
• Do not leak platform information.

Sample Web API Design

• Sample Application with a simple expense reporting system
• There should be Web APIs
• It needs to allow to create, edit and delete
• There should be different views on the data
• Users should be able to authenticate
• User shouldn't considered as resources
• Authentication should be possible

Sample Application for web API: resources (not an exhaustive list)

• Bill's Expense Reports: /users/bill/expenses
• Expense Report Number: /users/bill/expenses/123
• All expense reports: /expenses/
• Pending expense reports: /expenses;pending
• Bill's pending expense reports: /users/bill/expenses;pending
• Expense 123's line items: /users/bill/expenses/123/line_items
• Link item 2 of Expense 123: /users/bill/expenses/123/line_items/2
• 2006 Expenses: /2006/expenses/
• 2006 Open Expenses: /2006/expenses;submitted

HTTP Operations

HTTP has a constrained user interface (set of verbs/operations/methods)

• GET
• POST
• PUT
• DELETE
• HEAD OPTIONS (not widely supported)
• TRACE (not significant)
• CONNECT (not significant)
• All will support GET

HTTP Methods

PUT vs POST

• When creating new resources, Use POST if the server chooses the URI.
• Use PUT if the client chooses the URI.
• POST does "something" and returns "something" (Usually masking an RPC call, or "overloaded POST")
• Don't use casually (process this" POST sometimes valuable
• Resource factories is an example of something that are valuable to POST
• Sometimes you just want a verb
• Reexamine you design to see if it can´t retrieved with GET
• You get it out of a design Jam

HTTP Response Status Codes

The response status code is generated by the server to indicate the outcome of a request. The status code is a 3-digit number:

• 1xx (Informational): Request received; server is continuing the process.
• 2xx (Success): The request was successfully received, understood, accepted and serviced.
• 3xx (Redirection): Further action must be taken in order to complete the request.
• 4xx (Client Error): The request contains bad syntax or cannot be understood.
• 5xx (Server Error): The server failed to fulfill an apparently valis request. Proper identification of status codes associated with a request is a crucial decision in REST development

Web API Sample Application

Below are the Methods, Business Operations and Return codes

URI | Method | Business Operation | Return Codes

• -- | --- | --- | --- /users/{uname}/expenses | POST | Create new expense header | 201, 400, 409, 404, 415, 405 /users/{uname}/expenses/{rep_id} | POST, PUT, DELETE | Add line items, Update expense header, Delete expense header and line items | 201, 400, 409, 404, 415 /users/{uname}/expenses/{rep_id}/line_items/{item_id} | PUT, DELETE | Update line item Delete line item | 204, 400, 409, 404, 415, 405

Content Negotiation

• A single resource can have multiple representations
  • XML
  • PNG
  • JSON, etc. English, Japanese, etc.
• Client can ask for a particular representations via request headers Accept: text/xml Content Negotiation doesn't work in practice
• Most clients don't expose a means to set Accept headers
• Some clients don't support Accept headers at all Best Practice:
• Use Accept headers and expose the content type in the URI http://expenses.example.com/123.xml http://expenses.example.com/123.xhtml http://expenses.example.com/123.json Dots preferred over slashes: http://expenses.example.com/123/xml

Defining data formats

• Neighter HTTP nor REST mandate a single representation for data
• A resource may have multiple representations -XML, JSON, binary, name/value pairs
• Schema Languages are not required (if even possible)
• Representations should be well-knowne media types (IANA registered MIME types) Try and user "ump-stack" media types
• Make you resources maximally accessible JSON instead of lower lebel binary formats like Protocol Buffers or MessagePack
• XHTML instread of vanilla XML You won't always be able to do this, but you should try

Using "up-stack" media types can have several advantages:

• Higher level media types can be more widely understood inter preted by different clients and servers.
• They are often based standards designed for human readability.
• Debugging is easier due to the humean-readable format.
• Information included types makes it easer to understand for its purpose.
• By abstracting away lower level simplicity the impilmenttion complexity is reduce More documented

XHTML

• XML parseable.
• More accessible.
• Has useful constructs.
• Graceful degradation from the client.
• Attributes provide the necessary value.
• Consider honoring stylesheets, browsers, and otherwise.

Sample Application with Web API: defining formats

• Expenses (a collection of Expense Reports):
• Will be presented as a list
• Summary data: report id, submitter, total status, link to details.
• Needs a format that presents a list of links.

Better Formats for APIs

• Even better (tables are understood by spreadsheets)
• More on formats
• Extends XHTML to give semantic meaning to HTML tags.
• Extensions done with certain attributes:
  • i.e class, rel, rev
• Formal microformats exist: http://microformats.org/ geo: latitude and longitude hCard: contact information a dozen more
• Often contrasted with the Semantic Web: RDF/OWL simpler leverages existing content
• Strongly encouraged to use XHTML
• representations with official or custom microformats. Example: GeoRSS

HTTP to built REST Applications

• Define the formats straight in XML
• A simple expense item and simple expense report

Caching to built REST Applications

• Caching reduced latency and network traffic
• Only non-SSL GET is cached
• Two kinds of caches Browser (user agent) Proxe
• Lachish sit Really should use a caching proge You may and not even know it Remember there can be cases All Long dewe

Cache control Header

• Expies =HTTP date Hold tall expiry
• Cache-Control: hold for the amount of time
• Cache_Control: Max age = second
• Cache Control: proxy public = Cacheable even If authentication is required
• Cache Control: public
• Don't store the cache - no cache Control Validate

Use Conditional GET's to built rest application

• Give a resouce for the client

Asynchronouse operationes using HTTP

• Example processing A check (queue)
• The Cut process request an espense(job)
• Is expose throw Queue API

Designing REST APIs to poll job queue

• Poll job resource for status, using GET

REST Service characteristics

• The web it's self is amazingly open, Scalable extensible and easy to undersrand, so take advantage.
• openness allows new technologies to be introduced
• Scaleblitty ensures that the system does not contain Bottlenecks
• extensibility allows the Web to evolve without any redesign of existing parts.
• It Simplicity makes sure that the system survives and evolves.

Web Services

-Web serves provide servcies that can uploaded and subbmited to the API

• To handle complex iteractions for Web serveices more operations may Be requried

• Example authoring HTTP methods to do define additional functions for data transferal.

• Use to built resources and make application in RESTful Way

• Resource must identified by URIs and used.

State: Representing application information and memory

• Stateful data should not be made specific on the connections, but rather transfreed as client information to be processed by the API
• It Loose couplings for API reduce the need to store API information

State of data

• Each resouce request happens in isolation. So applications must maintain there state
• API Should not rely on user requst to mainit the state, it most use API for handling the state

Statelessness

• The applition should be load-balanced

Commin of Rest

• There common REST apicactions That is a reimplement implementation
• Htppermedia
• The data must been
• The nouns should all Be based on the current on Load
• REST is be defined in the following elements
• Content types
• the REST should be be to semantic

Hypermedia to build RestApis

• hyper media application should be the engine of application
• servers shiuold must maintain resource state
• following a lick is a data transation
• the clien be allowed to used it own state
• there should a guides for client of data.

Clients APIs

• -clients should one provide links the provide to there server
• Links Must Be
• classified
• the the points will also allow the loss couplings between client and servers.
• exmamples in diffrent versions and formats.

Should only follow links provided by the server or built via forms

• Links classified to know where the link points

• Helps to loosen couplings

• Media to send

• Must also to see this

• The hyperMedia representation is the interface

• the link must has been of the current

• If is of

Explore Service-Oriented Architecture (SOA) and its role in cloud computing. Understand web services architecture, including service providers, brokers, and requestors. Learn about the concept of Everything as a Service (XaaS).