SOA

4.1.1 - Introduction to SOA

- 2 components: service requester (request) and service provider (fulfill the request). Similar to client and server - We have service-oriented life (car service, meal service, laundry service). - 2 type of services: within an organization (internal, cost tracking) or on the web (external, trip budgeting).

4.2.1 - Web services

- A service is some functionality that is exposed for use by other processes. In other words, a service has an interface that can be used by some service requester. A web service then is functionality that is exposed and accessible using web technologies. - A web service as a software system designed to support inter-operable machine to machine interaction over a network. - First generation of web services relies on WDSL (how to interact, description), SOAP (do the interaction), and UDDI (published by service providers). They allow for webservices to be invoked by service (SOAP), to describe themselves ( WDSL), and to be published registries where they can be discovered (UDDI). - Composite services are services that are built with other services, which can either be composites themselves, or basic. A basic service does not rely on other services. The act of combining services into new services is called service composition.

4.1.6 - Request methods

- Get - Put: /questions/<new_question> ok, added a note to the 'new_question', can just call directly to the newly created resource URI, idempotent = can be called multiple time, always get the same result - Post: /questions/<new_question> error, not idempotent - Delete

4.1.5 - HTML, XML, JSON

- HTML and XML: markup languages based on tagging text. HTML is used to structure the text on web pages to be rendered appropriately in web browsers. XML is used to structure data or messages - JSON is used to represent data as key-value pairs, which can be easily converted to and from Javascript objects

4.1.8 - Remote Procedure Call (RPC) - functional/procedural

- Heterogeneous environment: machine architecture or operating system maybe different between a client and server. - Middleware: a type of architecture used to facilitate communications of services available and requests for these services between two applications that are operating on environmentally different systems. Sits between client and server providing a common interface (similar to Mediator design pattern) - RPC: basis for modern day middleware using network technologies. Network connectivity is expected as new system is designed to be able to be connect to other system via network. RPC allows clients to invoke procedures that are implemented on a server - Distributed computing: a system architecture in which computers on a network are able to communicate and coordinate their actions by passing messages through the network - Tiered architecture: each (specialized) layer focusing on specific aspects of the overall system

4.1.6 - HTTP

- Hypertext is a document embedded with hyperlinks (link documents), which, when clicked, will take you to the intended document or resources. HTTP was designed to facilitate the use of hypertext and to support the communication of documents and resources (which are expressed in HTML) - HTTP: Hypertext Transfer Protocol, is a protocol that dictates how information, including hypertext, is transferred across the internet

4.1.4 - Web Systems Architecture

- Layers: a collection of components that work together toward a common purpose. use layers to identify hierarchies and restrict interaction between layers. Generally, lower layers provide services to higher layers above them. - Layered system are conceptually organized into presentation -> application -> data tiers. In web app, presentation has 2 tiers: web browser -> web server

4.1.3 - Web Systems Evolution

- Static vs Dynamic webpages: static pages are stored on the web server while dynamic pages are built by the web server when they are requested - Web application and web services communicate over the web using open standards like HTTP, XML, and JSON which are easy for machines to manipulate - The request and response of these services is asynchronous, meaning that the logic is designed to continue running instead of waiting for a response. This way, the rest of the page can be generated while the individual services are processing the requests and sending responses

4.1.6 HTTP - URI vs URL

- URI: Universal Resource Identifier and its subset URL: Universal Resource Locator. URIs identify and URLs locate; however, locators are also identifiers, so every URL is also a URI, but there are URIs which are not URLs. http://etsy.com:80/user/fav/hat.png - protocol: HTTP - hostname: etsy.com - TCP port: 80 (optional) - location of resource on host machine: user/fav - resource: hat.png Browser can either resolve the IP address (already know IP address corresponding to the host name, or, if it doesn't know, it will query DNS, Domain Name System, server to find out.

API vs Web Service

1. All Web services are APIs but all APIs are not Web services. 2. Web services might not perform all the operations that an API would perform. 3. A Web service uses only three styles of use: SOAP, REST and XML-RPC for communication whereas API may use any style for communication. 4. A Web service always needs a network for its operation whereas an API doesn't need a network for its operation. 5. An API facilitates interfacing directly with an application whereas a Web service is a

4.3.1 - Rest characteristic by 5 constaints

1. REST is a client-server architecture which applies separation of concerns by having roles with specific responsibilities, the client (user interface to access services) and server (provide services such as creating and manipulating data), which interact with each other. Highly scalable 2. REST is a layered system. It can consist of multiple architectural layers of software or hardware called by the client and server. This helps improving performance, translate messages, re-usability of REST web services 3. Interaction must be stateless. Server does not save information about current client state or previous request. Client must send everything every time (ie. authentication). Improve performance of web services 4. Client can cache: client can keep a local copy of a server response to use for later requests. This again improves performance and reduce number of requests for the same resources 5. Uniform interface for communication between server and client: 1. REST use common HTTP methods: GET, PUT, POST, and DELETE. 2. The resource must be identified in the request using specific URI. 3. The representations of the resources are uniform

4.2.2 - 4 basic message patterns

1. Request-response pattern: synchronous, requester first sends a message then receives a reply from the provider 2. Solicit-response pattern: synchronous, provider instead makes a request to the requester, often called confirmation 3. One-way communication pattern: asynchronous, requester sends a request to the provider but no response is needed 4. Notification pattern: provider sends a notification to the requester without expecting a response

4.1.6 - HTTP - TCP vs UDP

HTTP is built on top of TCP, Transmission Control Protocol which allow reliable, ordered, connection-oriented communication. HTTP messages are sent and received through TCP ports (default is 80). UDP, User Datagram Protocol, is used primarily for establishing low-latency and loss-tolerating connections (speed) between applications on the internet. When a client makes a request to a server, this opens a TCP connection between client and server for them to communicate

4.1.6 - Url Encoding

HTTP limits number of characters in request URIs, request queries, and request response to ASCII, so special or unicode characters must be encoded using '%' and 2 character hexadecimal encoding

4.1.6 - HTTP Request and Response

HTTP request consists of: - Request line: request method, request URI, protocol - Headers: 2 mandatory host header (domain or IP address of host) and accept header (specify accepted response for the request). If message body is present, content length header and content type header must be included - A blank line - Message body (optional): can be HTML documents, json, parameters HTTP response consists of: - Status line: HTTP version, HTTP status code to show status of the request - Headers: including content length header and content type header - A blank line - Message body (optional): can be HTML documents, json, parameters

4.3.3 - Introduction to Microservices

Microservice can be thought of as a variation of SOA. Microservice architectural style is the way of composing microservices to produce complex application. A microservice is the process that is responsible for performing a single independent task (ie. search feature, recommendation feature). Benefit of microservices: 1. independent of the implementation allows it to use language, framework, and architecture that is best suited to the service: allow dev to create microservice using appropriate tool, allow dev to try out new technologies 2. easier to scale due to lose coupling. Each microservice can be replicated to allow parallel processing in distributed computing 3. more resilient to failure by replication 4. can be scaled independently as not all services needed to be scaled at the same rate 5. allow to be developed quickly and maintained by small team 6. ms can be local, remote, or both Cons: 1. Some centralized management of all microservices will be required to coordinate all the microservices as distributed system enabled asynchronous communication. Databases will likely be distributed over multiple ms and transactions may span multiple ms. -> otherwise we will have inconsistent and error 2. Testing is complex due to changing test conditions. Difficult and hard to reproduce bugs due to complex interactions between ms 3. in case 1 ms fails, all other ms must be able to handle it gracefully Consider: 1. amount of communication that will be required between ms in an app as they have overhead cost 2. if passing data around ie. user authentication via cookie will introduce keeping track of these data in all services, cost

4.1.9 - Object brokers - CORBA - Object oriented

Object brokers combined the distributed computing aspects of remote procedure calls with object oriented design principles to allow distributed systems to use an object oriented approach. CORBA: Common Object Request Broker Architecture, set of standards, provide an outline of what should be included in object brokers: - independent of the programming languages used to implement clients and servers - should be able to function independent of the operating system CORBA has 3 main components: - Object request broker: provides object interoperability to the client and the server - corba services: these are services provided by the middleware to the objects being used by the client and server. can be accessed via corba standardized API - corba facilities: provide services at an application level (high level functions)

4.1.8 - RPC

Original design of RPC consists of: - a client which is the caller, it is the component that is making the remote call - an interface definition language, IDL, which is the language through which the client and server communicate. Implemented first as it defines available procedures, input parameters, and returned response. - a server which is the callee, it is the component that implements the procedure that is being invoked - Synchronous (blocking) not Asynchronous Basic types of interfaces provided to make a remote procedure call are: procedure registration, procedure call, and procedure call by broadcast - Asynchronous system: clients do not need to wait for a server response before moving on to another task. This allows different components of a distributed system to work more independently of each other

4.3.2 - Designing REST service

Practices for design good REST API: 1- use only nouns for your URI (/students, /students/sid NOT /student/getSid -> verb) 2- GET method should not alter the state of your resources 3- use plural nouns for your URI, sticking to a singular way is good 4- use sub-resources for relationships between resources (/students/3/courses -> get all courses of student 3) 5- use HTTP header to specify input/output format (content-type and accept) 6- provide option for filtering and paging via adding query string after ? (/courses?department=cs&offset=3&limit=10) 7- version your API - (api.service.com/v2/students/3/courses) 8- provide proper HTTP status code (201 new resource successfully created, 204 resource successfully deleted)

4.3.1 - Introduction to REST

REST: REpresentational State Transfer, using HTTP to send messages to communicate between components, is a client-server architecture based on a request-response pattern. - Resource: any piece of information that is self-contained, ie. documents, images, object representations. Written in 3 specific ways: XML, JSON, or Simple Text - Communication is resource based, means messages are sent as representations of resources.

4.1.6 - HTTP Request stateless

Relationship between requests are not preserved. HTTP protocol does not aware if the same client is making the request

4.2.2 - Service invocation (SOAP)

Service requesters and service providers communicate with each other in the form of XML messages. SOAP message is in XML format includes: Envelop (required), Header, Body (Required) 2 styles of SOAP messaging: document or RPC

4.1.2 - Principles of Services

Very similar to OOP: 1. Modular: must be independent, modular to other services for reuse purpose. Similar to Object in OOP only exposing relevant information to others 2. Composable: services must be able to combined with other services. Similar to combining objects in OOP to obtain desired behaviors 3. Language - Platform independent: service provider written in Java must be usable by service requester written in Python. Can be achieved by following standard protocols 4. Self-describing: must describe exactly what it is expecting and what is return. Using formal standard such as WSDL (Web Services Description Language). Similar to interfaces in OOP. 5. Self-advertising: internal organization can use catalog to list all services, distributed app can use formal language such as UDDI (Universal Description Discovery Integration) which is an XML-based standard for describing, publishing, and finding web services

Microservice Composition patterns

https://www.tutorialspoint.com/microservice_architecture/microservice_architecture_composition_patterns.htm http://blog.arungupta.me/microservice-design-patterns/ https://github.com/iluwatar/java-design-patterns/tree/master/aggregator-microservices/aggregator-service/src/main/java/com/iluwatar/aggregator/microservices 1. Aggregator 2. Proxy 3. Chain 4. Branch invokes mutually exclusive chains simultaneously 5. Shared Data 6. Asynchronous Messaging (message queue)