SOA: Joining data across multiple services

Question

Imagine we have 2 services: Product and Order. Based on my understanding of SOA, I know that each service can have its own data store (a separate database, or a group of tables in the same database). But no Service is allowed to touch the data store of another Service directly.

Now, imagine we have stored the product and order data independently inside Product and Order Services. In the Order Service, we can identify products by their ID.

My question is: With this architecture, how can I display the list of orders and product details on the "same" page?

My understanding is that I should get the list of OrderItems from OrderService. Each OrderItem has a ProductID. Now, if I make a separate call to ProductService to retrieve the details about each Product, that would be very inefficient.

How would you approach this problem?

Cheers, Mosh

Answer 1

I did some research and found 2 different solutions for this.

1- Services can cache data of other Services locally. But this requires a pub/sub mechanism, so any changes in the source of the data should be published so the subscribing Services can update their local cache. This is costly to implement, but is the fastest solution because the Service has the required data locally. It also increases the availability of a Service by preventing it from being dependent to the data of other Services. In other words, if the other Service is not available, it can still do its job by its cache data.

2- Alternatively, a Service can query a "list" of objects from another Service by supplying a list of identifiers. This prevents a separate call to be made to the target service to get the details of a given object. This is easier to implement but performance-wise, is not as fast as solution 1. Also, in case the target Service is not available, the source Service cannot do its job.

Hope this helps others who have come across this issue.

Mosh

Answer 2

DB integration (which is really what you are talking about when two services share a table in a DB) is wrong at so many levels! It completely breaks some of the major principles of software engineering

loose coupling, encapsulation separation of concerns

A service should be (to earn that name) completely independent, namely:

1. it must not rely on others to ensure the consistency and coherence of its data
2. it must not rely on others to guaranty the security of its data
3. it must not depend on external implementations (only interfaces)

Two services that share data at the DB level are unable to guarantee any of the former.

The fact that you "control" both services is completely irrelevant. Today you control... tomorrow you might want to outsource or replace one of the services. That should be as simple as ensuring the proper interfaces are in place.

Imagine both services that share a table with some field (varchar) in it. Now one service needs to change that field to numeric... bang the other service stops functioning - loose coupling goes down the drain.

Most of the time the trick lies in properly defining the service scope and clearly stipulating what a service do and what it doesn't do. You should also avoid turning everything into a service. Set your service granularity to high and services will start popping everywhere and integration headaches will escalate.

That being said, there are some situations where data integration between services poses some challenges. The main premiss do, should always be - data can belong only to one service. Data is intrinsically tied to business logic that affects data consistency and coherence and as such there should never be more than one service controlling any given data.