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”.
ServiceMatrix stays code-centric by using code generation and partial classes. Here is a typical example of a service method created by ServiceMatrix.
namespace OnlineSales.Sales
{
public partial class SubmitOrderHandler : IHandleMessages<SubmitOrder>
{
public void Handle(SubmitOrder message)
{
// Handle message on partial class
this.HandleImplementation(message);
}
partial void HandleImplementation(SubmitOrder message);
public IBus Bus { get; set; }
}
}
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.