Variations in event-driven architecture

Find out if mediator or broker topology is right for you.

Editor’s note: this is an advance excerpt from Chapter 2 of the forthcoming Software Architecture Patterns by Mark Richards. This report looks at the patterns that define the basic characteristics and behavior of highly scalable and highly agile applications, and will be made available to download in advance of our Software Architecture Conference happening March 16-19 in Boston.

Coming soon.

Available now!

The event-driven architecture pattern is a popular distributed asynchronous architecture pattern used to produce highly scalable applications. It is also highly adaptable and can be used for both small and large, complex applications. The pattern is made up of highly decoupled, single-purpose event processing components that asynchronously receive and process events. 

The event-driven architecture pattern consists of two main topologies, the mediator and the broker. The mediator topology is commonly used when you need to orchestrate multiple steps within an event through a central mediator, whereas the broker topology is used when you want to chain events together without the use of a central mediator. Because the architecture characteristics and implementation strategies differ between these two topologies, it is important to understand each one to know which is best suited for your particular situation.

Read more…

Comment: 1

Software engineers must continuously learn and integrate

Four ways programmers can thrive in their careers.

Software engineers: themes to watch in software architecture, open source culture and code, data, mobile and the Internet of Things

As O’Reilly continues to build and assess our programming content ecosystem — now more than 30 years in the making — we have gone from covering a few key languages, operating systems, and concepts to a diversification of topics that would have made an editor’s head spin in the 1980s. Our goal, however, remains the same: to continue to provide practical content from experts who help you do your job. An important piece of that goal is to keep you informed as we interpret the trends on the horizon. What follows are a few of the core themes we are focusing on at the moment. Expect these to evolve and change with the speed of innovation.

You can also stay in the loop on the latest analysis and developments through our weekly Programming newsletter.

Actually be a software engineer

The term “full-stack” first emerged in a 2008 blog post (the original post is no longer available, but an archive is published here). The term perhaps reached its canonical definition in a post by Facebook engineer Carlos Bueno. He wrote:

“A ‘full-stack programmer’ is a generalist, someone who can create a non-trivial application by themselves. People who develop broad skills also tend to develop a good mental model of how different layers of a system behave.“

Whether you are striving to be a full-stack programmer, a T-shaped engineer, or you choose to rebuff those terms entirely as mere marketing, what now floats around as a “full-stack developer” definition is incomplete. Read more…

Comments: 2

Elvis has left the ivory tower

Pragmatism now rules in team structure, technology, engineering practices, and operational innovation.

Karnakpanorama_b

Ancient history in computer science (2004) provides a gem about the personas that Microsoft envisioned as users of the development environment Visual Studio. They developed three:

  • Mort, the opportunistic developer, likes to create quick-working solutions for immediate problems. He focuses on productivity and learns as needed.
  • Elvis, the pragmatic programmer, likes to create long-lasting solutions addressing the problem domain, and learning while working on the solution.
  • Einstein, the paranoid programmer, likes to create the most efficient solution to a given problem and typically learns in advance before working on the solution.

These designations received a lot of negative press, particularly around the Mort persona, but I want to focus on Einstein and Elvis.

Formerly, software architects exemplified the Einstein persona: isolated from day-to-day development details, focused on building abstractions and frameworks. The isolation is so common that it spawned its own “Ivory Tower Architect” derogatory phrase. But the realities of building systems that scale as fast as the business does invalidates that approach. Now, Elvis, the pragmatic developer, has ascended to architect while simultaneously descending from the Ivory Tower. Modern architects don’t have the luxury of isolation from the gritty realities of software development today. Pragmatism now rules in team structure, technology, engineering practices, and operational innovation because:

Read more…

Comment: 1

Java 8 streams API and parallelism

Leveraging intermediate and terminal operators to process large collections.

In the last post in this series, we learned about functional interfaces and lambdas. In particular, we looked at the ITrade functional interface, and filtered a collection of trades to generate a specific value. Prior to the feature updates made available in Java 8, running bulky operations on collections at the same time was ineffective and often cumbersome. They were restricted from performing efficient parallel processing due to the inherent explicit iteration that was being used. There was no easy way of splitting a collection to apply a piece of functionality on individual elements that then ran on multi-core machine architectures — that is, until the addition of Java 8’s Streams API.

Read more…

Comment

Using the command pattern with lambda expressions

Reduce boilerplate and make the intent of your code more obvious.

As Java developers we’re all familiar with the concept of Design Patterns. These are codified template solutions to problems that we may encounter when developing. We’re probably also familiar with being told by our functional programming brethren that design patterns are just “missing” language features. So the question now arises, with the introduction of lambda expressions in Java 8 and a more functional style of programming, how do design patterns change? In this article we’ll be looking at the command pattern.

A command object is an object that encapsulates all the information required to call another method later. The command pattern is a way of using this object in order to write generic code that sequences and executes methods based on runtime decisions.

There are four classes that take part in the command pattern:

  • Receiver – Performs the actual work
  • Command – Encapsulates all the information required to call the receiver
  • Invoker – Controls the sequencing and execution of one or more commands
  • Client – Creates concrete command instances

invoker

Let’s look at a concrete example of the command pattern and see how it improves with lambda expressions. Read more…

Comment

Where apps end and the system begins

Exploring the system calls and control flow that underpin high-level languages.

Editor’s note: Sometimes we can forget how important it is to truly understand how a system works, and how the nuts and bolts affect our everyday activities. Marty Kalin asks us to dive a little deeper and strengthen our computational thinking abilities.

It’s clear that applications need system resources to execute: a processor, memory, and usually I/O devices such as the keyboard and screen. It’s less clear how applications gain access to these shared resources, which are under operating system (OS) control. The OS, like any good manager, is efficient and unobtrusive as it handles resource requests from applications. Let’s take a look at how applications interact with the OS, in both routine and dramatic fashion.

Consider what happens when a print statement executes. Here’s a Ruby example:

The Ruby puts statement wraps a call to a high-level I/O function in the standard C library (in this case, printf), which acts as the interface between resource-requesting applications and resource-granting OS routines. In this example, the screen is the requested resource. The standard library interacts seamlessly with the OS, which also is written in C with some assembly language. The library function printf is high-level because, as the f in the name indicates, the function can format the bytes to be written as integers, floating-point values, and character strings such as Hello, world!. In systems-speak, the Ruby application and the C library function execute in user space, which does not bestow the rights and privileges needed to control system resources such as the screen.

Read more…

Comment