WCF – Decisione dei parametri di progettazione

Sto progettando un servizio per FundManagement. Il servizio FundManagement ha un’operazione denominata “UpdateFundApprovalDate (fondo FundDTO)”. Questa operazione aggiornerà il record della tabella del fondo con la data di approvazione per l’ID finanziamento. Il servizio verrà utilizzato da un client “FundManagementUI”.

Esiste una regola aziendale che la data di approvazione non dovrebbe essere aggiornata se il rinnovo del contratto è in corso.

Esiste un servizio di rinnovo separato. Il servizio di rinnovo utilizza i dati della tabella di rinnovo (che contiene ID di finanziamento). La struttura della tabella di rinnovo è (RenewalID, FundingID, RenewalStartDate, Renewal CompletionDate, RenewalStatus). Esiste un’operazione di servizio denominata “elenco pubblico GetInProgressRenewal (fondo FundDTO)”.

Un punto importante è qui. Sebbene entrambi i servizi stiano utilizzando lo stesso database, i rinnovi “In corso” dovrebbero essere decisi dal servizio Rinnovo. Può essere basato sullo stato o sulla data di completamento del record di rinnovo. Spetta al servizio di rinnovo decidere la logica aziendale per i rinnovi “In corso”. Il servizio FundManagement non rivendica la proprietà su tale logica.

  1. Qual è il principio / modello SOA che spiega il comportamento di cui sopra? (Uso del servizio di rinnovo per determinare i rinnovi “in corso”, sebbene sussista il rischio che il servizio di rinnovo possa modificare la logica in base ai propri interessi). Quali sono le linee guida su tali scenari?

  2. Avete qualche suggerimento per gli articoli che trattano di tali criteri di progettazione?

  3. All’interno del servizio FundManagement, chi dovrebbe essere responsabile della convalida dell’elenco NULL dei rinnovi restituiti? Dove deve avvenire questa convalida all’interno del codice del metodo di funzionamento del servizio o all’interno del FundBusinessLayer (chi chiama il servizio)?

Nota: qui la SOA sarà implementata usando WCF e le classi di business saranno sviluppate usando C #.

LETTURA:

  1. SOA / WCF che sezionano i confini del sistema e del servizio

In questo caso, non utilizzerei i servizi esistenti nel servizio di rinnovo, come tu dici che potrebbero cambiare.

Seguo il principio che nei servizi SOA dovrebbe avere un significato aziendale.

Creo quindi una nuova operazione: IsContractRenewalInProgress . Ciò elimina la necessità di pensare a chi dovrebbe essere responsabile per la convalida che l’elenco dei rinnovi restituiti sia NULL. Ancora più importante che la lista sia NULL significa che non ci sono rinnovi contrattuali in corso.

L’ UpdateFundApprovalDate quindi chiamerebbe e controllerebbe il risultato di IsContractRenewalInProgress , prima di apportare qualsiasi modifica.

IsContractRenewalInProgress deve essere nel servizio di rinnovo, poiché è il servizio di rinnovo che possiede i dati e la logica di business a sapere quando è in corso un rinnovo del contratto.

Qualsiasi elaborazione di informazioni finanziarie ruoterà attorno a un aspetto chiave: l’attenta gestione dello stato.

Prova a creare un modello di stato per il tuo sistema di contratti e documenta attentamente quali stati possono essere raggiunti da un determinato stato e quale elaborazione deve avvenire per passare da uno stato valido a un altro stato valido. Quindi, assicurarsi che qualsiasi passaggio da uno stato a un altro si verifichi in una transazione in modo che il mancato raggiungimento dello stato successivo restituisca il contratto al suo stato precedente.

Potresti scoprire che renderà più facile per te se granularizzi i tuoi stati in modo che riflettano l’elaborazione corrente – cioè anziché RIVEDUTO, RINNOVATO, APPROVATO, RIFIUTATO, FINANZIATO, hai anche stati che indicano che un contratto è in uno stato di stream – cioè è in fase di revisione in questo momento, è stato finanziato in questo momento, ecc. In questo modo il sistema può identificare i contratti che vengono triggersmente elaborati in questo momento. Inoltre, consente di identificare facilmente cosa stava succedendo se l’ambiente si arrestasse improvvisamente senza un rollback di successo.

Assicurarsi di disporre di un solo servizio che aggiorna lo stato di un contratto e che questo servizio blocchi il contratto durante l’aggiornamento. Tutti gli altri processi utilizzerebbero questo servizio per eseguire i cambiamenti di stato richiesti.

Quindi, nel tuo caso specifico, l’UpdateFundApprovalDate (fondo FundDTO) verrebbe eseguito solo su contratti il ​​cui stato era PENDING_FUNDING e probabilmente sarebbe solo una parte dell’elaborazione totale, in ogni caso, quando il processo che esegue il tuo updateFundApprovalDate (FundDTO fund ), lo stato del contratto sarà FINANZIATO se ha avuto esito positivo o se il tentativo di finanziamento è fallito, tutte le modifiche saranno state annullate con conseguente stato del contratto originale di PENDING_FUNDING. Se il sistema si è arrestato in modo anomalo, lo stato del contratto potrebbe essere lasciato nello stato di elaborazione corrente, con uno stato simile a FONDI. Lo stesso FINANZIAMENTO non sarebbe uno stato valido nel tuo modello statale: è uno stato provvisorio. Tutti i processi inizieranno a elaborare un contratto solo in uno stato valido, mai in stati intermedi.

Per i pattern che potrebbero essere usati in questa situazione, guarda i pattern della macchina statale.