SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Microservices, SOA and Service Broker

By Phil Factor,

The idea of a 'Microservice' isn't new. It is possible to argue that it is different from Service-Oriented Architecture, or any other loosely coupled, service-centric distributed architecture, but any real difference is academic.

What underlies any workable distributed system is a reliable and secure way of exchanging information between each self-contained component or service. The important thing is that a message can never get lost. A network is intrinsically fickle; you can't rely on it and in certain cases you need processes to be transactional, so that the component processes either fail and rollback, as a unit, or succeed and commit together. Without the bedrock of robust messaging and transactionality, implementing services in this way becomes a death-march, whatever name you give them. You can, to an extent, fudge an object request broker (ORB), but reliable queueing and network messaging is necessary before you can start.

Microsoft was rather slow to provide reliable support for service-oriented architectures. After some spectacular failures in the early 1990s, Microsoft came up with reasonably reliable solutions to the problem of implementing asynchronous distributed applications, using Microsoft Message Queue Server (MSMQ) and Microsoft Transaction Server (MTS). The problem with MSMQ was that a message could be lost, so it was of limited use for financial systems. This application-oriented approach has evolved and improved since then into the Windows Communication Foundation (WCF), which provides the means of supporting multi-platform services.

However, the real breakthrough for support of service-oriented architectures came with the release of SQL Server 2005, which provided Service Broker. It is not just for distributed services; its ability to do asynchronous, queued database actions is very useful, even if the database application isn't distributed.

SQL Server with Service Broker remains the most robust and secure way of implementing a service-oriented architecture on Windows servers. It may be a conservative approach but it works fine and is being actively developed. Maybe a happy result of the recent revival in interest in 'micro' service-oriented architectures will be a well-deserved increase in use of the product.

Phil Factor.

Total article views: 149 | Views in the last 30 days: 1
Related Articles

Configuring Service Broker Architecture

Learn how to configure technically reliable, consistent, robust, efficient, asynchronous message qu...


Architecture for "Reporting Services"

Architecture for "Reporting Services"


Service Oriented Architecture

Is anyone currently planning or working on building a system using either SQL Server 2000 or 2005 th...


Service Application Architecture

Hello Friends, As discussed in my previous blog the new architecture of Service Application in 20...


SQL Server Service Broker – Service Architecture

This post is part of a series on this blog that will explore SQL Server Service Broker, a native mes...