Come si fa l'integrazione del sistema?

Question

Sono curioso di sapere come persone diverse risolvono l'integrazione dei sistemi.Ho la sensazione che negli ultimi anni sia stato dedicato sempre più lavoro all'integrazione dei sistemi e che anche questo tipo di necessità di lavoro aumenterà.

Mi chiedo se lo risolvi sviluppando i tuoi piccoli servizi che poi vengono collegati o se usi qualche tipo di prodotto (WebSphere, BizTalk, Mulo eccetera).Penso anche che sarebbe interessante sapere come vengono gestiti e mantenuti questo tipo di soluzioni (come risolvi la sicurezza, la strumentazione ecc. ecc.), che tipo di problemi hai riscontrato con la tua soluzione e così via.

Answer 1

wow - Ok - riceverò un post su questo ma sarà grosso.

L'integrazione deve essere supportata da una grande comprensione da parte dell'azienda dei vantaggi: ottenere un modello operativo risolto, poiché l'azienda potrebbe effettivamente aver bisogno di standardizzare invece di integrare, poiché ciò può essere costoso: è per questo che la maggior parte della SOA fallisce! Architettura d'impresa:Guida gli affari beneficiano dell'autore / i IT:Jeanne W.Ross

Se è necessaria l'integrazione, è necessario stabilire il tipo di integrazione.

Quali sono le metriche di velocità e prestazioni?

Disponiamo di una SOA .NET con un'applicazione composita che utilizza BizTalk 2006 e servizi Web con applicazioni Line of Business.Le prestazioni dell'applicazione all'estremità composita (consumo) sono limitate alla velocità dei servizi web (e alla loro implementazione) nell'applicazione line of business!Abbiamo bisogno di un ritorno sui risultati inferiore a 3 secondi: elenco dei casi.Non è possibile ottenerlo nei servizi Web, quindi è necessario accedere direttamente al database per la ricerca iniziale.Quindi tramite i servizi web per la creazione del caso.Le implicazioni in termini di costi e manutenzione diventano un problema qui.

Il punto qui è guardare i criteri prestazionali nelle specifiche e nei requisiti aziendali, questo ti aiuterà a valutare il tipo di integrazione che devi fare: WebServices (HTTP), File Drop/EDI ecc.

Dal punto di vista funzionale per l'integrazione è quindi necessario esaminare i punti di fallimento nell'architettura proposta, poiché ciò porterà a una catena di responsabilità in SLA/OLA.Potrebbe essere necessario racchiudere i punti di integrazione/errore in cose che controlli.

Un punto simile sull'integrazione con Line of Business riguarda quanto devi sapere sull'altro prodotto prima di poterlo integrare?Sì, i servizi Web dovrebbero essere progettati per contratto, ma l'implementazione spesso perde e devi capire molto cosa sta succedendo - e se questo è un prodotto di cui non controlli l'astrazione anche con le perdite di servizi web nella tua tecnologia di interazione, ovvero BizTalk.

Combina questi due punti insieme e il miglior consiglio è quello di ottenere un tipo di hub di integrazione come BizTalk - avvolgere la linea di applicazioni aziendali nei servizi Web creati - in modo che il lato BizTalk possa essere libero da astrazioni che perdono, quindi puoi anche ridurre i punti di errore poiché hai disaccoppiato l'applicazione line-of-business dall'hub di integrazione e dal punto di errore verso un'unica fonte anziché all'interno di un'orchestrazione.

La strumentazione e la diagnostica nei progetti SOA e di integrazione sono difficili da ottenere!- Non lasciare che nessun venditore brillante provi a dirti il ​​contrario!Sì, MOM con MOM Ent può farlo, UniCenter può fare bla.

Il problema principale è capire cosa significano gli errori, ovvero i rutti, nell'interrogazione e come risolverli...Ti ritrovi con i messaggi bloccati e devi capire cosa significa per quel processo aziendale.È possibile ricevere un avviso per dire: i processori sono al 100% Ram, le orchestrazioni al 100% sono fallite, ma senza alcun significato reale.Devi progettare queste cose nella soluzione fin dall'inizio e, si spera, nei tuoi punti di fallimento.

È necessario considerare anche i tipi di modelli di integrazione e come realizzarli.

Quanto sopra è una visione del mondo reale di una SOA .NET con BizTalk in un'implementazione LIVE.Ma è anche dovuto ai limiti architetturali di questo: BizTalk è principalmente un modello HUB e SPOKE.

Guardare Modelli di applicazioni aziendali di Martin Fowler

Ci sono molti modi per snellire il compito!

Altre considerazioni...Linguaggi della piattaforma/sviluppatore, ecc.

Uno dei fattori più importanti per noi erano le competenze necessarie per avviare questa attività.Avevamo sviluppatori OO con comprensione di Java e C#, ma principalmente C#.Quindi abbiamo optato per lo stack MS.Ma quando si sceglie il tipo di integrazione e il prodotto per gestirlo, saranno necessarie maggiori competenze nella comprensione di tale tecnologia.Ma ehi, questo è normale per noi sviluppatori, giusto?Sbagliando molti sviluppatori, indipendentemente dalla loro esperienza, possono rimanere bloccati con artisti del calibro di BizTalk!Grande cambiamento di paradigma, che in parte è dovuto al cambiamento della messaggistica piuttosto che al codice.

Il meglio per ultimo!

Il numero di transazioni che probabilmente si dovranno affrontare nell’integrazione è probabilmente il fattore più importante in tutto questo.Poiché questo guiderà quale modello, punti di fallimento e tolleranza per tali cose.

È necessario selezionare meglio sui volumi previsti quello giusto.Qualcosa che può espandersi e espandersi!Abbiamo selezionato BizTalk poiché può essere ampliato e ridimensionato correttamente e con una migliore comprensione rispetto ad altri.

Se non disponi di volumi, cerca di non ottenere qualcosa per gestirli e scegli uno stile di tipo da servizio Web a servizio Web senza gestione: le prestazioni e la comprensione degli errori dovranno essere codificati in essi.

Se utilizzi una piattaforma Windows con .net 3, dai un'occhiata a WWF/WCF in quanto può aiutare da servizio web a servizio web: molto di più nella piattaforma attuale ora per tutte queste preoccupazioni senza il sovraccarico di BizTalk e altri.

Spero che questo ti aiuti.

Answer 2

Secondo la mia esperienza dipende dal tipo di problema che stai affrontando.

Nella mia esperienza è difficile battere BizTalk 2006 R2 in termini di rapporto qualità-prezzo, ma implica l'uso di uno stack tecnologico Microsoft.

Websphere MQ sembra essere più facile da vendere alle aziende più grandi e probabilmente ha visto un maggiore utilizzo a livello aziendale.

Entrambi forniscono una buona strumentazione, ma spetta a te come sviluppatore personalizzarla per soddisfare le esigenze del tuo cliente.

In alcuni casi ho scoperto che una soluzione su misura è la più appropriata o sfrutta tecnologie come MSMQ per contenere i costi.

Answer 3

Hai menzionato WebSphere, BizTalk, Mule.Ognuno dei quali ha caratteristiche molto diverse con i suoi pregi e difetti.Se stai cercando solo l’integrazione, consiglierò Mule.Ho avuto un'esperienza molto positiva e, cosa più importante, l'architetto non è invasivo, quindi puoi sempre migrare a un ESB diverso o ad un'altra soluzione di reclamo per parole Buzz.Uno dei punti di forza di Mule è che può essere incorporato nella tua applicazione e il tuo artefatto finale può essere distribuito su Webshpere, WLS, Glassfish ecc...senza nemmeno mostrare che hai incorporato un ESB.Quindi questo ESB può eseguire tutte le operazioni di integrazione (gestendo tipi e protocolli di connessione).Considerando che alcuni dei punti finali potrebbero essere altre soluzioni di integrazione che hai menzionato.

Answer 4

Stiamo utilizzando Mule per un po' (ora esaminiamo la migrazione dalla versione 1.4 alla versione 2.1.x).

Beh, è ​​uno dei migliori ESB con comunità live e reazione rapida da parte del fornitore, ma la versione IMO 2.1.x è ancora un po' grezza (o siamo solo la società che la usa per chiamare CXF web :) vedi anche il mio post per i dettagli http://www.nabble.com/Migration-from-XFire-to-CXF:-Is-Web-Service-Client-in-Mule-2.x-broken--to19969320.html#a19969320)

Answer 5

abbiamo un contratto Oracle.Quindi stiamo usando lo stack Oracle.Suite SOA 10.1.3.4.Principalmente soluzioni BPEL e per trasformazioni semplici cerchiamo di utilizzare ESB.

L'ESB ha un cattivo meccanismo di gestione dei guasti.Per il BPEL esistono molti modi per gestire gli errori.Cerchiamo di sviluppare servizi web Java per connetterci alla Suite SOA e i nostri sistemi principali sono i sistemi Oracle EBS.Comunicano con sistemi legacy o altri ambienti EBS tramite gli adattatori EBS predefiniti forniti con SOA Suite.

Il problema che abbiamo riscontrato è la mancanza di conoscenza degli adattatori EBS.Abbiamo riscontrato alcuni problemi con una soluzione BPEL che riceveva informazioni dai sistemi EBS.È stato un lavoro incredibile preparare la produzione della soluzione.

Proteggere i nostri servizi web non è un grosso problema.Con lo stack Oracle arriva Oracle Web Service Manager.Con ciò possiamo proteggere, registrare ecc.tutti i servizi web.

Il problema più grande che incontriamo è la mancanza dei nostri standard.Far sì che l'azienda senta di poter anche creare soluzioni SOA.Non possiamo spiegare i vantaggi che ottengono con una soluzione SOA.Più veloce?NO !Più economico?Diavolo, no!Soluzioni più facili?Beh, forse quando avremo buoni servizi riutilizzabili...beh, quella parte più semplice ha un problema al suo interno:come facciamo a sapere quali applicazioni utilizzano i servizi web riutilizzabili?

Abbiamo bisogno di un registro in grado di visualizzare questo tipo di informazioni.Poiché non riusciamo a trovare una buona soluzione opensource, stiamo cercando di creare il nostro registro.Soluzione APEX semplice, sempre dallo stack Oracle.;)

Quindi qualcuno conosce un buon prodotto per registrare questo tipo di informazioni?