Circular dependency in SOA

Question

I assume this is a general question, but I will try to describe my current problem.

I have a basic service, let's call it "CoreService", which provides that I would say "basic" functions: process data in the database (we have a centralized database in our applications). There are a number of other applications, some of which have their own database for local purposes. And there is one simple "NotificationService". Its purpose is to send messages to various subscribers.

Usually this NotificationService is called from "ExternalWorld" and sends notifications to various services (among them "CoreService").

Today I saw the need to name "NotificationService" from "CoreService".

It bothers me that I introduced a cyclical dependency: NotificationService should know how to send messages to each service (including "CoreService", so it needs to know about the "CoreService" interface, and as a result, it needs to refer to "CoreService") and "CoreService" must send messages to the "NotificationService" (so it also needs to be referenced) ... Circular dependency ...

Question: How should we build our architecture to solve this problem?

Thanks a lot!

Answer 1

When I finished writing the question, I found some idea:

Inside "NotificationService" I need to define 2 interfaces "IMessagesSender" and "IMessagesReceiver".

• Each subscriber must implement "IMessagesReceiver", and his address must be recorded in the configuration file "NotificationService";
• Each message sender must use a wsdl file that describes the IMessageSender interface and must have an entry in its own configuration file with the NotificationService address.

In this case, we will not remove the cyclic dependency, but this seems like a solution ...

Currently, it’s hard for me to say what is the best way, what are the pros and cons of this solution, so please comment on this (and / or suggest a better option).

Thanks a lot!

Answer 2

You need to switch from point-to-point to pick. The broker will now commit to link the source to the destination and send / post messages accordingly (ESB calls me in the head).

Explanation

You do not directly refer to a CoreService from a NotificationService, or vice versa. Both will subscribe to the topic of their interest. For example, a CoreService will post events for a topic that NotificationService will sign (and a CoreService will also subscribe for a topic that NotificationService will post ). Then the responsibility of the topic handler (messaging system or ESB, etc.) lies with the forwarding of events to all subscribers to this topic. Thus, the services are loosely connected from each other and do not even know about their existence.

Currently, you are using NotificationService as a mediator / ESB, thereby making it as an infrastructure service if you will, and therefore problems like circular dependencies, etc. This is no longer a business service.