3

I have a few questions regarding the three architecture patterns mentioned in the title. I'm having a little trouble trying to understand the advantages any one of them has over the others, especially the first two.

So I'll start each one off with a description of what I understand so far and then I'll ask questions below

Service Oriented Architecture

  • involves a client, a service directory and single services
  • the services register at the service directory
  • the client can request a service by providing a service specification to the directory. The service directory finds a matching service and connects client and service, so they can communicate directly

Client-Server-Dispatcher

Here's where my troubles start. As I understand it's basically the same as SOA. Servers register at the Dispatcher, the Client requests a connection and the Dispatcher connects Server and Client.

What are the differences and what are the advantages over SOA or the other way around? Is the only difference the physical distribution of the components?

Broker

In this pattern the client only communicates with a Broker. The client sends a request to the Broker. The Broker knows components that can handle each request and returns the result to the client. I'm thinking this works pretty much like the Facade Design Pattern just on a system with distributed components. Is this a fitting analogy?

The lecture that introduced me to these patterns specifically mentioned that the Broker could be a Single Point of Failure. This was not mentioned for the Service Directory in SOA, but would that not be a SPoF as well? I was thinking the same for the Dispatcher, but there it was mentioned that a system could have multiple Dispatchers. Is this not true for Brokers and Service Directories or did my Uni just forget to mention this?

2

Broker

A broker pattern is the easiest pattern / architecture to separate here. A broker component is simply an component within a distributed system tasked with coordinating communication between other components. The system at large can be synchronous (a request that waits for a response) or asychronous (a message that receives a response later or never). A broker pattern is simply system that uses brokers for coorindating its communication. Generally in these type of systems you don't use the term client - server but rather producer - consumer. Most often I see this implemented in asychronous environments or in systems where the producer (the thing sending the message) doesn't know anything about the signature of the consumer, or when the producer needs to fan out to many consumers.

client server dispatcher

A client server dispatcher pattern has three main components. The client can be thought of as the source of the request and the server is the destination. In between the client and server you have a dispatcher which creates a channel for requests to navigate to the server. In this way you can abstract the physical location of the server endpoint. This is almost always a request response model and the reason I see this implemented most often is to maintain the ability to do things that swap out physical endpoints for other endpoints for performance reasons, or to allow versioning or API endpoints.

service oriented architecture

Unlike the other two, service oriented architecture is not a pattern but rather an architecture. An large SOA environment will likely have client server dispatcher patterns and also broker and/or pub sub patterns. In SOA, a service is suppose to represent a single business activity, be a black box to the client (except possibly for the services signature), be self contained, but may consist of other underlying services.

This one is a bit more abstract so I will give you a use case.

In an SOA environment I work with we have a business process that assigns credits to be approved to sales people based on where that company is geographically located. The workflow process that assigns the work has both functionality find the salesman for a company but geographical location. Instead we have an enterprise service bus that sits on a completely separate server. This *service bus" sits behind a reverse proxy that distributes the requests to different servers running the same service bus based on current load.

In this way you could way that we are using a client server dispatcher model where the workflow is the client, the reverse proxy is the dispatcher, and the final service bus is the server. However, once the request gets to the final destination it then is routed to one of several hundred small, individual "applications" (or services) that is tasked with doing one thing and one thing only. In this case the service takes in a company id and returns a salesman.

Once it gets to the service that service then reaches out to various web services (our erp system, our SugarCRM system, etc) and returns the username of the salesman. The client has no idea about the logic in the service and moreover doesn't even really know that service exists. It only knows to send in this data with this "key" and then takes the response and assigns the unit of work to whatever the value of the response was. Similarly the service has no idea what the client is doing with this information or even that the client exists.

In this regard we have very very loose coupling. The client and service are abstracted by multiple levels of abstraction. This service doesn't care if the client is expecting a response immediately (reauest response) or if it's a pub sub or anything.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.