1

I am designing a service for FundManagement. The FundManagement Service has an operation named “UpdateFundApprovalDate(FundDTO fund)”. This operation will update the fund table record with approval date for the fundingID. The service will be used by a “FundManagementUI” client.

There is a business rule that the approval date should not be updated if contract renewal is in progress.

There is a separate Renewal Service. The Renewal service uses data from Renewal table (which has Funding ID in it). Structure of Renewal table is (RenewalID, FundingID, RenewalStartDate, Renewal CompletionDate, RenewalStatus). There is a service operation named “public List GetInProgressRenewal(FundDTO fund)”.

One important point is here. Though both the services are using the same database, the “In Progress” renewals should be decided by the Renewal service. It can be based on status or completion date of renewal record. It is upto the Renewal Service to decide the business logic for “In Progress” renewals. The FundManagement Service claims no ownership on that logic.

  1. What is the SOA principle/ pattern that explains the above behavior? (Use of Renewal Service for determining the “In Progress” renewals though there is a risk that the Renewal Service can change the logic on its own interest.). What are the guidelines on such scenarios?

  2. Do you have any suggestions for any articles that deals with such design decisons?

  3. Inside the FundManagement Service, who should be responsible for validating that the list of renewals returned is NULL? Where this validation should happen inside service operation method code or inside the FundBusinessLayer (who the service calls)?

Note: Here the SOA will be implemented using WCF and the business classess will be dlls developed using C#.

READING:

  1. SOA/WCF dissecting the system & service boundaries
Community
  • 1
  • 1
LCJ
  • 22,196
  • 67
  • 260
  • 418
  • Both services appear to relate on the same object: FundDTO. Why are 'FundManagement' and 'Renewal' separate services? – Phil Degenhardt Mar 04 '12 at 21:47
  • @degorolls Renewal service has major responsibility with RenewalDTO. However it need to answer renewals for a funding - hence accepting a FundDTO. Please see the Renewal table (RenewalID, FundingID, RenewalStartDate, Renewal CompletionDate, RenewalStatus) – LCJ Mar 05 '12 at 05:14

2 Answers2

4

In this case I would not use the existing services in the Renewal Service, like you say they could change.

I follow the principle that in SOA services should have a business meaning.

I would therefore create a new operation: IsContractRenewalInProgress. This removes the need to think about who should be responsible for validating that the list of renewals returned is NULL. More importantly that the list being NULL means that there are no contract renewals in progress.

The UpdateFundApprovalDate would then call and check the result of IsContractRenewalInProgress, before making any changes.

IsContractRenewalInProgress should be in the Renewal Service, since it is the Renewal Service that owns the data and the business logic to know when a contract renewal is in progress.

Shiraz Bhaiji
  • 64,065
  • 34
  • 143
  • 252
  • Thanks. Do you mean IsContractRenewalInProgress should be part of FundManagement service? Businesswise that is not correct, right? FundManagement is no way the ownwer of such decisions - its Renewal Service – LCJ Mar 04 '12 at 11:36
  • Thanks. One question- IsContractRenewalInProgress will make it more fine grained than GetInProgressRenewal, isn't it? Is it good to increase the fineness of granularity? – LCJ Mar 06 '12 at 07:03
  • You have to balance the granuality, in this case I think that it is correct to have IsContractRenewalInProgress – Shiraz Bhaiji Mar 06 '12 at 18:37
  • OK. One more question. SHould the SL or BL (of FundManagement service) should call the Renewal Service's IsContractRenewalInProgress operation for validation? – LCJ Mar 06 '12 at 18:45
  • 1
    the BL since it is a business rule that determines that it should be called – Shiraz Bhaiji Mar 23 '12 at 08:40
1

Any processing of financial information is going to revolve around one key facet - the careful management of status.

Try creating a state model for your contract system, and carefully document what states can be reached from a given state, and what processing has to occur in order to move from one valid state to another valid state. Then, ensure that any move from one state to another occurs in a transaction such that a failure to achieve the next state returns the contract to its previous state.

You may find it will make it easier for you if you granularize your states to reflect current processing - i.e. rather than REVIEWED, RENEWED, APPROVED, REJECTED, FUNDED, also have states that are set to indicate that a contract is in a state of flux - i.e. it is being reviewed right now, it is being funded right now, etc. In this way the system can identify the contracts that are actively being processed right now. It also makes it easy to identify what was going on if the environment were to suddenly crashes without a successful rollback.

Make sure that you have only one service that updates the state of a contract, and that this service locks the contract during the update. All other processes would use this service to perform the required status changes.

So, in your specific case, the UpdateFundApprovalDate(FundDTO fund) would only be run on contracts whose status was PENDING_FUNDING, and would probably only be a part of the total processing - whatever the case, when the process that runs your updateFundApprovalDate(FundDTO fund) completes, the contract status will be either FUNDED if it was successful - or if the attempt to fund failed, all changes will have been rolled back resulting in the original contract status of PENDING_FUNDING. If the system crashed, the contract status could potentially be left in the current processing state, having a status something like FUNDING. FUNDING itself would not be a valid state in your state model - it is an interim state. All processes will only begin processing a contract in a valid state, never interim states.

For patterns which could be used in this situation, look at State Machine patterns.

Rodney P. Barbati
  • 1,883
  • 24
  • 18