Il Proof-of-Concept strutturale prende l'input principalmente daAttività: Analisi asset esistente e prende in considerazione il Concetto: Portafoglio del servizio definito da Attività: Esecuzione specifica del servizio.
Inoltre, quando si trattano le applicazioni esistenti, è necessario esaminare e considerare le seguenti voci:
-
Gestione eccezione: È necessario comprendere come funziona la gestione dell'eccezione. Nell'elaborazione
batch, quando si verifica l'eccezione, il programma si chiude (termina in modo anomalo) e produce un dump core. Al
programmatore viene richiesto di controllare il dump core e di capire cosa fare. Questo potrebbe non essere
accettabile. È necessario capire cosa fare, ad esempio come eseguire l'integrazione con il framework di gestione
dell'eccezione.
-
Elaborazione e distribuzione dei dati: È necessario esaminare dove sono eseguiti i dati ed il processo.
L'applicazione CICS è in esecuzione su una macchina e potrebbe inviare una richiesta ad un'altra macchina
(conosciuta anche come funzione che passa a CICS) o chiamare in modo remoto i dati su un'altra macchina.
Considerare la possibilità di andare direttamente (JDBC a DB) alla macchina remote dove è in esecuzione il processo
o i dati, invece di utilizzare il connettore che va da JDBC a DB.
-
Disponibilità dati: Se viene personalizzato il file in VSAM che richiede, diciamo una finestra di
manutenzione di 4 ore, allora non è possibile supportare un'assistenza clienti 24 ore al giorno 7 giorni su
7. È necessario considerare la possibilità di una nuova soluzione di memorizzazione.
-
Autorizzazione/Autenticazione: Molte applicazioni legacy hanno meccanismi di autorizzazione e
autenticazionenel codice di applicazione. Questo richiede la migrazione dell'accesso utente ad un ambiente gestito
associato supportato dalle migliori pratiche.
-
Ritardi di gestione temporanea: In genere i programmi di batch vengono eseguiti una volta al giorno durante
la notte. Se i requisiti devono eseguire il programma più spesso, allora sarà necessario modificare il programma di
pianificazione per modificare la frequenza.
L'elenco su riportato non deve è esaustivo; ma viene fornito come guida.
Esempio
Nell'esempio Noleggia una macchina, la realizzazione del servizio deve prendere in considerazione i seguenti
requisiti:
-
Un'interfaccia senza interruzioni tra il client/server remoto, le applicazioni della stazione di lavoro, e le
applicazioni IMS di mainframe.
-
L'eliminazione di "screen scraping" dal punto di vista dell'applicazione remota. Questo serve per eliminare la
necessità di cambiare l'elaborazione dell'applicazione remota, semplicemente perché un messaggio viene aggiunto ad
uno schermo, o un campo cambia le posizioni su uno schermo.
-
Il supporto di messaggi di input e output delle applicazioni IMS che sono in un formato predefinito e fisso.
-
L'elaborazione relativa alla formattazione del messaggio in modo che sia trasparente all'applicazione IMS, così che
il tempo necessario per sviluppare e verificare le nuove applicazioni remote sia ridotto in modo significativo.
-
Il supporto delle nuove funzioni per le applicazioni IMS e i nuovi campi di dati nei sistemi remoti in modo
aggiornato, ad esempio ridurre il tempo che impiega per potenziare i sistemi esistenti.
Gli elementi di queste decisioni di fattibilità e le considerazioni sono relative agli aspetti funzionali e operativi
dell'architettura. Per indirizzare i requisiti su riportati, è stato utilizzato il seguente approccio:
-
Il broker del messaggio/di integrazione per gestire la formattazione del messaggio da e verso le applicazioni IMS.
Il broker del messaggio esegue le seguenti funzioni:
-
Riformatta i messaggi integrati (da XML ad un formato di lunghezza fisso) in un formato predefinito
accettabile dalle applicazioni IMS del mainframe.
-
Riformatta l'output IMS del mainframe (da formato a lunghezza fissa a XML) risponde ad un formato di parola
chiave IMF, affinché venga elaborato dall'applicazione di invio originale.
-
Interroga il messaggio integrato, per determinare se si tratta di un formato IMF controllando
l'intestazione del messaggio che precede il payload dei dati. L'intestazione si trova in un formato di
posizione e contiene diversi pezzi chiave di informazioni necessarie affinché IMF esegui l'elaborazione in
modo corretto.
-
Esegue il routing e la trasformazione in base ai contenuti dell'intestazione del messaggio ed il codice di
transazione IMS. Questo codice di transazione IMS viene richiesto per eseguire la transazione appropriata
nel sistema di mainframe IMS.
-
Il bridge IMS-MQ per agire come condotto tra il Broker del messaggio ed il sistema IMS.
L'utilizzo del broker del messaggio/di integrazione riduce molto o elimina la necessità di personalizzare ogni
applicazione IMS per gestire le richieste di transazione da diversi sistemi remoti. Poiché la maggior parte
dell'elaborazione relativa alla formattazione del messaggio è trasparente all'applicazione IMS, il tempo necessario per
sviluppare e verificare le nuove applicazioni remote è significativamente ridotto. Inoltre, le nuove funzioni di
applicazione IMS e i nuovi campi di dati diventano disponibili per i sistemi remoti in modo aggiornato, riducendo il
tempo che impiega per potenziare i sistemi esistenti. Questo porta ad allentare l'accoppiamento delle applicazioni che
è uno dei principi core di SOA.
|