Im Entwickler-Alltag finden wir uns oft in Situationen wieder in denen wir mit parallelen, nebenläufigen Systemen kämpfen. Hier kann Actorbased Programming helfen dieser Herr zu werden. Akka.Net, welches sich selbst als „toolkit and runtime for building highly concurrent, distributed, and fault tolerant event-driven applications“ bezeichnet erlaubt es Entwicklern dieses Paradigma für sich zu nutzen.Akka.Net ist eine Portierung des von Typesafe entwickelten Actor-Framework.In der Java/Scala Welt hat es bereits einen durchschlagenden Erfolg. Akka.Net bietet nun diese Möglichkeiten für .Net-Entwickler.Im Wesentlichen soll der Vortrag auf die Basics des Actorbased Computings eingehen, sowie Parallelen zu verwandten Thematiken wie Agentbased Computing und verwandten Design-Patterns herstellen.An kleinen abstrakten Szenarien wird das Framework und eine minimale Anwendung eines Actor-Systems vorgestellt. Zum Abschluss ist geplant nochmals auf die essentielle Kommunikationspattern eingegangen.
Reactive applications with Akka.Net - DDD East Anglia 2015Anthony Brown
Application requirements have changed significantly over the past 20 years and we’re now building software which has to handle potentially millions of users and billions of devices. The reactive manifesto is a set of common traits shared by applications capable of handling these new requirements. Akka is the canonical example of a toolkit for building such applications, but thanks to a team of dedicated developers, Akka has arrived on the CLR in the form of Akka.Net. This session looks at the key principles of Akka.Net and how using these you can build applications which handle potentially massive traffic.
Writing a Search Engine. How hard could it be?Anthony Brown
5 of the most dangerous words you'll hear a developer say are "How hard could it be?". This talk tells the tale of what happens when you act on the question of "I'm going to write the next Google beater. How hard could it be?" This is the tale of how one person in a few hours is able to write something resembling a search engine thanks to the platform features of Azure and the productivity of F#. We'll see how we're able to use Azure search from F# to easily power our search internals, we'll use MBrace to rapidly find the most popular web pages on the internet and Azure functions to tie everything together to build up APIs and create on demand infrastructure. Add in a healthy mix of queues provided by Azure Service Bus and if you squint hard enough, you might just end up seeing something resembling a search engine.
But seriously writing the next Google, just how hard could it be?
A recording of this talk is available via SkillsMatter at https://skillsmatter.com/skillscasts/8901-f-sharpunctional-londoners-meetup
This was a talk from DDDSW on Akka.Net, the actor model, concurrency and reactive. It covered what they are as well as an example use case and the lessons learned when running in that use case.
The actor model is an approach to designing concurrent systems that has been around since the early 70's, but is gaining more popularity today. Being a message-based approach, the actor model fits nicely when building out transactional or multi-step workflow process systems. Message-driven actor systems take a lot of the complexity away and allow you to create small classes (actors) that handle very specific tasks. These actors are coordinated via the passing of immutable messages, which allows your system to scale out if needed. In this talk, we’ll look at a popular .NET actor system Akka.NET and, through several simple examples, show you how to get started building scalable message-driven solutions.
As users of NServiceBus, we’re already familiar with using message-oriented systems to decouple our systems and create reliable collaboration between our services. But what could be possible if you made this message-oriented behavior the basis of your entire application?
In this talk, we’ll introduce Akka.NET and the actor model and show you how to use it to create massively scalable, stateful applications using many of the same messaging patterns you’re already familiar with from NServiceBus. We’ll talk about how to use the Akka.NET distributed actor framework to create more responsive, scalable, and intuitive applications by bringing message-oriented behavior to your entire stack via actors and many of the messaging patterns you already use.
Reactive applications with Akka.Net - DDD East Anglia 2015Anthony Brown
Application requirements have changed significantly over the past 20 years and we’re now building software which has to handle potentially millions of users and billions of devices. The reactive manifesto is a set of common traits shared by applications capable of handling these new requirements. Akka is the canonical example of a toolkit for building such applications, but thanks to a team of dedicated developers, Akka has arrived on the CLR in the form of Akka.Net. This session looks at the key principles of Akka.Net and how using these you can build applications which handle potentially massive traffic.
Writing a Search Engine. How hard could it be?Anthony Brown
5 of the most dangerous words you'll hear a developer say are "How hard could it be?". This talk tells the tale of what happens when you act on the question of "I'm going to write the next Google beater. How hard could it be?" This is the tale of how one person in a few hours is able to write something resembling a search engine thanks to the platform features of Azure and the productivity of F#. We'll see how we're able to use Azure search from F# to easily power our search internals, we'll use MBrace to rapidly find the most popular web pages on the internet and Azure functions to tie everything together to build up APIs and create on demand infrastructure. Add in a healthy mix of queues provided by Azure Service Bus and if you squint hard enough, you might just end up seeing something resembling a search engine.
But seriously writing the next Google, just how hard could it be?
A recording of this talk is available via SkillsMatter at https://skillsmatter.com/skillscasts/8901-f-sharpunctional-londoners-meetup
This was a talk from DDDSW on Akka.Net, the actor model, concurrency and reactive. It covered what they are as well as an example use case and the lessons learned when running in that use case.
The actor model is an approach to designing concurrent systems that has been around since the early 70's, but is gaining more popularity today. Being a message-based approach, the actor model fits nicely when building out transactional or multi-step workflow process systems. Message-driven actor systems take a lot of the complexity away and allow you to create small classes (actors) that handle very specific tasks. These actors are coordinated via the passing of immutable messages, which allows your system to scale out if needed. In this talk, we’ll look at a popular .NET actor system Akka.NET and, through several simple examples, show you how to get started building scalable message-driven solutions.
As users of NServiceBus, we’re already familiar with using message-oriented systems to decouple our systems and create reliable collaboration between our services. But what could be possible if you made this message-oriented behavior the basis of your entire application?
In this talk, we’ll introduce Akka.NET and the actor model and show you how to use it to create massively scalable, stateful applications using many of the same messaging patterns you’re already familiar with from NServiceBus. We’ll talk about how to use the Akka.NET distributed actor framework to create more responsive, scalable, and intuitive applications by bringing message-oriented behavior to your entire stack via actors and many of the messaging patterns you already use.
Serverless lessons learned #2 dead letter queuesMaik Wiesmüller
After building serverless applications for quite a few years, we decided to share some important pieces and concepts for production-ready serverless projects.
This time: Why you should utilize Dead Letter Queues when building event-driven systems.
More Information: https://lnkd.in/dnY6cNnG
It's rare that you get a chance to build an applicaton the way you want to, from the ground up. If you did, what architectural choices would you make and why? Command Query Responsibility Segregation (CQRS) is a hot topic and has been described as crack for architecture addicts. This talk will look at why CQRS may be a good architectural choice for your project, how to use the NCQRS framework, and how this framework can be incorporated with ASP.NET MVC on the front-end and Azure on the back-end. This talk will also focus on the learning curve experienced when implementing an architectural style that bends the curve and is out of the mainstream of traditional application development.
After building serverless applications for quite a few years, we decided to share some important pieces and concepts for production-ready serverless projects.
This time: Lambda Reserved Concurrency.
More Information: https://lnkd.in/dRxHdrCa
When we started building serverless applications back in 2017, there was quite a lot to learn.
So we'd like to share some mistakes, important pieces, and concepts for production-ready serverless projects.
This time: Retries.
More Information:
API-Retries: https://lnkd.in/dVwwEsat
Lambda-Retries: https://lnkd.in/dEs6xXyb
SQS-Retries: https://lnkd.in/dPm2x7ZT
After building serverless applications for a couple of years now, we decided to share some important pieces and concepts for production-ready serverless projects.
Let's start with: What are Custom SDK Timeouts and why you should care.
Default timeouts and troubleshooting: https://lnkd.in/dZsgxk9p
This deck is the story around how Postman was able to scale to serve 10+ million requests per hour in one year from startup and how docker became an integral part of it's frugal operations
An example of Continuous Delivery in Java presented at Italian Agile Days 2015. How you can improve your Continuous Delivery pipeline using an iterative and incremental approch
Continuing our series of mistakes, important pieces, and concepts for production-ready serverless projects in 2022.
"exponential backoff"
In-depth backoff and jitter comparison: https://lnkd.in/disA6tQq
AWS SDK (node) custom backoff: https://lnkd.in/dFrMbGfs
After building serverless applications for quite a few years, we decided to share some important pieces and concepts for production-ready serverless projects.
This time: Circuit Breaker.
More Information: https://lnkd.in/dExSRsjp
Empower every Azure Function to achieve more!!Massimo Bonanni
Session at Microsoft Reactor Stockholm at 10/02/2021.
The Azure Functions seem easy to use but what if our business scenario cannot be implemented using one of the "default" triggers or bindings? "Extension" is the keyword in this case! In this session, we see how to enhance our functions with custom triggers and custom bindings to make the most of the power of Serverless.
AWS Lambda has changed the way we deploy and run software, but this new serverless paradigm has created new challenges to old problems - how do you test a cloud-hosted function locally? How do you monitor them? What about logging and config management? And how do we start migrating from existing architectures?
In this talk Yan will discuss solutions to these challenges by drawing from real-world experience running Lambda in production and migrating from an existing monolithic architecture.
When we started building serverless applications back in 2017, there was quite a lot to learn.
So we'd like to share some mistakes, important pieces, and concepts for production-ready serverless projects.
This time: Rate limiting / Throttling
AWS SDK retry handling: https://lnkd.in/dVwwEsat
AWS SDK customize retry options: https://lnkd.in/dFrMbGfs
API-GW Throttling: https://lnkd.in/dfVbVtsm
Here is the technology behind how I took my boring Mr. Coffee coffee maker and made it accessible over a WiFi network to allow me to control it from my laptop.
Building responsive applications with Rx - CodeMash2017 - Tamir DresherTamir Dresher
Slides from the CodeMash 2017 conference: http://www.codemash.org/session/creating-a-responsive-application-using-reactive-extensions/
Code example are here: https://github.com/tamirdresher/Rx101
Serverless lessons learned #2 dead letter queuesMaik Wiesmüller
After building serverless applications for quite a few years, we decided to share some important pieces and concepts for production-ready serverless projects.
This time: Why you should utilize Dead Letter Queues when building event-driven systems.
More Information: https://lnkd.in/dnY6cNnG
It's rare that you get a chance to build an applicaton the way you want to, from the ground up. If you did, what architectural choices would you make and why? Command Query Responsibility Segregation (CQRS) is a hot topic and has been described as crack for architecture addicts. This talk will look at why CQRS may be a good architectural choice for your project, how to use the NCQRS framework, and how this framework can be incorporated with ASP.NET MVC on the front-end and Azure on the back-end. This talk will also focus on the learning curve experienced when implementing an architectural style that bends the curve and is out of the mainstream of traditional application development.
After building serverless applications for quite a few years, we decided to share some important pieces and concepts for production-ready serverless projects.
This time: Lambda Reserved Concurrency.
More Information: https://lnkd.in/dRxHdrCa
When we started building serverless applications back in 2017, there was quite a lot to learn.
So we'd like to share some mistakes, important pieces, and concepts for production-ready serverless projects.
This time: Retries.
More Information:
API-Retries: https://lnkd.in/dVwwEsat
Lambda-Retries: https://lnkd.in/dEs6xXyb
SQS-Retries: https://lnkd.in/dPm2x7ZT
After building serverless applications for a couple of years now, we decided to share some important pieces and concepts for production-ready serverless projects.
Let's start with: What are Custom SDK Timeouts and why you should care.
Default timeouts and troubleshooting: https://lnkd.in/dZsgxk9p
This deck is the story around how Postman was able to scale to serve 10+ million requests per hour in one year from startup and how docker became an integral part of it's frugal operations
An example of Continuous Delivery in Java presented at Italian Agile Days 2015. How you can improve your Continuous Delivery pipeline using an iterative and incremental approch
Continuing our series of mistakes, important pieces, and concepts for production-ready serverless projects in 2022.
"exponential backoff"
In-depth backoff and jitter comparison: https://lnkd.in/disA6tQq
AWS SDK (node) custom backoff: https://lnkd.in/dFrMbGfs
After building serverless applications for quite a few years, we decided to share some important pieces and concepts for production-ready serverless projects.
This time: Circuit Breaker.
More Information: https://lnkd.in/dExSRsjp
Empower every Azure Function to achieve more!!Massimo Bonanni
Session at Microsoft Reactor Stockholm at 10/02/2021.
The Azure Functions seem easy to use but what if our business scenario cannot be implemented using one of the "default" triggers or bindings? "Extension" is the keyword in this case! In this session, we see how to enhance our functions with custom triggers and custom bindings to make the most of the power of Serverless.
AWS Lambda has changed the way we deploy and run software, but this new serverless paradigm has created new challenges to old problems - how do you test a cloud-hosted function locally? How do you monitor them? What about logging and config management? And how do we start migrating from existing architectures?
In this talk Yan will discuss solutions to these challenges by drawing from real-world experience running Lambda in production and migrating from an existing monolithic architecture.
When we started building serverless applications back in 2017, there was quite a lot to learn.
So we'd like to share some mistakes, important pieces, and concepts for production-ready serverless projects.
This time: Rate limiting / Throttling
AWS SDK retry handling: https://lnkd.in/dVwwEsat
AWS SDK customize retry options: https://lnkd.in/dFrMbGfs
API-GW Throttling: https://lnkd.in/dfVbVtsm
Here is the technology behind how I took my boring Mr. Coffee coffee maker and made it accessible over a WiFi network to allow me to control it from my laptop.
Building responsive applications with Rx - CodeMash2017 - Tamir DresherTamir Dresher
Slides from the CodeMash 2017 conference: http://www.codemash.org/session/creating-a-responsive-application-using-reactive-extensions/
Code example are here: https://github.com/tamirdresher/Rx101
"How do I do transactions across a distributed system?" is a very common question. This talk taught the basic conceptual model, which can then be customized and applied to specific use cases and consistency requirements.
From Zero to the Actor Model (With Akka.Net) - CodeMash2017 - Tamir DresherTamir Dresher
These are the slides from my talk at the CodeMash 2017 conferenece: http://www.codemash.org/session/creating-a-responsive-application-using-reactive-extensions/
Code examples are located here: https://github.com/tamirdresher/FromZeroToTheActorModel
Reactive Development: Commands, Actors and Events. Oh My!!David Hoerster
Distributed applications are becoming more popular with the increasing popularity of microservices (however you want to define that term). But the principles of distributed application development are key if you want to build a system that is resilient, responsive, elastic and maintainable. In this workshop, we’ll review the principles of CQRS and the Reactive Manifesto, and how they complement each other. We’ll build an application that can handle a large stream of data, and allow users to still have a responsive experience while interacting with real-time and near-real-time data.
We’ll look at Akka.NET as the workhorse inside your services, and how the principles of CQRS can help with your service-to-service communications.
We’ll also look at how Event Sourcing can aid in managing your domain state, and how an event stream can be used to project data for your system for a number of different uses. We’ll build our own simple event store, but also look at commercially available stores, too.
This session will focus on using Akka.NET along with a few other tools and technologies, such as EventStore and MongoDB. The concepts learned in this session will be applicable to a number of different tools, technologies and languages.
CQRS (Command Query Responsibility Segregation) was all the hype in .NET architecture circles a few years back. But has it faded away? Is it old news? I argue that it hasn't, and the concepts of CQRS are alive and well and probably more widely accepted and considered today than a few years ago. From event-driven systems to the Reactive Manifesto, the principles of CQRS are with us and impacting many different tools. In this session, we'll explore those CQRS principles and how they have manifested themselves in the architectures of choice today. You'll come away with a greater appreciation of CQRS and ideas on how to incorporate those principles in your applications today.
CQRS and Event Sourcing, An Alternative Architecture for DDDDennis Doomen
Most of us will be familiar with the standard 3- or 4-layer architecture you often see in larger enterprise systems. Some are already practicing Domain Driven Design and work together with the business to clarify the domain concepts. Perhaps you’ve noticed that is difficult to get the intention of the 'verbs' from that domain into this standard architecture. If performance is an important requirement as well, then you might have discovered that an Object-Relational Mapper and a relational database are not always the best solution.
One of the main reasons for this is the fact that the interests of a consistent domain that takes into account the many business rules, and those of data reporting and presentation are conflicting. That’s why Betrand Meyer introduced the Command Query Separation principle.
An architecture based on this principle combined with the Event Sourcing concept provides the ideal architecture for building high-performance systems designed using DDD. Well-known bloggers like Udi Dahan and Greg Young have already spent quite a lot of of posts on this, and this year’s Developer Days had some coverage as well.
But how do you build such a system with the. NET framework? Is it really as complex as some claim, or is just different work?
During the talk, we will build a simple web app using Lift and then introduce Akka ( http://akkasource.org) to help scale it. Specifically, we will demonstrate Remote Actors, "Let it crash" fail over, and Dispatcher. Other Scala oriented tools we will use include sbt and ENSIME mode for emacs.
Although most microservices are stateless - they delegate things like persistence and consistency to a database or external storage. But sometimes you benefit when you keep the state inside the application. In this talk I’m going to discuss why you want to build stateful microservices and design choices to make. I’ll use Akka framework and explain tools like Akka Clustering and Akka Persistence in depth and show a few practical examples.
Nowadays Akka is a popular choice for building distributed systems - there are a lot of case studies and successful examples in the industry.
But it still can be hard to switch to actor-based systems, because most of the tutorials and documentation don't show the way to assemble a real application using actors, especially in microservices environment.
Actor is a powerful abstraction in the message-driven environments, but it can be challenging to use familiar patterns and methodologies. At the same time, message-driven nature of actors is the biggest advantage that can be used for Reactive systems and microservices.
I want to share my experience and show how Domain-Driven Design and Enterprise Integration Patterns can be leveraged to design and build fine-grained microservices with synchronous and asynchronous communication. I'll focus on the core Akka functionality, but also explain how advanced features like Akka Persistence and Akka Cluster Sharding can be used together for achieving incredible results.
This slide shows you how to use Akka cluster in Java.
Source Code: https://github.com/jiayun/akka_samples
If you want to use the links in slide, please download the pdf file.
Introduction to Akka, as presented on May 3 2012 at the Belgian Java User Group (BeJUG). For more details see: http://www.bejug.org/confluenceBeJUG/display/BeJUG/ForkJoin+and+Akka
Demo code can be found at: http://bit.ly/bejug-akka
Similar to Reactive Programming in .Net - actorbased computing with Akka.Net (20)
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdfPeter Spielvogel
Building better applications for business users with SAP Fiori.
• What is SAP Fiori and why it matters to you
• How a better user experience drives measurable business benefits
• How to get started with SAP Fiori today
• How SAP Fiori elements accelerates application development
• How SAP Build Code includes SAP Fiori tools and other generative artificial intelligence capabilities
• How SAP Fiori paves the way for using AI in SAP apps
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
PHP Frameworks: I want to break free (IPC Berlin 2024)Ralf Eggert
In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development.
This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
UiPath Test Automation using UiPath Test Suite series, part 3DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 3. In this session, we will cover desktop automation along with UI automation.
Topics covered:
UI automation Introduction,
UI automation Sample
Desktop automation flow
Pradeep Chinnala, Senior Consultant Automation Developer @WonderBotz and UiPath MVP
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Welocme to ViralQR, your best QR code generator.ViralQR
Welcome to ViralQR, your best QR code generator available on the market!
At ViralQR, we design static and dynamic QR codes. Our mission is to make business operations easier and customer engagement more powerful through the use of QR technology. Be it a small-scale business or a huge enterprise, our easy-to-use platform provides multiple choices that can be tailored according to your company's branding and marketing strategies.
Our Vision
We are here to make the process of creating QR codes easy and smooth, thus enhancing customer interaction and making business more fluid. We very strongly believe in the ability of QR codes to change the world for businesses in their interaction with customers and are set on making that technology accessible and usable far and wide.
Our Achievements
Ever since its inception, we have successfully served many clients by offering QR codes in their marketing, service delivery, and collection of feedback across various industries. Our platform has been recognized for its ease of use and amazing features, which helped a business to make QR codes.
Our Services
At ViralQR, here is a comprehensive suite of services that caters to your very needs:
Static QR Codes: Create free static QR codes. These QR codes are able to store significant information such as URLs, vCards, plain text, emails and SMS, Wi-Fi credentials, and Bitcoin addresses.
Dynamic QR codes: These also have all the advanced features but are subscription-based. They can directly link to PDF files, images, micro-landing pages, social accounts, review forms, business pages, and applications. In addition, they can be branded with CTAs, frames, patterns, colors, and logos to enhance your branding.
Pricing and Packages
Additionally, there is a 14-day free offer to ViralQR, which is an exceptional opportunity for new users to take a feel of this platform. One can easily subscribe from there and experience the full dynamic of using QR codes. The subscription plans are not only meant for business; they are priced very flexibly so that literally every business could afford to benefit from our service.
Why choose us?
ViralQR will provide services for marketing, advertising, catering, retail, and the like. The QR codes can be posted on fliers, packaging, merchandise, and banners, as well as to substitute for cash and cards in a restaurant or coffee shop. With QR codes integrated into your business, improve customer engagement and streamline operations.
Comprehensive Analytics
Subscribers of ViralQR receive detailed analytics and tracking tools in light of having a view of the core values of QR code performance. Our analytics dashboard shows aggregate views and unique views, as well as detailed information about each impression, including time, device, browser, and estimated location by city and country.
So, thank you for choosing ViralQR; we have an offer of nothing but the best in terms of QR code services to meet business diversity!
25. PM> Install-Package Akka
nuget
using Akka.Actor;
using (var actorSystem = ActorSystem.Create("MyActorSystem"))
{
// universe
}
nur innerhalb dieses Blocks
„leben“ Aktoren
var actorSystem = ActorSystem.Create("MyActorSystem"));
// universe
actorSystem.WhenTerminated.Wait(); // wait for termination-task
actorSystem.AwaitTermination(); // deprecated
oder
26. // universe
IActorRef myActor = actorSystem.ActorOf(
Props.Create(() => new MyActor())
);
using (var actorSystem = ActorSystem.Create("MyActorSystem"))
{
}
// talk to the actor
myActor.Tell(new SomeMessage("rise up slave..."));
erzeuge AktorSystem
fordere spezifischen
Aktor an
sprich mit dem erhaltenen
Aktor
27. public class SomeMessage
{
public SomeMessage(string name)
{
Name = name;
}
public string Name { get; private set; }
}
public class MyActor : ReceiveActor
{
public MyActor()
{
Receive<string>(message => {
Sender.Tell(message);
});
Receive<SomeMessage>(message => {
// react to message
});
}
}
alle Nachrichten sind
immutable
Nachrichten werden
prinzipiell nach ihrem
Typ unterschieden *
* es geht fein-granularer
und abstrakter
31. public class MyActor : ActorBase
{
public MyActor()
{
//nothing todo
}
protected override bool Receive(object _message)
{
//handle different messages
var message = _message as SomeMessage;
if(message != null)
{
return false;
}
return false;
}
}
Nachrichten werden
prinzipiell nach ihrem
Typ unterschieden *
* es geht fein-granularer
und abstrakter
32. using Akka.Actor;
public class MyUntypedActor : UntypedActor
{
protected override void OnReceive(object message)
{
var msg = message as Messages.InputError;
if (msg != null)
{
// cool, its for me
}
else
{
Unhandled(message); //from ActorBase
}
}
}
• anders als beim ReceiveActor müssen nicht behandelte
Nachrichten selbst als solche markiert werden
35. event-driven thread
Actor
Behavior
Mailbox
State
Childs
Supervisor-Strategy
ActorRef 1 2 34
Transport [Akka]
IActorRef myActor = ...
myActor.Tell(new Message("four"));
• IActorRef: handle oder reference auf einen Actor
• Nachrichten werden niemals direkt an einen
Actor gesendet
• ActorSystem fügt Metadaten (Sender, Empfänger) hinzu
• ActorSystem garantiert Ankunft jeder Nachricht *
36. IActorRef
• Actor Namen sind optional
• best practise: named actors
Create
Look up
IActorRef myActor = actorSystem.ActorOf(
Props.Create(() => new MyActor()),
"myactor1"
);
• adressierbar über ActorPath
• Actoren bilden eine Hierarchy
Parent
Children
Sender
ActorSelection randomActor =
actorSystem.ActorSelection("akka://ActorSys/user/myactor1");
37. Props props1 = Props.Create(typeof(MyActor));
Props props2 = Props.Create(() => new MyActor());
Props props3 = Props.Create<MyActor>();
typeof Syntax
lambda Syntax
generic Syntax
• einzigerWeg um Parameter
zu übergeben
• unsicher
Context.ActorOf(props2);
actorSystem.ActorOf(props2);
aus einem Actor heraus:
direkt im ActorSystem:
-> erzeugt HierarchieVerwendung
43. • erklärtes Ziel ist es Fehler einzugrenzen:
• localizing the failure: fehleranfälligen Code
The critical thing to know here is that *whatever action is
taken on a parent propagates to its children*. If a parent is
halted, all its children halt. If it is restarted, all its children
restart.
44. protected override SupervisorStrategy SupervisorStrategy() {
// immer die gleiche Entscheidung
return new OneForOneStrategy(
maxNrOfRetries: 10,
withinTimeRange: TimeSpan.FromSeconds(30),
localOnlyDecider: exception =>
{
Console.WriteLine("*** Supervision: Restart");
return Directive.Restart;
}
);
}
shared nothing, almost
maximum isolation between services
no shared state (including persistence)
no shared domain model or logic
easy scale out & easy failover
share non-functional infrastructure code
network access, serialization, failover, …
----
These changes are happening because 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.
http://www.reactivemanifesto.org/
Elastizität (im Unterschied zu Skalierbarkeit)
Englisch: elasticity (in contrast to scalability)
Elastizität bedeutet, dass der Durchsatz eines Systems automatisch erhöht oder vermindert werden kann, um sich an sich verändernde Lastbedingungen anzupassen. Voraussetzung hierfür ist die Skalierbarkeit des Systems, damit der Durchsatz von vermehrten Ressourcen profitieren kann. Elastizität erweitert also den Begriff der Skalierbarkeit um automatisches Ressourcenmanagement.
Responsiveness =
React to users / clients in timely manner (lags, „the system is down“)
Avoid slow responses
often means: tied up resources in calling and called system
Disk IO, Out of Memory, …
slow systems aren‘t usable
a responsive System depends on Resilient and Elastic one
Responsiveness =
React to users / clients in timely manner (lags, „the system is down“)
Avoid slow responses
often means: tied up resources in calling and called system
Disk IO, Out of Memory, …
slow systems aren‘t usable
a responsive System depends on Resilient and Elastic one
Resilient =
A resilient system react to failures
it keeps processing transactions,even when there are:
transient impulses
persistent stresses or
component failures
disrupting normal processing
often meant by people that say stability
---
in realworld:
redundancy
supervisor
bulk head
delegation
low coupled components
---
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. 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.
Elastic =
A elastic system can allocate / deallocate resources for every indivdual component (service)dynamically to match demands
---
Elasticity is about resources (resources are constraint) [CPUs, Memory, VMs, …]
good Idea: share N resources between M applications
---
They achieve elasticity in a cost-effective way on commodity hardware and software platforms.
---
Vertikale Skalierung (scale up) -> become bigger
Horizontale Skalierung (scale out) -> become more
---
Scalability Haiku
Avoid all shared resources
if you can‘t avoid it: try to batch and never block
Abstraction
Thread vs. Task
Locking vs. Hiding & Proxying
Isolation and Abstraction
over Resources and State
with Message-Driven Architecture
Resilient =
A resilient system react to failures
it keeps processing transactions,even when there are:
transient impulses
persistent stresses or
component failures
disrupting normal processing
often meant by people that say stability
---
in realworld:
redundancy
supervisor
bulk head
delegation
low coupled components
---
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. 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.
Following Hewitt, Bishop, and Steiger's 1973 publication, Irene Greif developed an operational semantics for the Actor model as part of her doctoral research.[4] Two years later, Henry Baker and Hewitt published a set of axiomatic laws for Actor systems.[5][6] Other major milestones include William Clinger's 1981 dissertation introducing a denotational semantics based on power domains[3] and Gul Agha's 1985 dissertation which further developed a transition-based semantic model complementary to Clinger's.[7] This resulted in the full development of actor model theory.
CSP: Communicating Sequential Processes / Theoretical Communicating Sequential Processes (TCSP)
„Calculus of Communicating Systems“
„Algebra of Communicating Processes“
Pi-Kalkül
Following Hewitt, Bishop, and Steiger's 1973 publication, Irene Greif developed an operational semantics for the Actor model as part of her doctoral research.[4] Two years later, Henry Baker and Hewitt published a set of axiomatic laws for Actor systems.[5][6] Other major milestones include William Clinger's 1981 dissertation introducing a denotational semantics based on power domains[3] and Gul Agha's 1985 dissertation which further developed a transition-based semantic model complementary to Clinger's.[7] This resulted in the full development of actor model theory.
CSP: Communicating Sequential Processes / Theoretical Communicating Sequential Processes (TCSP)
„Calculus of Communicating Systems“
„Algebra of Communicating Processes“
Pi-Kalkül
Following Hewitt, Bishop, and Steiger's 1973 publication, Irene Greif developed an operational semantics for the Actor model as part of her doctoral research.[4] Two years later, Henry Baker and Hewitt published a set of axiomatic laws for Actor systems.[5][6] Other major milestones include William Clinger's 1981 dissertation introducing a denotational semantics based on power domains[3] and Gul Agha's 1985 dissertation which further developed a transition-based semantic model complementary to Clinger's.[7] This resulted in the full development of actor model theory.
CSP: Communicating Sequential Processes / Theoretical Communicating Sequential Processes (TCSP)
„Calculus of Communicating Systems“
„Algebra of Communicating Processes“
Pi-Kalkül
An actor is a computational entity that, in response to a message it receives, can concurrently:
send a finite number of messages to other actors;
create a finite number of new actors;
designate the behavior to be used for the next message it receives.
There is no assumed sequence to the above actions and they could be carried out in parallel.
Decoupling the sender from communications sent was a fundamental advance of the Actor model enablingasynchronous communication and control structures as patterns of passing messages.[9]
Recipients of messages are identified by address, sometimes called "mailing address". Thus an actor can only communicate with actors whose addresses it has. It can obtain those from a message it receives, or if the address is for an actor it has itself created.
The Actor model is characterized by inherent concurrency of computation within and among actors, dynamic creation of actors, inclusion of actor addresses in messages, and interaction only through direct asynchronousmessage passing with no restriction on message arrival order.
--------
functions, coroutines, processes, numbers, lists, databases, and devices should be represented as actors
An actor is a computational entity that, in response to a message it receives, can concurrently:
send a finite number of messages to other actors;
create a finite number of new actors;
designate the behavior to be used for the next message it receives.
There is no assumed sequence to the above actions and they could be carried out in parallel.
Decoupling the sender from communications sent was a fundamental advance of the Actor model enablingasynchronous communication and control structures as patterns of passing messages.[9]
Recipients of messages are identified by address, sometimes called "mailing address". Thus an actor can only communicate with actors whose addresses it has. It can obtain those from a message it receives, or if the address is for an actor it has itself created.
The Actor model is characterized by inherent concurrency of computation within and among actors, dynamic creation of actors, inclusion of actor addresses in messages, and interaction only through direct asynchronousmessage passing with no restriction on message arrival order.
--------
The actor theory requires that everything in the system, functions, coroutines, processes, numbers, lists, databases, and devices should be represented as actors, and be capable of receiving messages. This may seem at first a little dogmatic, but there are important practical benefits that arise from having a totally actor-oriented system.
Never think in terms of shared state, statevisibility, threads, locks, concurrent collections,thread notifications etc.
Low level concurrency plumbing BECOMESSIMPLE WORKFLOW - you only think about howmessages flow in the system
You get high CPU utilization, low latency, highthroughput and scalability - FOR FREE as part ofthe model
Proven and superior model for detecting andrecovering from errors
------
Actors are location transparent & distributable by design
Scale UP and OUT for free as part of the model
You get the PERFECT FABRIC for the CLOUD
elastic & dynamic
fault-tolerant & self-healing
adaptive load-balancing, cluster rebalancing & actor migration
build extremely loosely coupled and dynamic systems that can change and adapt at runtime
Never think in terms of shared state, statevisibility, threads, locks, concurrent collections,thread notifications etc.
Low level concurrency plumbing BECOMESSIMPLE WORKFLOW - you only think about howmessages flow in the system
You get high CPU utilization, low latency, highthroughput and scalability - FOR FREE as part ofthe model
Proven and superior model for detecting andrecovering from errors
------
Actors are location transparent & distributable by design
Scale UP and OUT for free as part of the model
You get the PERFECT FABRIC for the CLOUD
elastic & dynamic
fault-tolerant & self-healing
adaptive load-balancing, cluster rebalancing & actor migration
build extremely loosely coupled and dynamic systems that can change and adapt at runtime
Never think in terms of shared state, statevisibility, threads, locks, concurrent collections,thread notifications etc.
Low level concurrency plumbing BECOMESSIMPLE WORKFLOW - you only think about howmessages flow in the system
You get high CPU utilization, low latency, highthroughput and scalability - FOR FREE as part ofthe model
Proven and superior model for detecting andrecovering from errors
------
Actors are location transparent & distributable by design
Scale UP and OUT for free as part of the model
You get the PERFECT FABRIC for the CLOUD
elastic & dynamic
fault-tolerant & self-healing
adaptive load-balancing, cluster rebalancing & actor migration
build extremely loosely coupled and dynamic systems that can change and adapt at runtime
Transaction processing (Online Gaming, Finance/Banking, Trading, Statistics, Betting, Social Media, Telecom)
Scale up, scale out, fault-tolerance / HA
Service backend (any industry, any app)
Service REST, SOAP, Cometd, WebSockets etc Act as message hub / integration layer Scale up, scale out, fault-tolerance / HA
Concurrency/parallelism (any app)
Correct Simple to work with and understand Just add the jars to your existing JVM project (use Scala, Java, Groovy or JRuby)
Simulation
Master/Worker, Compute Grid, MapReduce etc.
Batch processing (any industry)
Camel integration to hook up with batch data sources Actors divide and conquer the batch workloads
Communications Hub (Telecom, Web media, Mobile media)
Scale up, scale out, fault-tolerance / HA
Gaming and Betting (MOM, online gaming, betting)
Scale up, scale out, fault-tolerance / HA
Business Intelligence/Data Mining/general purpose crunching
Scale up, scale out, fault-tolerance / HA
Complex Event Stream Processing
Scale up, scale out, fault-tolerance / HA
NOTE: When creating Props, ActorSystem, or ActorRef you will very rarely see the new keyword. These objects must be created through the factory methods built into Akka.NET. If you're using new you might be making a mistake.
NOTE: When creating Props, ActorSystem, or ActorRef you will very rarely see the new keyword. These objects must be created through the factory methods built into Akka.NET. If you're using new you might be making a mistake.
NOTE: When creating Props, ActorSystem, or ActorRef you will very rarely see the new keyword. These objects must be created through the factory methods built into Akka.NET. If you're using new you might be making a mistake.
With an UntypedActor, unhandled messages are not logged as unhandled unless you manually mark them as such, like so:
However, in a ReceiveActor—which we cover in Unit 2—unhandled messages are automatically sent to Unhandled so the logging is done for you.
Anmerkung: Messages SIND immutable
------
Messages Are Immutable
Time for a fun developer buzzword that will make you sound really smart:immutability!
So what’s an “immutable” object?
An immutable object is an object who’s state (i.e. the contents of its memory) cannot be modified once it’s been created.
If you’re a .NET developer, you’ve used the string class. Did you know that in .NETstring is an immutable object?
Let me give you an example: var myStr = "Hi!".ToLowerInvariant().Replace("!", "?");
In this example, the following occurs in this order:
.NET allocates a const string with the content Hi!” and then
ToLowerInvariant() is called, which copies the original “Hi!” string andmodifies the copy to become all lowercase and returns the modifiedcopy (which now reads as “hi!”) Then
.Replace(string,string) is called, which copies the “hi!” string returnedbyToLowerInvariant and modifies the copy to substitute ! with ? and returnsthe modified copy, with the final result reading as “hi?”
Since the original string is immutable, all of these operations had to make a copyof the string before they could make their changes.
Immutable messages are inherently thread-safe. No thread canmodify the content of an immutable message, so a second threadreceiving the original message doesn’t have to worry about aprevious thread altering the state in an unpredictable way.
You do talk to them, just not directly :) You have to talk to them via the intermediary of the ActorSystem.
It gives you better information to work with and messaging semantics. The ActorSystem wraps all messagesin anEnvelope that contains metadata about the message. This metadata is automatically unpacked andmade available in the context of your actor.
It allows "location transparency": this is a fancy way of saying that you don't have to worry about whichprocess or machine your actor lives in. Keeping track of all this is the system's job. This is essential forallowing remote actors, which is how you can scale an actor system up to handle massive amounts ofdata (e.g. have it work on multiple machines in a cluster). More on this later.
*CAUTION*: Do NOT call new MyActorClass() outside of Props and the ActorSystem to make an actor.
There are two key reasons actors exist in a hierarchy:
To atomize work and turn massive amounts of datainto manageable chunks
To contain errors and make the system resilient
Since parents supervise their children, this means that every actor has a supervisor, and every actor can also BE a supervisor.
/ - The Root Guardian
/user – Root Actor
Actor path == actor position in hierarchy
Here's the sequence of events when an error occurs:
Unhandled exception occurs in child actor (c1), which is supervised by its parent (b1).
c1 suspends operations.
The system sends a Failure message from c1 to b1, with the Exception that was raised.
b1 issues a directive to c1 telling it what to do.
Life goes on, and the affected part of the system heals itself without burning down the whole house.The critical thing to know here is that *whatever action is taken on a parent propagates to its children*. If a parent is halted, all its children halt. If it is restarted, all its children restart.Kittens and unicorns, handing out free ice cream and coffee to be enjoyed while relaxing on a pillowy rainbow. Yay!
----
Restart the child (default): this is the common case, and the default.
Stop the child: this permanently terminates the child actor.
Escalate the error (and stop itself): this is the parent saying "I don't know what to do! I'm gonna stop everything and ask MY parent!"
Resume processing (ignores the error): you generally won't use this. Ignore it for now.
Here's the sequence of events when an error occurs:
Unhandled exception occurs in child actor (c1), which is supervised by its parent (b1).
c1 suspends operations.
The system sends a Failure message from c1 to b1, with the Exception that was raised.
b1 issues a directive to c1 telling it what to do.
Life goes on, and the affected part of the system heals itself without burning down the whole house.The critical thing to know here is that *whatever action is taken on a parent propagates to its children*. If a parent is halted, all its children halt. If it is restarted, all its children restart.Kittens and unicorns, handing out free ice cream and coffee to be enjoyed while relaxing on a pillowy rainbow. Yay!
----
Restart the child (default): this is the common case, and the default.
Stop the child: this permanently terminates the child actor.
Escalate the error (and stop itself): this is the parent saying "I don't know what to do! I'm gonna stop everything and ask MY parent!"
Resume processing (ignores the error): you generally won't use this. Ignore it for now.