Una metodologia di analisi e confronto per strumenti BPM

More documents

Recommendations

Info

32 Capitolo 2. Stato dell’Arte software distinti che devono lavorare insieme per svolgere alcuni compiti. Questi agenti in un sistema distribuito non operano nello stesso ambiente di calcolo quindi devono comunicare per mezzo di uno stack di protocolli hardware/software su una rete. Motivare perchÃ¨ dico questo Questo modello architetturale permette la creazione di sistemi residenti su una rete focalizzando l’attenzione sul concetto di servizio (service). Con il termine “servizio” viene indicata un’applicazione residente su un sistema progettato secondo le specifiche SOA. In questi sistemi infatti sono presenti una o più applicazioni, chiamate appunto servizi, ben definite ed indipendenti l’una dall’altra che risiedono su più calcolatori all’interno di una rete. Ogni servizio mette a disposizione una certa funzionalità e può utilizzare quelle che gli altri servizi mettono a disposizione realizzando in questo modo applicazioni di maggiore complessità. L’architettura SOA non è legata ad una specifica tecnologia ma contiene semplicemente delle proprietà che devono essere rispettate da servizi che compongono il sistema. Le proprietà che un servizio deve rispettare sono: • essere realizzato in modo da da permetterne la composizione con altri. La creazione di applicazioni o servizi più complessi attraverso la composizione di servizi viene definita con il termine di “orchestrazione di servizi” (Service Orchestration) • fornire un’interfaccia di tipo a grana grossa (coarse-grained), cioè deve mettere a disposizione un limitato numero di funzionalità inquanto questo permette di avere una complessità bassa del programma di controllo. Tale bassa complessità favorisce l’interazione con gli altri servizi attraverso scambi di messaggi • essere debolmente accoppiato con altri servizi (loosely coupled), cioè le dipendenze con altri servizi devono essere in numero limitato rendendo il sistema flessibile e facilmente modificabile • essere ben definito, completo ed indipendente dal contesto o dallo stato degli altri servizi • essere ricercabile e recuperabile dinamicamente attraverso la sua interfaccia e richiamato a tempo di esecuzione • essere definito da un’interfaccia ed indipendente dall’implementazione • essere reso disponibile sulla rete attraverso la pubblicazione della sua interfaccia ed accessibile in modo trasparente rispetto alla sua collocazione.
2.2. Business Process Management 33 Il funzionamento di una SOA è basata sull’interazione di tre attori: • Service Provider • Service Consumer • Service Registry Il Service Provider è quell’entità che mette a disposizione un qualche servizio. Tale servizio per poter essere trovato da altre entità nella rete deve prima essere “pubblicato”. A tale fine il Service Provider comunica al Service Registry le informazioni relative al servizio perchè vengano memorizzate. Il Service Registry possiede quindi tutte le informazioni (come URL o modalità di accesso) di tutti i servizi disponibili. Nel momento in cui un Service Consumer dovrà utilizzare un servizio farà richiesta delle informazioni ad esso relative al Service Registry. Con queste informazioni il Service Consumer potrà comunicare direttamente con il Service Provider ed utilizzare il servizio. Tutte queste informazioni passano attraverso quella che viene genericamente definita rete di comunicazione che può ad esempio essere una rete intranet oppure la stessa Internet. In figura 2.17 uno schema riassuntivo. Figura 2.17: Relazioni di interazione tra i vari attori di un SOA I Web Service sono una tipologia di applicazioni web che cooperano fra loro attraverso lo scambio di messaggi, indipendentemente dalla piattaforma sulla quale si trovano. Ognuna di queste applicazioni viene chiamato Web
Page 1: POLITECNICO DI MILANO Facoltà di I
Page 5: A Martina
Page 9: Sommario Il Business Process Manage
Page 13 and 14: Indice Abstract I Sommario III Ring
Page 15: 6.2.4 Conformità agli standard BPM
Page 18 and 19: 2 Capitolo 1. Introduzione Fattori
Page 20 and 21: 4 Capitolo 1. Introduzione opiù wo
Page 22 and 23: 6 Capitolo 1. Introduzione
Page 24 and 25: 8 Capitolo 2. Stato dell’Arte 2.1
Page 26 and 27: 10 Capitolo 2. Stato dell’Arte Fi
Page 28 and 29: 12 Capitolo 2. Stato dell’Arte ni
Page 30 and 31: 14 Capitolo 2. Stato dell’Arte Ne
Page 32 and 33: 16 Capitolo 2. Stato dell’Arte
Page 34 and 35: 18 Capitolo 2. Stato dell’Arte mo
Page 36 and 37: 20 Capitolo 2. Stato dell’Arte 1.
Page 44 and 45: 28 Capitolo 2. Stato dell’Arte 3.
Page 50 and 51: 34 Capitolo 2. Stato dell’Arte Se
Page 54 and 55: 38 Capitolo 2. Stato dell’Arte e
Page 56 and 57: 40 Capitolo 2. Stato dell’Arte if
Page 58 and 59: 42 Capitolo 3. Standard degli Strum
Page 96 and 97: 80 Capitolo 4. Analisi degli Strume
Page 98 and 99:
82 Capitolo 4. Analisi degli Strume
Page 100 and 101:
Page 102 and 103:
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
Page 110 and 111:
Page 112 and 113:
Page 114 and 115:
Page 116 and 117:
100 Capitolo 4. Analisi degli Strum
Page 118 and 119:
Page 120 and 121:
Page 122 and 123:
Page 124 and 125:
Page 126 and 127:
Page 128 and 129:
Page 130 and 131:
Page 132 and 133:
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
Page 140 and 141:
Page 142 and 143:
Page 144 and 145:
Page 146 and 147:
130 Capitolo 5. Valutazione dei Sin
Page 148 and 149:
Page 150 and 151:
Page 152 and 153:
Page 154 and 155:
Page 156 and 157:
show all

Una metodologia di analisi e confronto per strumenti BPM

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?