Operazione: Costruzione del Proof-of-Concept strutturale (SOA)
Questa attività descrive in che modo sviluppare il proof-of-concept (POC) strutturale sulla base dei requisiti strutturali esistenti e del profilo del rischio.
Discipline: Analisi e progettazione
Estende: Costruzione della prova strutturale del concetto
Scopo

Per sintetizzare una soluzione esemplare che rispetta i requisiti strutturali critici, questo esempio potrebbe essere limitato in un modo determinato, come:

  • La soluzione risultante potrebbe essere semplicemente concettuale,
  • la soluzione risultante potrebbe solo illustrare alcuni aspetti critici dei requisiti generali.
Relazioni
Descrizione principale

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.

Passi
Scelta dell'approccio di costruzione

Selezionare le tecniche da utilizzare per la costruzione del Proof-of-Concept (POC) strutturale, ad esempio:

  • Modellazione concettuale
  • Realizzazione 'rapida' dei prototipi
  • Simulazione
  • Conversione automatica delle specifiche in codice
  • Specifiche 'eseguibili'
  • Costruzione di  'spike' come prototipi - porzioni verticale attraverso i livelli

L'architettura software deve essere in grado di riconoscere questi modelli, individuando nel processo le aree di soluzione e le problematiche.

Selezione delle risorse e tecnologie per il Proof-of-Concept (POC) strutturale

L'architetto di software deve selezionare, dalle risorse e tecnologie identificate nell'attività: Analisi strutturale, quelle da utilizzare nella costruzione del Proof-of-Concept (POC) strutturale.

Costruzione del Proof-of-Concept (POC) strutturale

Utilizzando le tecniche selezionate per la costruzione, l'architetto di software realizza il Proof-of-Concept (POC) strutturale, mediante le risorse e tecnologie selezionate, per soddisfare - fino al punto richiesto dal profilo rischio del progetto - i requisiti strutturalmente significativi come integrati nelle realizzazioni del caso d'uso standard, i modelli di distribuzione e progettazione e il documento di architettura del software.



Ulteriori informazioni
Concetti