specifica dellarchitettura funzionale mais enrico mussi - wp2
TRANSCRIPT
Specifica dell’Architettura Funzionale MAIS
Enrico Mussi - WP2
Sommario
Configurazioni dell’architettura MAIS nell’ambito WP2, MAIS-P e µ-MAIS
MAIS-P e SOA
Descrizione scenari di utilizzo MAIS-P
Architettura Funzionale MAIS
Configurazioni di Utilizzo dell’Architettura MAIS
Compatibilmente con gli obiettivi del gruppo WP2 possono essere identificati 2 configurazioni di utilizzo della piattaforma MAIS
MAIS-P: ASP in grado di fornire funzionalità avanzate:
• Esecuzione di processi complessi
• Esecuzione flessibile e adattiva
• Esecuzione di servizi basata sul contesto utente
µ- MAIS: sistema P2P totalmente distribuito
MAIS-P e SOA
La piattaforma MAIS si caratterizza per la sua capacità di gestire servizi in modo avanzato.
Rispetto alla Service Oriented Architecture (SOA), la piattaforma MAIS si può porre a livello di service provider, di service registry e di service requestor.
Nel caso MAIS-P, la presenza della piattaforma MAIS rispetto agli attori SOA è così dislocata:
La possibilità di avere service provider e service requestor realizzati mediante tecnologia MAIS o tecnologia proprietaria porta alla definizione di 4 scenari di utilizzo.
Attore Tecnologia di sviluppo
Service Registry MAIS
Service Provider MAIS o Proprietaria
Service Requestor MAIS o Proprietaria
Scenari di Utilizzo MAIS-P
I 4 scenari di utilizzo nella configurazione MAIS-P sono:
1. Service provider MAIS – Service requestor MAIS;
2. Service provider MAIS – Service requestor proprietario;
3. Service provider proprietario – Service requester MAIS;
4. Service provider proprietario – Service requestor proprietario.
Gli scenari 1 e 2 si possono ulteriormente suddividere considerando il tipo di servizio MAIS invocato:
• invocazione di un servizio concreto semplice;
• invocazione di un servizio astratto;
• invocazione di un servizio concreto complesso.
L’analisi dello scenario 4 è fuori dal nostro interesse.
Service Registry – Il MAIS Registry per la ricerca dei servizi
Match Maker UDDI
QualityAnalyzer
BehavioralCompatibility
Engine
ServiceOntology
MAIS Registry
SP MAIS – SR MAIS – Servizio concreto semplice
ConcreteService
Invocator
MAIS MAISService
implementations
Reflective platform
SOAPClient
UserEnvironment
(WP7)
PlatformInvocatorLocal
profile
Reflective platform
SP MAIS – SR MAIS – Servizio astratto
ConcreteService
Invocator
MAIS
MAISService
implementations
Reflective platform
SOAPClient
UserEnvironment
(WP7)
PlatformInvocatorLocal
profile
Reflective platform
ExternalService
implementations
Concreti-zator
Negotia-tor
ProfileRegistry
Recom-mender(WP6)
MAISRegistry
SP MAIS – SR MAIS – Servizio concreto complesso
ConcreteService
Invocator
MAIS
MAISService
implementations
Reflective platform
SOAPClient
UserEnvironment
(WP7)
PlatformInvocatorLocal
profile
Reflective platform
ExternalService
implementations
Concreti-zator
Negotia-torProfile
Registry
Recom-mender(WP6)
MAISRegistry Process
Orch.
TXmanager
Service requestor proprietario
Il Service Requestor è realizzato con tecnologie non MAIS (es. Client SOAP standard)
Il Service Requestor può comunque continuare ad utilizzare il Concrete Service Invocator per invocare servizi astratti, concreti semplici e concreti complessi
Non c’è possibilità di trasferire in modo esplicito alla piattaforma informazioni sul contesto e il profilo dell’utente
L’utente non può sfruttare tutte le potenzialità della piattaforma per la selezione e gestione dei servizi
Service requestor MAIS – Service provider proprietario
SOAPServer
SOAPClient
UserEnvironment
(WP7)
PlatformInvocatorLocal
profile
Reflective platform
Conclusioni
Nell’ambito WP2 esistono 2 configurazioni della piattaforma MAIS
• MAIS-P
• µ-MAIS
In MAIS-P possono essere identificati diversi scenari di invocazione
Quando il Service Requestor è realizzato con teconologia MAIS è possibile sfruttare al meglio le potenzialità della piattaforma