SOA pratica per un novellino

Question

Sono un novizio totale nel mondo SOA. In quanto tale, sto osservando alcuni "framework/tecnologie SOA" e sto cercando di capire come utilizzarli per creare un sito web altamente scalabile (classe Facebook).

Ci sono diversi "dolori" Sto cercando di risolvere qui:

(dipendenze + gestione, Pub/Sub)

1. Composability
2. Lingua-indipendenza dei servizi
3. scalabilità & prestazioni
4. Alta disponibilità

Ho esaminato alcune tecnologie che rispondono a un sottoinsieme di i criteri di cui sopra:

1. Thrift - cross-platform piattaforma di RPC di Facebook
2. WCF - supporta SOAP, JSON & REST, in modo che possa essere considerato lingua-interoperabile. Genera file WSDL che possono essere utilizzati per generare proxy java.
3. Microsoft DSS - l'ho appena inserito nel mio sondaggio, ma non sembra rilevante in quanto è altamente guidato dallo stato e specifico di .NET.
4. Web Services

Ora, capisco come ottenere alcuni aspetti della componibilità e del linguaggio-indipendenza di cui sopra. Ma, non ho trovato molte informazioni concrete (non buzz) su come utilizzare gli strumenti sopra/altri per la scalabilità e l'alta disponibilità. Così finalmente arrivo alla mia domanda:

Come sfruttare le tecnologie SOA per risolvere i dolori che ho definito sopra? Dove posso trovare delle guide tecniche per questo? Sto cercando più di semplici diagrammi di sistema, ma piuttosto librerie reali, esempi di codice, APIS ...

Answer 1

Vale la pena dare un'occhiata a: http://www.manning.com/davis/?

Answer 2

Controlla il progetto Mule che raggruppa lo stack di servizi CXF e anche il pacchetto Mule REST che fornisce alternative RESTful. Penso che vedrai che risolve tutti i tuoi problemi e ci sono molti esempi nella documentazione e nella distribuzione.

Answer 3

IDesign.net ha un bunch of great downloads per WCF.

Answer 4

Penso che la domanda abbia più a che fare con i concetti coinvolti rispetto agli strumenti. Risposte agli articoli:

1. Comprendere e internalizzare bounded context. Tenere separati i pezzi non correlati è importante per ottenere un reale riutilizzo su diversi servizi. Le tecnologie correlate non ti aiuteranno in questo, tu che separi l'app in contesti appropriati, che puoi riutilizzare in modo appropriato per servizi diversi.
2. Chiaro punto finale per comunicazioni basate su protocolli noti consente di implementare diversi pezzi con tecnologie diverse
3. Avendo le operazioni del flusso come azioni indipendenti basate su protocolli diversi, offre molti punti in cui è possibile aggiungere livelli.È un sottoprocesso particolare del processo generale che utilizza molte risorse e il server non può più utilizzarlo, basta spostarsi su un server separato. Il carico ha continuato a crescere e il server non ne ha più, aggiunge un server aggiuntivo e bilanciamento del carico. Hai anche più possibilità di utilizzare il caching e il pool di connessioni.
4. Avere un sottoprocesso critico che deve essere sempre disponibile, aggiungere un server in modo da poter eseguire un failover. Avere un processo globale che deve essere "disponibile" in ogni momento, utilizzare le code per i pezzi che possono essere elaborati in seguito.

Hai davvero bisogno di supportare quel tipo di carico? Definire gli obiettivi di prestazioni/carico/interoperabilità appropriati relativi allo scenario specifico. Se hai davvero bisogno di supportare quel tipo di carico, ti consiglio di far salire a bordo qualcuno che lo abbia affrontato.

Se è qualcosa per un carico che potrebbe eventualmente essere, identificare i contesti limitati e progettare l'interazione tra quelli con una mentalità SOA. Mantenere il codice pulito è tutto ciò che devi fare per il resto, utilizzare TDD, accoppiamento libero, test di integrazione mirati, ecc. Nella tua base di codice. Con un buon codice, se in seguito dovrai separare parti del sistema, sarà molto più semplice.

Answer 5

Posso consigliare il libro: Enterprise Service Oriented Architectures pubblicato da Springer Verlag.

Answer 6

Tutti i consigli qui vanno bene, ma non preoccuparti fino a quando non ne hai davvero bisogno.

Concentrati sulla creazione di un'applicazione utilizzabile e funzionale che piaccia davvero alla gente. Quando inizi a incorrere in problemi, inizia a gestire i colli di bottiglia.

Non sarai mai in grado di prevedere in ogni modo un errore, quindi come puoi sapere se [[inserire la tecnologia qui]] è la tua risposta?

Answer 7

ci sono cose interessanti e rilevanti detto di servizi e l'architettura di CTO di Amazon - Werner Vogels:

• An interview sulla piattaforma tecnologica di Amazon
• un post sul suo blog - "Eventually Consistent - Revisited"
• A 50 min presentation about Availability & Consistency