How to loosely couple modules in service oriented architecture
We're developing a total solution, and we've chosen service-oriented
architecture to loosen subsystems. However, now we have a problem.
When customer orders something, Order Subsystem is responsible to get that
order, and register it. However, there are some other modules which are
responsible too, in order registration process, and each module should do
something on it:
Customer Accounting module should check customer's balance, and prevent
order registration if there is not enough money in customer's account.
Asset Management module should increase/decrease customer's assets
Rule Engine should apply some business rules dynamically on it (like
preventing a specific customer, or notifying an operator, etc.)
CRM should view customer's history, and give good customers some discount
...
Right now, we're doing it this way:
public void RegisterOrder(Order order)
{
RuleEngineService.ApplyBusinessRules(order);
// some code here
CrmService.GiveDiscountIfApplicable(order);
// some code here
CustomerAccountingService.CheckBalance(order);
// some code here
AssetManagementService.ChangeAssetCount(order);
// some code here
}
This means that if we add another subsystem (module) that needs to do
something on order, we have to recompile the code of our OMS (Order
Management System) to support it. Also we're coupled to some extent to
other subsystems here, and if one of them fail, this registration process
fails.
One way of making this piece of code dynamic and loosely coupled is to use
interfaces or contracts, like:
public void RegisterOrder(Order order)
{
// Finding a list of all IOrderProcessors.
// Looping over each, calling orderProcessor.Process(order);
}
However, it has two problems:
We can't use interfaces over SOAP and HTTP (we don't have access to other
subsystems' DLL files)
Those need to run in a specified order (rule engine the first one)
What should we do here? What are the known patterns and practices?
No comments:
Post a Comment