Enn Õunapuu

Transcription

1 Asünkroonsed teenused Enn Õunapuu

2 Määrang Asynchronous processing enables methods to return immediately without blocking on the calling thread. Consumers request asynchronous processing when initializing a data source object or when opening or populating a rowset. The consumer must explicitly request asynchronous processing. Otherwise, the provider can perform asynchronous operations in the background but must behave synchronously, blocking if necessary, until the underlying asynchronous operation completes.

3 Miks asünkroonne 1. Ei blokeeri rakenduse 2. Hoiab ressursse kokku

4 Messagging

5 Asynchronous messaging Asynchronous messaging is fundamentally a pragmatic reaction to the problems of distributed systems. Sending a message does not require both systems to be up and ready at the same time. Furthermore, thinking about the communication in an asynchronous manner forces developers to recognize that working with a remote application is slower, which encourages design of components with high cohesion (lots of work locally) and low adhesion (selective work remotely).

6 Basic Messaging Concepts Channels Messaging applications transmit data through a Message Channel, a virtual pipe that connects a sender to a receiver. Messages A Message is an atomic packet of data that can be transmitted on a channel. Multi-step delivery A Pipes and Filters architecture describes how multiple processing steps can be chained together using channels. Routing In a large enterprise with numerous applications and channels to connect them, a message may have to go through several channels to reach its final destination. Transformation Various applications may not agree on the format for the same conceptual data; the sender formats the message one way, yet the receiver expects it to be formatted another way. Endpoints This bridge code is a set of coordinated Message Endpoints that enable the application to send and receive messages.

7 Message Channel

8 Message

9 Pipes and filters

10 Message router

11 Message translator

12 Message endpoint

13 Enterprise integration Patterns

14

15

16 Event Driven Messaging Service A requests that it be set up as a subscriber to the event it is interested in by interacting with an event manager. Once the event occurs, Service B forwards the details to the event manager which, in turn, notifies Service A (and all other subscribers) via a one-way, asynchronous data transfer. Note that in this case, Service A also receives the event information earlier because the event details can be transmitted as soon as they're available.

17

18

19 Enterprise 1.0 ( 60s 80s) Enterprise 2.0 ( 80s 2000) Enterprise 3.0 ( ) Data Processing Client Server Predictive Building Block Mainframe Database ESB Software 2-Tier 3-Tier N-Tier Velocity Batch Online Event Driven Interactions 000 s 000,000 s 000,000,000,000 s 19

20 Half Life of Data Enterprise 1.0 ( 60s 80s) Enterprise 2.0 ( 80s 2000) Enterprise 3.0 Amount of Data ( ) Time to React Data Processing Client Server Predictive Building Block Mainframe Database ESB Software 2-Tier 3-Tier N-Tier Velocity Batch Online Event Driven Interactions 000,000 s 000,000,000 s 000,000,000,000 s 20

21 The Data Advantage Events Enterprise 3.0 Threats & Opportunities Transactions Enterprise

22 Potential Business Value CEP enables More Effective Decisions Business Automation Enables Fast Response Business Event Effective Real-time Decisions Dynamic Business Conditions Point of Transaction Response to Dynamic Conditions Result Measured Root Cause Determined Corrective Decision Made Action Taken Action time 22

23 Velocity drives need for Event Processing Business Cycle-Time Improvements Perform Trading Analytics Airline Operations 30 minutes 20 minutes 5 seconds 30 seconds Handle Call Center Inquiries Track Financial/Risk Position 1 day 8 hours 5 minutes 10 seconds Supply Chain Updates Document Transfer Phone/Service Activation Refresh Data Warehouse Settle Trade/Transaction Build-to-Order Product 1 day 3 days 3 days 1 month 5 days 6 weeks 15 minutes Mail express fax 20 seconds 1 hour 1 hour 1 day 1 day Source: Gartner 23

24 Demo

25 public bool SavetoMSMQ(string XMLDoc) { Boolean edu = true; // check if queue exists, if not create it MessageQueue msmq = null; if (!MessageQueue.Exists(ConfigurationManager.AppSettings["queueName"])) { msmq = MessageQueue.Create(ConfigurationManager.AppSettings["queueName"]); } else { msmq = new MessageQueue(ConfigurationManager.AppSettings["queueName"]); } try { msmq.send(xmldoc); } catch (Exception ee) { edu = false; } finally { msmq.close(); } return edu; }

26 <appsettings> <!-- use appsetting to configure MSMQ queue name --> <add key="queuename" value=".\private$\invoicequeue"/> </appsettings>

27 protected void Button1_Click(object sender, EventArgs e) { Stream thestream = FileUpload1.PostedFile.InputStream; StreamReader reader = new StreamReader(theStream); string text = reader.readtoend(); MSMQ client = new MSMQ(); client.savetomsmqasync(text); Label1.Text = "kirjutatud MSMQ-sse FILE:" + FileUpload1.FileName; }

28 Background Application requirements have changed dramatically in recent years. Only a few years ago a large application had tens of servers, seconds of response time, hours of offline maintenance and gigabytes of data. Today applications are deployed on everything from mobile devices to cloud-based clusters running thousands of multi-core processors. Users expect millisecond response times and 100% uptime. Data is measured in Petabytes. Today's demands are simply not met by yesterday s software architectures.

29 Intension A coherent approach to systems architecture is needed, and we believe that all necessary aspects are already recognised individually: we want systems that are: Responsive, Resilient, Elastic and Message Driven. We call these Reactive Systems.

30 Features Systems built as Reactive Systems are more flexible, loosely-coupled and scalable. This makes them easier to develop and amenable to change. They are significantly more tolerant of failure and when failure does occur they meet it with elegance rather than disaster. Reactive Systems are highly responsive, giving users effective interactive feedback.

31 Responsive The system responds in a timely manner if at all possible. Responsiveness is the cornerstone of usability and utility, but more than that, responsiveness means that problems may be detected quickly and dealt with effectively. Responsive systems focus on providing rapid and consistent response times, establishing reliable upper bounds so they deliver a consistent quality of service. This consistent behaviour in turn simplifies error handling, builds end user confidence, and encourages further interaction.

32 Resilient The system stays responsive in the face of failure. This applies not only to highly-available, mission critical systems any system that is not resilient will be unresponsive after a failure. Resilience is achieved by replication, containment, isolation and delegation. Failures are contained within each component, isolating components from each other and thereby ensuring that parts of the system can fail and recover without compromising the system as a whole. Recovery of each component is delegated to another (external) component and high-availability is ensured by replication where necessary. The client of a component is not burdened with handling its failures.

33 Elastic The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. This implies designs that have no contention points or central bottlenecks, resulting in the ability to shard or replicate components and distribute inputs among them. Reactive Systems support predictive, as well as Reactive, scaling algorithms by providing relevant live performance measures. They achieve elasticity in a cost-effective way on commodity hardware and software platforms.

34 Message Driven Reactive Systems rely on asynchronous message-passing to establish a boundary between components that ensures loose coupling, isolation, location transparency, and provides the means to delegate errors as messages. Employing explicit message-passing enables load management, elasticity, and flow control by shaping and monitoring the message queues in the system and applying back-pressure when necessary. Location transparent messaging as a means of communication makes it possible for the management of failure to work with the same constructs and semantics across a cluster or within a single host. Nonblocking communication allows recipients to only consume resources while active, leading to less system overhead.

35

36 Architecture principe Large systems are composed of smaller ones and therefore depend on the Reactive properties of their constituents. This means that Reactive Systems apply design principles so these properties apply at all levels of scale, making them composable. The largest systems in the world rely upon architectures based on these properties and serve the needs of billions of people daily. It is time to apply these design principles consciously from the start instead of rediscovering them each time.

37 Node.js characteristics

38

39

40

41

42

43

44

45

46

47

48

49

50 Jõudu!!!