© Donald F. Ferguson, 2015. All rights reserved. Topics in Computer Science: COMS E6998-07-2015-03 Micro-service Application and API Development Lecture.

© Donald F. Ferguson, 2015. All rights reserved. Topics in Computer Science: COMS E6998-07-2015-03 Micro-service Application and API Development Lecture 6: Message Queues, Orchestration/Workflow, CAP/Dynamo DB Dr. Donald F. Ferguson Donald.F.Ferguson@gmail.com

3 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Content Housekeeping –Midterm student course evaluation and actions. –TLDS and project reviews. Diversion on some best practices: REST interface, MVC-AO/DO, Carelessness Context: 2 nd project overview Message Driven Processing –Asynchronous REST. –Message queues oververview and Message patterns. –Amazon SQS. Orchestration and workflow –Motivation. –BPMN oververview. –State machine model. –Amazon Simple Workflow overview. New database models –CAP Theorem –NoSQL –Amazon DynamoDB Discussion

4 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Housekeepin g

6 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Questions and Answers?

7 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Student Midterm Course Evals

8 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Midterm Student Course Evaluations

9 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Midterm Student Course Evaluations Write-in Comments Maybe it's better to focus more on material, rather than just student questions, in the class. One of the best courses at Columbia. The assignments are a little too open ended, and it seems like there are not right answers. That said, the lectures are very enjoyable and rewarding to attend and the coursework is very up to date. Students would benefit from a higher amount of workload. The projects needs to be less open ended and have clear and precise goals to achieve At this point of the semester, I have not been graded on any assignments so my required response regarding the grading process should be considered irrelevant. Regarding the assignment prompts, they could be more detailed, clear, and organized. For the past assignment, my team patched together deliverables from what was said in class, what was contained in the brief word document provided on courseworks, and from questions with the TA and Professor. We spent what we felt was an unreasonable amount of time figuring out what the assignment - not due to the complexity of the assignment, but because the assignment wasn't clearly defined - when we could have spent that time working on the assignment.

10 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Midterm Student Course Evaluations Write-in Comments Maybe it's better to focus more on material, rather than just student questions, in the class. One of the best courses at Columbia. The assignments are a little too open ended, and it seems like there are not right answers. That said, the lectures are very enjoyable and rewarding to attend and the coursework is very up to date. Students would benefit from a higher amount of workload. The projects needs to be less open ended and have clear and precise goals to achieve At this point of the semester, I have not been graded on any assignments so my required response regarding the grading process should be considered irrelevant. Regarding the assignment prompts, they could be more detailed, clear, and organized. For the past assignment, my team patched together deliverables from what was said in class, what was contained in the brief word document provided on courseworks, and from questions with the TA and Professor. We spent what we felt was an unreasonable amount of time figuring out what the assignment - not due to the complexity of the assignment, but because the assignment wasn't clearly defined - when we could have spent that time working on the assignment. Product development has three roles Product management – “What.” Product architecture – “How.” Product engineering – “Code it.” Ideally, The project definition/specification would fill the “What.” The teams would do the “How and Code it.” Unfortunately, in the “real world” for advanced projects The “what” is often very unclear. Architecture applies judgement, proposes an approach, and then asks, “Is this what you meant?” Which is one reason for thje Q&A approach.

11 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Midterm Student Course Evaluations

12 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Observations and Actions The ratings –Are pretty good –Median is consistently above 4 – Very Good. –Mean is consistenly around 4.3 –But, I typically do better than this (above 4.5). Comments –Clear request for more explicit, unambiguous definition of projects. –More emphasis on lecture material and less on Q&A, discussion. Actions –OK. Wilco. –But be careful what you ask for.

13 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Project Reviews

14 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction TLDS and Project Reviews TLDS –In general, pretty good. –All submitted TLDS should have grades. –We can discuss during office hours. My personally doing project reviews –Is a “mess.” –I wanted to cap my “Topics in Computer Science” course enrollment to 20 students. This would enable more small-team/one-on-one interaction. –The enrollments have gone from 20  40  60  90. You pay tuition and should get the classes you want. –I am looking at approximately 18 one hour project reviews, which is infeasible. –So, there is a new approach –I will publish review slots when I am available. –Teams can register 1 st come, 1 st served. –TAs will handle other reviews. –The format will be –Walk through the TLDS and TA comments. –Demo and walk through of some of the code.

15 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Setting the Content 2 nd Project Overview

16 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction 1 st Project: A Simple Scenario Course Info Microservice Manages Course Resource With a little bit of student info “inside” student resource 3 rd parties provide the micro-service  Cannot examine or modify code. Combine to provide a single microservice –Managing two resources: Student, Course –Existing apps will continue to use the existing microservices. –Referential integrity, e.g. deleting a student removes student from course. Student Info Microservice Manages Student Resource With a little bit of course info “inside” student resource Student Course

17 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction When you do not know how to do something, the most likely answer is build a microservice. Student CourseAPI GW StudentCourse Integrat e

18 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction 2 nd Project Overview Student CourseAPI GWIntegrateHS InfoFinanceWorkflow 1. 2. 3. 4.

19 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction 2 nd Project Overview New workflow and orchestration microservice –REST CRUD for Student resource. –Uses orchestration to map CRUD on student to CRUD on –Original StudentInfo microservice. –Original CourseInfo microservice. –External, global service with basic information on all K-12 and university students. –New FinanceInfo microservice that tracks students’ tuition, fees and payments. New microservice with core information about all K-12 and university students, and used by all K-12 and universities in the US. –The dataset is extremely large with frequent updates. –The data manipulation operations are relatively simple. –  Use Amazon DynamoDB New FinancialInfo microservice. –Some core student data + some basic tuition/fees data. –If you did the original StudentInfo service properly, this is just a schema modification to the code. All inter-microservice communication uses Amazon SQS.

21 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Message Driven Processing

22 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Asynchronou s Operations

23 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction REST Implementations Call REST Services Cart Functions Java SQLite Recommendation Functions Node.js Redis Catalog Functions PDP MongoDB XXX MMM NNN Content Functions Ruby Amazon S3

24 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Synchronous Integration

25 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Synchronous and Asynchronous HTTP operations are inherently synchronous –Connect –Verb –Response –Disconnect The implementation of the operation may “take a while,” –A calls B before returning. B calls C and D before returning to A. … –The implementation may be computationally or data intensive. –Something in the implementation may operate at “people speed,” e.g. –Creating an Account may require. –Manual approval by “Dave.” Holding open connections can cause problems –A server typically has an upper limit on open connections. Holding a connection for long requests will cause some client calls to “get a busy signal.” –A connection is more likely to break the longer it is open. A call graph of “long” connections is inherently fragile. One breaks and the whole thing breaks.

26 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Asynchronous Operation This is going to “take a while.” So, I am going to Tell you that your request looks OK. Acknowledge that I am working on it. Give you a URL on which you can poll with GET for the answer

27 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Implementation Observations Define a collection /QueuedResponses –A client can call …/QueuedResponses/21 to get a specific response. –You already know how to do this for …/staff, …/stores –The data format in the table is {id, status, JSONString}, where JSONString is the response you would have received for a synchronous request. A simple implementation would be writing a façade –Accept request –Create new table entry with status = “in progress” –Return 202 and URL –Call the actual implementation –Update the database table entry with the JSON result Most application platforms have middleware approaches to support registering callbacks, threads, etc. The implementation would typically –Invoke some long running action, e.g. DB query, workflow process and register a callback –The callback implementation updates the entry in the response table.

28 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Message Driven Processing

29 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Message Queue Service Pattern Point-to-Point communication between modules becomes fragile at scale Adding modules P and Q requires finding and configuring all senders. I want to send M to any one of X1, X2 and X3, but only one. I want to make sure that someone processes M but do not want to hold the transaction until I get a response (I may not even need the response). My destinations are not “up” at the same times I am. A B X Y Z Anti-Pattern Best Practice Pattern

30 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Message Exchange Patterns

31 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Why Would I Use a Queue http://www.javacodegeeks.com/2013/06/working-with-amazon-simple-queue-service-using-java.html is one example) http://www.javacodegeeks.com/2013/06/working-with-amazon-simple-queue-service-using-java.html Flow control –My server may be able to process 100 reqs/second –There are thousands of clients –The aggregate rate could be 10 req/s or 300 req/s –Without a queue, clients would get connect failures under load The request is going to take a long time –Image reformatting and tagging –I cannot have my code “wait” for a response –And I do not want to write a lot of “Is it done yet?” calls I do not know (or care) which one implements the logic –I have 5 – 10 image processors for GIFs –I have 7 – 10 processors for.wav files –I do not want to know which ones are active, when and processing what. –I just want to put the “thing in a queue” knowing that someone will eventually pick it up. Think “email” for API calls

32 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Amazon SQS

33 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Amazon SQS (I) Selected “Send Msg”

34 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Amazon SQS (I)

35 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Amazon SQS (III)

36 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Amazon SQS (IV)

37 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Amazon SQS (V)

38 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Amazon SQS (VI)

39 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Project 2 Implications

40 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Project 2 Impliications Each microservice has two “channels” –An HTTP URL for REST –A pair of SQS Queues (URLs) –Request message –Response message The microservice has a “thing” that –Listens on the InputQ. –Gets the next message. –Calls the application logic. –Puts the resoonse on the ResponseQ. “Calling” a microservice is –Put a message on the InputQ. –Periodically check the ResponseQ. Student REST SQS InputQ ResponseQ

41 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Workflow and Orchestration

42 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Introduction, Context, Classic Business Process Modeling

43 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Composition Models (and Diagrams) The diagrams are always “nodes” and “arcs.” Structure: node A node B, where x is Requires/depends/calls/synchronizes with/… Control: –Execute A and then execute B, where A and B are tasks. –There is a shared set of “data objects” the tasks manipulate. Data flow: Do A to the message/document/… and then do B to A’s output Control FlowStructureData Flow

44 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction A flowchart is a type of diagram that represents an algorithm, workflow or process, showing the steps as boxes of various kinds, and their order by connecting them with arrows. This diagrammatic representation illustrates a solution model to a given problem. diagramalgorithmproblem Action/Task Decision/ Control

45 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Workflow Diagram

46 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction And You can Define Complex Processes

47 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Flowcharts, Programming and Workflow We “old people” learned to develop software by –Doing flowcharts with pencil and paper. –Review and discuss the flowchart with the team. –Convert the flowchart into code –Activities –Implementation was a subroutine. –Implementation in flowchart was to call subroutine. –Decision mapped to “if … then.. else …,” “while … do …,” etc. The approach became slow, redious and redundant as more modern programming languages and tools evolved. We discovered –The concept was not useful for “programming in the small,” e.g. implementing a microservice. –But was useful for implementing a complex, long running, asynchronous element that called a bunch of microservices/services.

48 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Overall Concepts Service A Service B P P

49 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Motivation Iterative design and refinement –Business professionals and programmers collaborate to solve a problem. –Business professionals may lack time or skill to read code. –But, the professionals can understand BPMN diagrams. Programmer agility –We repeatedly see a pattern in which –A higher level language (domain specific language) emerges, e.g. SQL, HTML, … –Supported by a WYSYWG tool for programming. –BPM(N) is the model applied to control flow composition. Change agility –The business process is a document, interpreted by an engine. –Modifying the process is simply “editing” the document. –Which is more agile than compiling code, rebuilding library, pushing out jar file, … The process –Is typically very long lived (human tasks, complex computations, invoke remote services, …) –Availability, scalability, etc. requires persisting the state between steps. –Which is complicated, tedious programming. –The “engine” handles the state management, persistence, …

50 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Amazon Simple Workflow

51 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Equivalent State Machine Model The workflow specification is logically a set of statements of the form If (I am in state == S1) AND (the incoming event message == E2) then –Send message/invoke REST API …/… –Set current state to S31 This is the Amazon Simple Workflow Model. Why did they choose this model? –Preference? I have seen teams that like Process and hate State and vice-versa. –More appealing to people incrementally evolving to workflow from hacking together solutions from microservices. –The engine in simpler with less abstractions/semantics  greater scalability. Process Diagram {S1, Event, Action, S2} { … … … } State Machine

53 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Application Structure Role of the Activities Worker: The activities worker performs the various tasks that the workflow must accomplish. It consists of: –The activities implementation, which includes of a set of activity methods that perform particular tasks for the workflow. –An activity worker, which uses HTTP long poll requests to poll Amazon SWF for activity tasks. When a task is available, Amazon SWF responds to the request by sending the information required to perform the task. The activity worker then calls the appropriate activity method, and returns the results to Amazon SWF. Role of the Workflow Worker: The workflow worker orchestrates the execution of the various activities, manages data flow, and handles failed activities. It consists of: –The workflow implementation, which includes the activity orchestration logic, handles failed activities, and so on. –An activities client, which serves as a proxy for the activities worker and enables the workflow worker to schedule activities to be executed asynchronously. –A workflow worker object, which uses HTTP long poll requests to poll Amazon SWF for decision tasks. If there are tasks on the workflow task list, Amazon SWF responds to the request by returning the information that is required to perform the task. The framework then executes the workflow to perform the task and returns the results to Amazon SWF.

54 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction New Databases

56 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction How to Think about BPM There are a set of “commands/verbs” –Call this API –Put X in this database –Compute this value –… … Wrap these with a plug-in adaptor, which in Activiti occurs through –Service task enablement by –Implementing org.activity.engine.delegate.JavaDelegate interface. –Interacts with the with the process/process engine by –Setting process variables; calling other APIs on DelegateExecution –Calling APIs on the process engine. –Assigning to a person/role that 1) Performs a task, 2) Fills out a form that updates process variables. Assemble the “verbs” into a sentence using BPMN Define the commands and verbs either “bottom-up” through inventory analysis or “top-down” from the process models and definitions.

57 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Activiti Structure Business applications with user interfaces. Callable web service/REST service implementing control and form functions. A “default” application for defining processes, viewing/managing the execution of processes and assigning tasks/forms to people.

59 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Topics Message driven processing; Amazon SQS Topic space + Event mediations DynamoDB Amazon Simple Workflow/BPMN Etags and optimistic transactions CAP theorem and databases

61 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Contents Questions and discussion –Synchronous update and orchestration motivation. –“Should I use ZooKeeper/Kubernetes?” –Z-scaling versus database sharding. –Schema changes violating referential integrity. –“Isn’t writing state change to logs a security exposure?” –“How big should a microservice be?” –Z-Scaling versus DB shards. –Schema update and data model corruption. 12 Factor Application –Overview and perspective. –Implications for projects. Orchestration/Workflow/Message Queues –Concepts illustrated with BPMN. –State machine approach and Amazon Simple Workflow Service. –Project #2. Introduction to Web application security.

62 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Questions and Discussion

63 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Synchronous Integration

64 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Synchronous Integration State based workflow will go here.

65 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Kubernetes, Mesos, ZooKeeper, … Logical scalable and HA single image. Control and management functions.

66 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Kubernetes and Docker Deploy and manage to Master Master transparently deploys to Minions

67 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Kubernetes

68 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Kubernetes, Mesos, ZooKeeper, … The technologies emerged to support –A large infrastructure of simple, commodity hardware enabling containers. – Running a very large number of dynamic microservices –Number of types of microservices. –Number of clones of a microservice type. –Microservice type deploy, and instance start, stop, restart, move, … The technologies are –Extremely relevant to microservices and APIs –Continuous development: Develop  unit test->QA  Deployment. –Scalable, available deployment and delivery. –But, using in class projects is difficult because they “require” scalable infrastructure. –I am explaining concepts and trying to figure out how to give hands-on experience. The technology is related to API Management/GWs, but –Kubernetes et al. primary focus on HW and container layer and are application semantics unaware. –While API Management and API GW operate as infrastructure extensions at the application and API layer.

69 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Student Submitted Question “Sysadmins, programmers and others access ‘logs’ for problem resolution, debugging, etc. These roles should not have access to sensitive business and customer information. Isn’t logging resource state changes a security exposure?” A very good question. –Logging sensitive data to admin/programmer accessible files/logs would be a very serious security exposure. –Shared, unsecured logs with sensitive data WILL cause data theft. –Many government and industry regulations explicitly preclude sharing sensitive data in things like logs. –I used “log” and “feed” as metaphors or analogies. I do not use the terms in a literal manner. –Almost all commercial data processing systems record and save business data state changes, e.g. –Backup and recovery. –Regulatory and legal compliance requires knowing what the data “used to be.” –Business intelligence and analytics often focuses on the evolution of data. –These “logs” are not /etc/syslog. The “logs” are themselves mission critical, sensitive business information. The information is a logical extension of the “current” state of the resource, is itself a resource and is protected like any other resource. –Propagating the “log” to an observing system is also very common. –Disaster recovery and backup. –Continuous load of a business data warehouse. –Legal and business compliance “write only” system.

70 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction An Example and Implications An insurance company resolving a complaint about a car insurance rate needs to know –Basic scenario –What color the car is now? –What color was the car when the rate was set? Cars change color. –Moreover, when did I come to know that the car changed color? The customer may have forgotten to tell me at the time. –Some systems maintain resource history in two-dimensional time. –…/don/car/actualState/t: What color was the car at time t? –…/don/car/beliefState/t: What color did I think the car was at time t? –And the system sends state change events as secure, business data to other services. –Feed data warehouse to enable reports, e.g. “Common car colors in Illinois in 1972.” –Business intelligence/analytics systems, e.g. “Look for trends in car color evolution to potentially identify new rate plans.” –Operations, e.g. “Notify agent to contact customer to discuss rate change due to color change. Implications –The state history and emitted business events are themselves “resources” that must be secure. The current value is just a special case. –The “unanticipated composition enablement pattern” recommends the practice for all micro-services. The service “configure” SPI should enable turning on/off, selecting resource types, etc.

71 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Transaction Log Shipping/Data Warehouse Loading Data replication is extremely common –Scalability, multi-site, availability. –Read only “data warehouse” to keep complex query partitioned from interactive workloads. How do you replicate? –Historically, replication occurred through –Backups, extract-transform-load, batch jobs. –Increasing “event/message” based. –Increasingly occurring through “data state change” events for –Updating multiple, unanticipated systems. –More current data.

72 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Summary Resource managers “logging” and “propagating” state changes is common –Many business scenarios. –Many technology realizations, e.g. –Triggers  messages. –Transaction commit/redo log shipping and replay. –Extract-Transform-Load. –Inherent part of core data model for application requirements. –The information is another type of core, secure data and protected. The resource state change pattern to enable unanticipated information –Exposes the state changes as part of the resource data model. –Secured the same way the current state is. –Pattern for enabling replication and synchronization, similar to existing approaches, but aligned with REST, microservices, etc.

73 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Another Question “How big should a microservice be? Should student info and course info really be different microservices? etc.” Well, we are not the 1 st people to ask this question. Some answers are –“Small enough and no smaller.” –“Created by no more than a handful of people.” The next obvious question is, “How many people is a handful?” –Follow the single responsibility principle (https://en.wikipedia.org/wiki/Single_responsibility_principle).https://en.wikipedia.org/wiki/Single_responsibility_principle –Avoid splitting microservices if it causes data sharing, which is not the same thing as “data linking.” The web is all about linked data. My advice: Assume you have to manage resource types X and Y. –If someone is likely to want your X but someone else’s Y  2 microservices. –If there are several logical scenarios that cause X to change Y and vice versa  1 microservice. –The ideal SW development size is 7 people, +/- 3. If the microservice requires more than 12 developers, even if logically one “business service,” split for development agility. –Use common sense. Be able to explain your decision.

74 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Event Models: Push versus Pull There are two approaches to “notification.” 1.Pull: –The supplier records and stores notifications. –The consumer calls and requests notifications that match conditions, e.g. –Resource types –Time intervals 2.Push: –The consumer sends a subscribe message with a filter to the supplier. The message contains a callback URL. –For any change that matches the filter, the supplier calls all subscribed consumers. There are microservices (middleware) that will adapt between –Pull consumers and Push suppliers. –Pull suppliers and Push consumers. I recommended: 1) Pull supplier. 2) Push consumer. 3) Microservice that adapts, including formats.

75 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction 12 Factor Application http://12factor.net/

76 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Overview and Motivation Use declarative formats for setup automation, to minimize time and cost for new developers joining the project; Have a clean contract with the underlying operating system, offering maximum portability between execution environments; Are suitable for deployment on modern cloud platforms, obviating the need for servers and systems administration; Minimize divergence between development and production, enabling continuous deployment for maximum agility; And can scale up without significant changes to tooling, architecture, or development practices.

77 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction The 12 Factors I. Codebase One codebase tracked in revision control, many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment IV. Backing Services Treat backing services as attached resources V. Build, release, run Strictly separate build and run stages VI. Processes Execute the app as one or more stateless processes VII. Port binding Export services via port binding VIII. Concurrency Scale out via the process model IX. Disposability Maximize robustness with fast startup and graceful shutdown X. Dev/prod parity Keep development, staging, and production as similar as possible XI. LogsTreat logs as event streams XII. Admin processes Run admin/management tasks as one-off processes

78 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction I. Codebase

79 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction II. Dependencies Concept “A twelve-factor app never relies on implicit existence of system-wide packages. It declares all dependencies, completely and exactly, via a dependency declaration manifest. Furthermore, it uses a dependency isolation tool during execution to ensure that no implicit dependencies “leak in” from the surrounding system. The full and explicit dependency specification is applied uniformly to both production and development. For example, Gem Bundler for Ruby offers the Gemfile manifest format for dependency declaration and bundle execfor dependency isolation. In Python there are two separate tools for these steps – Pip is used for declaration and Virtualenvfor isolation. Even C has Autoconf for dependency declaration, and static linking can provide dependency isolation. No matter what the toolchain, dependency declaration and isolation must always be used together – only one or the other is not sufficient to satisfy twelve-factor.Gem BundlerPipVirtualenvAutoconf One benefit of explicit dependency declaration is that it simplifies setup for developers new to the app. The new developer can check out the app’s codebase onto their development machine, requiring only the language runtime and dependency manager installed as prerequisites. They will be able to set up everything needed to run the app’s code with a deterministicbuild command. For example, the build command for Ruby/Bundler is bundle install, while for Clojure/Leiningen it islein deps.Leiningen Twelve-factor apps also do not rely on the implicit existence of any system tools. Examples include shelling out to ImageMagick or curl. While these tools may exist on many or even most systems, there is no guarantee that they will exist on all systems where the app may run in the future, or whether the version found on a future system will be compatible with the app. If the app needs to shell out to a system tool, that tool should be vendored into the app.” Observations –This does not solve the problem of documenting service dependencies. –Docker packaging increasingly solves some of the system dependency issues.

80 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction III. Configuration An app’s config is everything that is likely to vary between deploys (staging, production, developer environments, etc). This includes:deploys Resource handles to the database, Memcached, and other backing servicesbacking services Credentials to external services such as Amazon S3 or Twitter Per-deploy values such as the canonical hostname for the deploy Apps sometimes store config as constants in the code. This is a violation of twelve-factor, which requires strict separation of config from code. Config varies substantially across deploys, code does not. Note that this definition of “config” does not include internal application config, such as config/routes.rb in Rails, or how code modules are connected in Spring. This type of config does not vary between deploys, and so is best done in the code.code modules are connectedSpring The twelve-factor app stores config in environment variables (often shortened to env vars or env). Env vars are easy to change between deploys without changing any code; unlike config files, there is little chance of them being checked into the code repo accidentally; and unlike custom config files, or other config mechanisms such as Java System Properties, they are a language- and OS-agnostic standard.

81 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction IV. Treat backing services as attached resources A backing service is any service the app consumes over the network as part of its normal operation. Examples include datastores (such as MySQL or CouchDB), messaging/queueing systems (such as RabbitMQ or Beanstalkd), SMTP services for outbound email (such as Postfix), and caching systems (such as Memcached).MySQLCouchDBRabbitMQBeanstalkdPostfixMemcached Backing services like the database are traditionally managed by the same systems administrators as the app’s runtime deploy. In addition to these locally-managed services, the app may also have services provided and managed by third parties. Examples include SMTP services (such as Postmark), metrics-gathering services (such as New Relic or Loggly), binary asset services (such as Amazon S3), and even API-accessible consumer services (such as Twitter, Google Maps, orLast.fm).PostmarkNew RelicLogglyAmazon S3TwitterGoogle MapsLast.fm The code for a twelve-factor app makes no distinction between local and third party services. To the app, both are attached resources, accessed via a URL or other locator/credentials stored in the config. A deploy of the twelve-factor app should be able to swap out a local MySQL database with one managed by a third party (such as Amazon RDS) without any changes to the app’s code. Likewise, a local SMTP server could be swapped with a third-party SMTP service (such as Postmark) without code changes. In both cases, only the resource handle in the config needs to change.configdeployAmazon RDS

82 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction IV. Backing Services Ideally –Backing services, even local backing services, export a Web callable/REST API. –If the backing service does not have a REST API, build an encapsulating (adaptor) microservice. –Clearly segregate data access services from business services.

83 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction V. Build, Release, Run A codebase is transformed into a (non-development) deploy through three stages:codebase –The build stage is a transform which converts a code repo into an executable bundle known as a build. Using a version of the code at a commit specified by the deployment process, the build stage fetches and vendors dependencies and compiles binaries and assets.dependencies –The release stage takes the build produced by the build stage and combines it with the deploy’s current config. The resulting release contains both the build and the config and is ready for immediate execution in the execution environment.config –The run stage (also known as “runtime”) runs the app in the execution environment, by launching some set of the app’sprocesses against a selected release.processes The twelve-factor app uses strict separation between the build, release, and run stages. For example, it is impossible to make changes to the code at runtime, since there is no way to propagate those changes back to the build stage. Every release should always have a unique release ID, such as a timestamp of the release (such as 2011-04-06-20:32:17) or an incrementing number (such as v100). Releases are an append-only ledger and a release cannot be mutated once it is created. Any change must create a new release.

84 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction V. Build, Release, Run

85 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction VI. Process The app is executed in the execution environment as one or more processes. In the simplest case, the code is a stand-alone script, the execution environment is a developer’s local laptop with an installed language runtime, and the process is launched via the command line (for example, python my_script.py). On the other end of the spectrum, a production deploy of a sophisticated app may use many process types, instantiated into zero or more running processes.process types, instantiated into zero or more running processes Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a statefulbacking service, typically a database.share-nothingbacking service The memory space or filesystem of the process can be used as a brief, single-transaction cache. The twelve-factor app never assumes that anything cached in memory or on disk will be available on a future request or job. Even when running only one process, a restart (triggered by code deploy, config change, or the execution environment relocating the process to a different physical location) will usually wipe out all local (e.g., memory and filesystem) state. Some web systems rely on “sticky sessions” – that is, caching user session data in memory of the app’s process and expecting future requests from the same visitor to be routed to the same process. Sticky sessions are a violation of twelve-factor and should never be used or relied upon. Session state data is a good candidate for a datastore that offers time-expiration, such asMemcached or Redis.“sticky sessions”MemcachedRedis

86 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction VII. Port Binding Export services via port binding Web apps are sometimes executed inside a webserver container. For example, PHP apps might run as a module insideApache HTTPD, or Java apps might run inside Tomcat.Apache HTTPDTomcat The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port. In a local development environment, the developer visits a service URL like http://localhost:5000/ to access the service exported by their app. In deployment, a routing layer handles routing requests from a public-facing hostname to the port-bound web processes. This is typically implemented by using dependency declaration to add a webserver library to the app, such as Tornado for Python, Thin for Ruby, or Jetty for Java and other JVM-based languages. This happens entirely in user space, that is, within the app’s code. The contract with the execution environment is binding to a port to serve requests.dependency declarationTornadoThinJetty

87 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction VIII. Concurrency Scale out via the process model

88 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction IX. Disposability Maximize robustness with fast startup and graceful shutdown The twelve-factor app’s processes are disposable, meaning they can be started or stopped at a moment’s notice. This facilitates fast elastic scaling, rapid deployment of code or config changes, and robustness of production deploys.processescodeconfig Processes should strive to minimize startup time. Ideally, a process takes a few seconds from the time the launch command is executed until the process is up and ready to receive requests or jobs. Processes shut down gracefully when they receive a SIGTERM signal from the process manager. For a web process, graceful shutdown is achieved by ceasing to listen on the service port (thereby refusing any new requests), allowing any current requests to finish, and then exiting. SIGTERM Processes should also be robust against sudden death, …

89 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction X. Dev/prod parity Keep development, staging, and production as similar as possible Historically, there have been substantial gaps between development (a developer making live edits to a local deploy of the app) and production (a running deploy of the app accessed by end users). These gaps manifest in three areas:deploy –The time gap: A developer may work on code that takes days, weeks, or even months to go into production. –The personnel gap: Developers write code, ops engineers deploy it. –The tools gap: Developers may be using a stack like Nginx, SQLite, and OS X, while the production deploy uses Apache, MySQL, and Linux. The twelve-factor app is designed for continuous deployment by keeping the gap between development and production small. Looking at the three gaps described above:continuous deployment –Make the time gap small: a developer may write code and have it deployed hours or even just minutes later. –Make the personnel gap small: developers who wrote code are closely involved in deploying it and watching its behavior in production. –Make the tools gap small: keep development and production as similar as possible.

90 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction X. Dev/prod parity Backing services, such as the app’s database, queueing system, or cache, is one area where dev/prod parity is important. Many languages offer libraries which simplify access to the backing service, including adapters to different types of services. Some examples are in the table below.Backing services Developers sometimes find great appeal in using a lightweight backing service in their local environments, while a more serious and robust backing service will be used in production. The twelve-factor developer resists the urge to use different backing services between development and production, even when adapters theoretically abstract away any differences in backing services. Differences between backing services mean that tiny incompatibilities crop up, causing code that worked and passed tests in development or staging to fail in production. Adaptor Fallacy

91 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction XI. Logs Treat logs as event streams Logs –Logs provide visibility into the behavior of a running app. In server-based environments they are commonly written to a file on disk (a “logfile”); but this is only an output format. –Logs are the stream of aggregated, time-ordered events collected from the output streams of all running processes and backing services. Logs in their raw form are typically a text format with one event per line (though backtraces from exceptions may span multiple lines). Logs have no fixed beginning or end, but flow continuously as long as the app is operating.stream –A twelve-factor app never concerns itself with routing or storage of its output stream. It should not attempt to write to or manage logfiles. Instead, each running process writes its event stream, unbuffered, to stdout. During local development, the developer will view this stream in the foreground of their terminal to observe the app’s behavior. –In staging or production deploys, each process’ stream will be captured by the execution environment, collated together with all other streams from the app, and routed to one or more final destinations for viewing and long-term archival. Comments –This applies to debug, trace, problem deternination, … logs. –My view is that business events have a pub/sub implementation and are part of app model.

92 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction XII. Admin processes Run admin/management tasks as one-off processes Application administration –The process formation is the array of processes that are used to do the app’s regular business (such as handling web requests) as it runs. Separately, developers will often wish to do one-off administrative or maintenance tasks for the app, such as:process formation –Running database migrations (e.g. manage.py migrate in Django, rake db:migrate in Rails). –Running a console (also known as a REPL shell) to run arbitrary code or inspect the app’s models against the live database. Most languages provide a REPL by running the interpreter without any arguments (e.g. python or perl) or in some cases have a separate command (e.g. irb for Ruby, rails console for Rails).REPL –Running one-time scripts committed into the app’s repo (e.g. php scripts/fix_bad_records.php). –One-off admin processes should be run in an identical environment as the regular long-running processes of the app. They run against a release, using the same codebase and config as any process run against that release. Admin code must ship with application code to avoid synchronization issues.long-running processesreleasecodebaseconfig Comments –Traditionally application management occurred through special side mechanisms, e.g. WMI, MBeans, SMTP, CMIP, … –12 Factor apps have admin as an intrinisc part of the application. –But, there will still be separate “management” solutions for end-to-end, multi-app management,

93 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Orchestration Workflow

94 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction BPMN BPMN 2.0 is an international standard for business process modeling. The BPMN specification describes how the elements of a process diagram have to look like (notation), how these can be combined with each other (meta model / syntax), what a diagram means (semantics) and how diagrams can be transferred from one tool to another (XML interchange format). Process models describe sequences of business activities from start to finish, e.g. Order-to-Cash, Account Open

95 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction BPMN and Activiti Some terms –BPMN 2.0 is a standard for defining/documenting workflows/orchestrations. –Activiti (and many others) are implementations of the standard –Runtime engine that can interpret and execute a BPMN process –A WYSIWYG editor –With prebuilt, configurable shapes palette that extend base BPMN shapes. Huh? BPMN has the concepts of a “Task,” which is one “step” in a process. But in a process model, this is just “prose” like “Order a Pizza” Implementations come with “common” types of tasks, e.g. Make an SQL call on a database. Call a REST API Put a document on a worklist etc. –A composition canvass for assembling shapes into processes. –Debugger, monitoring, reporting, versioning, etc. This is –The same concept as enterprise integration patterns and Boomi –But, –The clipart is different –And the graph mostly represents “control flow,” not data flow.

96 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Simple BPMN Diagram

97 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction And You can Define Processes

98 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction How do you Implement? Notify a person/role. Have them do something. Have the use an app that calls the engine to tell you they are done. Send an email. POST a document etc. Decision table Call Drools etc. Insert into a DB Call a web service Run a Java app. etc. Run some JavaScript or Java or … Right at this point in the workflow/process And manipulate the data/documents/control.

99 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction AWS Simple Workflow

101 © Donald F. Ferguson, 2015. All rights reserved.Micro-service Application and API Development (E6998-07-2015-03) – Lecture 5: Questions, 12 Factor App, Orchestration, Security Introduction Application Structure Role of the Activities Worker: The activities worker performs the various tasks that the workflow must accomplish. It consists of: –The activities implementation, which includes of a set of activity methods that perform particular tasks for the workflow. –An activity worker, which uses HTTP long poll requests to poll Amazon SWF for activity tasks. When a task is available, Amazon SWF responds to the request by sending the information required to perform the task. The activity worker then calls the appropriate activity method, and returns the results to Amazon SWF. Role of the Workflow Worker: The workflow worker orchestrates the execution of the various activities, manages data flow, and handles failed activities. It consists of: –The workflow implementation, which includes the activity orchestration logic, handles failed activities, and so on. –An activities client, which serves as a proxy for the activities worker and enables the workflow worker to schedule activities to be executed asynchronously. –A workflow worker object, which uses HTTP long poll requests to poll Amazon SWF for decision tasks. If there are tasks on the workflow task list, Amazon SWF responds to the request by returning the information that is required to perform the task. The framework then executes the workflow to perform the task and returns the results to Amazon SWF.

© Donald F. Ferguson, 2015. All rights reserved. Topics in Computer Science: COMS E6998-07-2015-03 Micro-service Application and API Development Lecture.

Similar presentations

Presentation on theme: "© Donald F. Ferguson, 2015. All rights reserved. Topics in Computer Science: COMS E6998-07-2015-03 Micro-service Application and API Development Lecture."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

© Donald F. Ferguson, 2015. All rights reserved. Topics in Computer Science: COMS E6998-07-2015-03 Micro-service Application and API Development Lecture.

Similar presentations

Presentation on theme: "© Donald F. Ferguson, 2015. All rights reserved. Topics in Computer Science: COMS E6998-07-2015-03 Micro-service Application and API Development Lecture."— Presentation transcript:

Similar presentations

About project

Feedback