Featured in Architecture & Design

Monal Daxini presents a blueprint for streaming data architectures and a review of desirable features of a streaming engine. He also talks about streaming application patterns and anti-patterns, and use cases and concrete examples using Apache Flink.

Featured in AI, ML & Data Engineering

Joy Gao talks about how database streaming is essential to WePay's infrastructure and the many functions that database streaming serves. She provides information on how the database streaming infrastructure was created & managed so that others can leverage their work to develop their own database streaming solutions. She goes over challenges faced with streaming peer-to-peer distributed databases.

Designing SOA Systems with ServiceMatrix

The Particular Service Platform has four headline components: ServiceMatrix, ServiceInsight, ServicePulse, and the well-respected NServiceBus. Over the next few weeks, we’ll be looking at each in turn starting with ServiceMatrix, their SOA design tool.

Service Matrix can be thought of as a CASE tool for SOA architectures. You start by using a visual designer to create endpoints and messages. The end points can be based on ASP.NET MVC or NServiceBus Hosts.

We spoke with Udi Dahan, CEO of Particular Software, about how he sees the product,

You can think about ServiceMatrix as a force multiplier for team leads and architects.

By having a graphical representation of endpoints, messages, processing logic, and the routing between them, this makes it much easier to make sure everyone on the team knows how their piece of the system works with everything else and for the leads to know that the team haven’t drifted away from the original design.

ServiceMatrix also automates a lot of the repetitive steps of creating new endpoints, making it much easier for teams to consistently follow best practices, all the while keeping all of that in extensible T4 templates that architects can tweak.

InfoQ: Visual tools such as BizTalk tend to have a bad reputation for making anything that is non-trivial significantly more difficult. How does ServiceMatrix avoid that problem?

I think the way that we avoid falling into many of the issues that other visual tools (like BizTalk) run into is that the platform is based on NServiceBus – a purely code-centric development framework and runtime. For years we’ve been honing and improving on NServiceBus so that developers have the most friction-free coding experience.

In doing that, we uncovered certain areas that were better handled visually – like the routing of messages between endpoints. Other things we found was that when people wanted to choose a common error or audit queue for their system, they had to either manually make sure to set that up for every new endpoint they created or to build some infrastructure to get that set by default. These were opportunities for us to provide global settings in ServiceMatrix which would then be automatically applied.

In some cases, what we found when working on ServiceMatrix was that by making certain improvements to NServiceBus, the UI in ServiceMatrix could be simplified even further.

In short, by taking a platform perspective (rather than just a Visual/code-generation perspective) we’re hoping to strike the right balance between doing as little as possible and as much as necessary, eventually reaching that elusive state – “not when there is nothing more to add, but when there is nothing left to take away”.

This code would be managed by ServiceMatrix itself; the developer is responsible for implementing the partial method HandleImplementation. Dependency injection is important part of this pattern. In order to support outgoing messages, a reference to the service bus is exposed via the Bus property.

By default message handlers are stateless. If you want something more sophisticated with support for long running operations then you need to look into NServiceBus Sagas.

Any process that involves multiple network calls (or messages sent and received) has an interim state. That state may be kept in memory, persisted to disk, or stored in a distributed cache; it may be as simple as 'Response 1 received, pending response 2', but the state exists.

By default, NServiceBus stores your sagas in RavenDB. The schema-less nature of document databases makes them a perfect fit for saga storage where each saga instance is persisted as a single document. There is also support for relational databases using NHibernate . NHibernate support is located in the NServiceBus.NHibernate assembly. You can, as always, swap out these technologies, by implementing the IPersistSagas interface.

When ServiceMatrix generates a handler for a saga, it injects a Data property for handling saga related information as well as methods such as MarkAsComplete to manipulate lifecycle.

ServiceMatrix is licensed as part of the Particular Service Platform. Pricing is dependent on the deployment model and either the number of nodes or developers.