Come si usa iBATIS in un'architettura orientata ai servizi efficienty?

Question

Abbiamo diversi servizi, ognuno dei quali dovrebbe idealmente operare indipendentemente l'uno dall'altro. L'uso primario dei servizi è quello di sostenere la nostra webapp. Stiamo cercando il modo migliore per utilizzare iBatis con quei servizi.

Il nostro primo approccio, era quello di avere un progetto con lo SqlSessionFactory ed avere tutte le implementazioni di servizi utilizzano quel progetto per l'accesso ai dati. Questo significa che il progetto dipende da tutti i servizi (abbiamo dovuto servizio separato e impl per eliminare la dipendenza cerchio) per gli oggetti di dati, e contiene tutte le mappe sql. Il vantaggio sarebbe un'istanza di qualsiasi momento SqlSessionFactory, ed una configurazione da gestire. Anche se se un servizio viene utilizzato come per junits, o qualche altro programma di utilità, tutte le mappe sono caricate sql a prescindere, e tutti i servizi sono una dipendenza.

Un altro approccio sarebbe quello di avere ogni servizio ha un proprio config iBATIS e l'istanza di SqlSessionFactory. Ciò eviterebbe la necessità di mecca del dipendenze sul progetto di accesso ai dati, ma attraverso diversi casi di SQLFactory sulla webapp.

Mi piace il secondo approccio, anche se vedo bene e il male in entrambi.

Che cosa faresti? Quello che aggiungere o togliere dal mio argomento?

Aiuto !!!

Answer 1

Anche se penso che la forza dei tuoi primi punti argomento per la debolezza della SOA in generale, penso che se si sta facendo la SOA, che sconfigge l'intero scopo per poi fare tutti i servizi interdipendenti gli uni dagli altri.

Se si sta facendo SOA, si accettano il compromesso di utilizzo delle risorse più inefficiente per il bene di disaccoppiamento e l'isolamento dei componenti.

Answer 2

Onestamente, mantenerlo semplice fino a trovare un collo di bottiglia o la vostra applicazione diventa troppo grande. Cioè, a meno che non ci si aspetta servizi per essere aggiornati in modo indipendente sui loro programmi.

dove lavoro, non c'è codice comune che è condiviso da tutte le applicazioni. Tutto deriva dalla stessa fonte, ma è costruito in modo indipendente in ciascuna applicazione. Questo probabilmente non è la soluzione migliore, ma almeno rende facile modificare codice comune con fuori preoccuparsi di un'applicazione separata da distribuire. E permette codice comune per il cambiamento come vengono introdotti più applicazioni, con fuori effettuando applicazioni distribuiti in precedenza.

Answer 3

Se possono applicare entrambe le soluzioni, probabilmente avete tutti i servizi eseguiti sulla stessa JVM. A mio parere, si dovrebbe pensare di correre i componenti in JVM separate. Una vera e propria architettura Service Component è quella in cui si dispone di diversi componenti (EJB per esempio) che funzionano in un ambiente cluster e parlare con l'altro in un loosely coupled con equipaggio (tramite JMS per esempio, o Webservices o RMI, ecc). Ogni componente è indipendente e, eventualmente, viene eseguito in un server remoto.

In questo caso, mi avrebbe usato, naturalmente, il secondo approccio. Ma se la vostra applicazione non ha bisogno di questo disaccoppiamento, si consiglia di utilizzare il primo approccio, dal momento che è più efficiente della memoria.

E 'dopo tutto, una questione di ciò che la vostra applicazione ha davvero bisogno.