CODEWITHSUNDEEP
architecturedistributed
newtogit
newtogit

Reputation: 553

Architecture: Notification mechanism

I am just considering several architectural options for a standard software systems. Perhaps you'd like to share your opinions.

System: We have a business logic component with an underlying database. Until today this logic component was used only by one client and thus UI and Logic and Data layer all have been in one executable. (Tool A)

Now, the program has such cool features that another, already existing tool should use it (Tool B). Tool B shall also use (or at least display) some of the data of Tool A but it also keeps its own data storage. Our solution approach is simple: We split Tool A. The business logic gets a service interface (probably web services, RESTful or not). Then tool B can access the business logic of Tool A, get data, execute calculations, whatever.

Now, if Tool B shows data of Tool A, it would be nice if it would be notified of data changes in Tool A. Our service interface is nice but a one-way story (if you don't do tricks like keeping asynchronous calls open until an event occurs).

We see several options:

We don't like b). Too slow and Tool A would need a means to determine the changes for each client. c) has the overhead of introducing a new component. a) Will tightly couple the two tools.

Further information: We will have a central datastorage (+ our business logic component) on one machine. On other machines may be the clients (up to 20, let's say. Not 100, not 1000, not 10000). It is a system from one vendor. We don't have to be prepared for lots of third party tools who want to use the events (that would be a strong indicator for solution c)).

Questions: i) What other options than a)-c) do we have? ii) Which way would you go and why?

Upvotes: 2

Views: 182

Answers (1)

Tom Anderson
Tom Anderson

Reputation: 47243

(i) I can't think of anything off the top of my head.

(ii) Option (c), using something simple like 0mq

Upvotes: 1

Related Questions