Facciamo parte di un'implementazione SOA.
Pubblichiamo eventi tramite il bus aziendale per determinate modifiche nel nostro sistema.
Gli architetti qui hanno consigliato, tuttavia, che alcune modifiche di massa ai dati dovrebbero passare attraverso un file flat (generato dal nostro sistema) e gestite (spostate tra i server) dal middleware, perché vogliono evitare di sovraccaricare il bus con i dati. (Sarebbe possibile per noi pubblicare un singolo evento contenente tutte le modifiche rispetto a molti singoli eventi, che si comporterebbero molto meglio, ma per qualche motivo non lo vogliono).
Più recentemente, è emersa una contesa su un listino prezzi che produciamo. Il requisito originale per noi era quello di produrre un file flat su base giornaliera (che sarebbe molto più semplice della comunicazione delle modifiche dei prezzi in tempo reale). In questo scenario, abbiamo contrastato i requisiti del sistema dei consumatori per adattare i dati in un modo specifico. La nostra argomentazione è che in un contesto SOA, il nostro output dovrebbe essere indipendente dal consumatore, quindi fintanto che contiene i dati necessari, può essere trasformato dal middleware nel formato di destinazione richiesto.
Ora, tuttavia, l'architettura è di nuovo intervenuta, dicendo che pubblicare un listino prezzi è un evento che potrebbe / dovrebbe passare attraverso l'autobus. Non siamo sicuri che siamo d'accordo con questo, e perché, nel caso di modifiche collettive di cui sopra, è accettabile un trasferimento di file che aggira efficacemente il bus.
Credo che la mia domanda sia molteplice:
- Ci sono delle linee guida su quali dati devono essere contenuti in un evento nel contesto SOA?
- C'è spazio per i trasferimenti di file in un'architettura basata su eventi? Se è così, la mia ipotesi è corretta sul fatto che potremmo esportare un file contenente informazioni sui prezzi nel nostro formato e lasciarlo trasformare in middleware?