enterprise soa service oriented architecturetorlone.dia.uniroma3.it/sistelab/consel.pdf ·...

SEMINARI DI SISTEMI INFORMATICI CORSO DI STUDI IN INGEGNERIA INFORMATICA ANNO ACCADEMICO 2005/2006 Prof. Riccardo

TORLONE

Ing. Gianluca [email protected]

http://www.consel.org/juniorconsulting/

ENTERPRISE SOASERVICE ORIENTED ARCHITECTURE

2/3723/01/2006

LE RADICIGap fra le competenze del neolaureato e i bisogni dell’aziendaNecessità di integrare la formazione universitaria sul campoEfficacia del Training on the JobValore formativo delle esperienze di consultingLa possibilità che la formazione crei valore in tempo reale

LE DUE ANIMEProgramma formativo che realizza servizi di consulenzaConsulting che forma laureandi

COSA NON ÈStage, Simulazione, Case Study

TEAM7 consultant: professionisti provenienti da consulting e multinazionali24 junior consultant - laureandi in laurea specialistica

JUNIOR CONSULTING

3/3723/01/2006

CONSULTINGTeam di progetto

1 Consultant – Team Leader3 Allievi – laureandi di secondo

livello in discipline tecniche e/o economico-gestionali

DURATA: 5 MESIOgni progetto viene definito con la committenza in termini di

Deliverable – Scadenze –Milestone

NETWORK EX ALLIEVII progetti “SENIOR”

JUNIOR CONSULTING [cont]

PROGRAMMA FORMATIVOFormazione integrata

Strumenti: Training on the job, Formazione d’Aula, Knowledge ManagementContenuti: Networking, Programming, Marketing, Soft Skills

4/3723/01/2006

VALORE RICONOSCIUTO DALLE AZIENDE• Metodo• Forte orientamento al prodotto• Creatività• Pensiero incondizionato


IL NOSTRO PLACEMENT

100%Oltre

96%Entro 6 mesi

92%Entro 3 mesi

65%Subito dopo la laurea

PercentualeMesiSettore azienda

Informatica22%

Consulenza42%

Telecomunicazioni18%

Altro18%

5/3723/01/2006

•Ipv4/Ipv6 interworking in IP Multimedia Subsystem

Presentazione dei risultati a livello global presso il centro di ricerche di Helsinky

•Video Quality Assessment per MPEG-4: valutazione oggettiva dei contenuti video

Presentazione dell’architettura proposta a livello global

•BPR del sistema della contrattualistica business

Presentazione dei risultati a livello nazionale

•Service Concept Definition per Vodafone Live! - NDA

I NOSTRI ALLIEVI LAVORANO OGGI IN: • Accenture, Bip; Busacca & Associati, Value Partners, Cap Gemini• Enterprise Digital Architect, Ericsson• Siemens;• Telecom Italia, Tim• Vodafone


ALCUNE DELLE METE RAGGIUNTE

6/3723/01/2006

ENTERPRISE SOA – SUMMARY

CONTESTOSCENARIO / REGOLE

SERVICE ORIENTED ARCHITECTUREEVOLUZIONE O RIVOLUZIONE?DEFINIZIONILIFECYCLES / SVILUPPO DI UN CLIENTI SERVIZI COME BUILDING BLOCKTRANSAZIONICOMUNICAZIONI / JMS

WEB SERVICEOVREVIEW / UTILIZZO / INTERAZIONETECNOLOGIA – SOAP / WSDL / UDDI

ENTERPRISE APPLICATION INTEGRATIONINTEGRATIONCORE COMPONENTSARCHITETTUREPROGETTO ENTERPRISE SOA

BIBLIOGRAFIA

7/3723/01/2006

SCENARIO

La Service Oriented Architecture nasce per integrare i rapporti Business-to-Business:

Elevato livello di integrazione tra diversi sistemi informativi

Inventario:

Server LINUX

Application server:

Windows Server 2003

INTERNET

Ordinazioni:

Server Fornitori

Clienti

Applicazione distribuita, le cui parti sianoFornitori di serviziFruitori o consumatori di tali servizi

CONTESTO

8/3723/01/2006

REGOLE

LINGUAGGIO COMUNECONTRATTO tra fornitore e fruitore del servizio:

ChiaroFissoPersistente“Comprensibile” da una macchina

INDIVIDUAZIONE DINAMICA dei serviziCANALE DI COMUNICAIZONE:

SicuroSempliceUniversalmente accettato

CONTESTO

9/3723/01/2006





BIBLIOGRAFIA


10/3723/01/2006

EVOLUZIONE O RIVOLUZIONE?

EVOLUZIONE E RIVOLUZIONE INSIEMETutto ciò che è già stato sviluppato può essere integrato grazie ad una filosofia secondo la quale gli oggetti diventano dei Web Service che interagiscono tra loro senza necessità di condividere le specifiche implementazioni. L’unico aspetto condiviso è il contratto fra il Service Provider ed il Client

Caratteristiche di una SOAEsposizione di un contratto (interfaccia)La granularità dei servizi è direttamente proporzionale all’utilitàServizi statefull, chiamate statelessServizi loosely coupledI servizi possono fruire di altri servizi ed essere fornitori di altriI messaggi sono scambiati attraverso un canale virtuale: service busConnettività asincrona tra i servizi

SOA

11/3723/01/2006

DEFINIZIONI

ARCHITETTURA SOFTWAREÈ un insieme di definizioni che descrive i componenti software ed assegna loro le funzionalità del sistema. Descrive la struttura tecnologica, i vincoli, le caratteristiche dei componenti e le loro interfacce. L’architettura è il blueprint del sistema e perciò il progetto ad alto livello per la costruzione del sistema stesso.

ARCHITETTURA SOA1. È un’architettura software basata sui concetti chiave di application frontend, di (business) service, di service repository e di service bus.Un servizio è a sua volta composto da un contratto, una o più interfacce ed una implementazione.2. “…is a set of components which can be invoked, and whose interface descriptions can be published and discovered…” [W3C]

BUS SERVICE

DESCRIPTION

SOA

REPOSITORY

12/3723/01/2006

DEFINIZIONI [cont]

APPLICATION FRONTENDInstaurano e controllano tutta l’attività del sistema aziendaleAttiva un business process e riceve i risultati

SERVICEComponente software che incapsula un concetto di business ad alto livello:o Contracto Interfaceo Implementation

Business logicData

SERVICE REPOSITORYContiene le informazioni per accedere ai servizi disponibiliMette a disposizione i mezzi necessari per scoprire i servizi disponibiliUn repository non è necessario, ma lo diviene a lungo termine

SERVICE BUSConnette tra loro tutti i componenti di una SOA, spesso basati su linguaggi di programmazione, sistemi operativi e ambienti di run time eterogeneiDeve supportare diversi tipi di comunicazione (almeno sincrona e asincrona)Deve fornire servizi “tecnici”: es. logging, auditing, security …

SOA

SOA

ServiceApplicationFrontend

ServiceRepository

ServiceBus

Implementation InterfaceContract

Business Logic Data

13/3723/01/2006

LIFECYCLE

I cicli di vita stimati dei dati, dei servizi, degli application frontend e delle tecnologie sono fortemente differenti

SOA

Data/Content

Application Frontend

Technology (installation life time)

Tech. Innovation/products

Services

0 5 10 15 20 25years

14/3723/01/2006

SVILUPPO DI UN CLIENT

MODELLO SEMPLICE: lo sviluppatore è responsabile di localizzare tutte le informazioni necessarie dal service repository in maniera da creare un client che interagisca correttamente con l’istanza del servizio desiderato.

ServiceRepository

ServiceContract SERVICE

Client(Application

frontend or Service)

ServiceStub

USES

Developer

CREATES

INVOKES

BOUND TO

SEARCHES INCONTAINS

BASED ON

DESCRIBES

FULFILLS

SOA

15/3723/01/2006

I SERVIZI COME BUILDING BLOCK

FOCUS di una SOASI: Infrastruttura funzionale ed i relativi servizi di businessNO: Infrastruttura tecnica ed i relativi servizi “tecnici”

Servizi business-oriented, associati a:Business EntityBusiness FunctionBusiness Process

CLASSI DI SERVIZIO

SOA

LowHighService specificService specificPUBLIC ENTERPRISE

HighLowStatefullHighPROCESS CENTRIC

Moderate to HighLowStatelessModerate to HighINTERMEDIARY

LowHighStatelessLow to ModerateBASIC

Frequenza di cambiamento

Livello di riusabilitàGestione dello statoComplessità di implementazione

16/3723/01/2006

TRANSAZIONI

Più messaggi scambiati tra i partecipanti costituiscono un unico “task” logicoLe parti devono

Iniziare un task coordinatoAssociare le operazioni con i loro task logiciAccordarsi sull’outcome della computazione

Transazioni ACIDATOMICITY: tutto o nienteCONSISTENTY: il sistema passa da uno stato consistente ad un altroISOLATION: due transazioni hanno lo stesso effetto se eseguite in serie o in paralleloDURABILITY: una volta stabilito un outcome esso non potrà essere mutato

Le proprietà vengono garantite bloccando opportunamente le risorse coinvolte

SOA

17/3723/01/2006

COMUNICAZIONE

SINCRONAService producer e consumer sono legati da stretti vincoli temporaliIl consumer(producer) attende l’elaborazione e la risposta del producer(consumer)HTTP, HTTPS, FTP, …

ASINCRONAService producer e consumer non sono legati da stretti vincoli temporaliIl consumer(producer) invia il proprio messaggio e prosegue le proprie attività fino alla scadere di un tempo di timeoutJMS, WSRM, …

SOA

18/3723/01/2006

JAVA MESSAGE SERVICE

JMS è la API di Java che permette lo scambio di messaggi tra applicazioni sulla rete (analogo a JDBC)Permette una comunicazione tra componenti sw ed applicazioniBasato sul paradigma peer-to-peer: il client può inviare e ricevere messaggi da qualsiasi altro clientComunicazione:

distribuita di tipo loosely coupledasincronaaffidabile

Ogni client si connette al gestore della messaggistica che fornisce gli strumenti per creare, spedire, ricevere e leggere messaggi: ènecessario un JMS container (message broker) che implementa la logica di dispatching definita dalle specifiche

SOA

19/3723/01/2006

JAVA MESSAGE SERVICE [cont]

Approccio alla messaggistica:POINT-TO-POINT (PTP o p2p):o Coda (queues)o Pull or Polling Based: i messaggi vengono prelevati dalle codeo 1 solo consumero Mittente e destinatario non hanno tempo di dipendenzao Il ricevente invia una conferma di avvento processamento (ack)

PUBLISH/SUBSCRIBE (pub/sub)o Molti consumer (One to Many)o Canale virtuale (TOPIC)o I consumer si sottoscrivono ad un Topico Push based: messaggi inviati in broadcast ai consumero Publish e subsriber hanno un timing dependency

SOA

20/3723/01/2006

JAVA MESSAGE SERVICE [cont]

Nelle specifiche JMS i messaggi possono essere consumati in due modalità:

SYNCHRONOUSLY (maniera sincrona): subscriber o receiveresplicitamente prelevano (fetch) il messaggio dalla destinazione chiamando il metodo “receive”. Questo metodo è bloccante fin tanto che non arriva un messaggio nella coda o si verifica un time outASYNCHRONOUSLY (maniera asincrona): il client si registra presso un message listener attraverso un oggetto consumer. Il messagelistener è simile ad un event listener. Se un messaggio arriva alla destinazione, il JMS provider consegna il messaggio chiamando il metodo “onMessage” del listener

SOA

21/3723/01/2006





BIBLIOGRAFIA


22/3723/01/2006

OVERVIEW

La Web Service Architecture è una istanza di SOA basata su di un particolare stack protocollareUna o più operazioni accessibili tramite URLDescritti con linguaggio standardizzatoComponibili in Web Service più complessiProtocol Architecture

ServiceComposition

ComposableService

Assurances

Description

Messaging

TransportHTTP – HTTPS – SMTP - JMS

XML - SOAP

WSDL – Policy – MetadataExchange – UDDI

TransactionsReliableMessagingSecurity

Orchestration – local perspectiveChoreography – global perspective

Stateful

Stateless

WEB SERVICE

23/3723/01/2006

UTILIZZO

I Processi Orchestrano i servizi per ottenere lo scopo voluto (orchestration)Sincronizzazione e scambio di messaggi fra diversi gruppi di webservice/processi (coreography)

BACK-END SYSTEMBACK-END SYSTEM

MESSAGGIO XMLRETERETE.NET.NET

DBMSDBMS

E-LEARNINGPLATFORM

E-LEARNINGPLATFORM

ADATTATORE

ERP

CRMADATTATORE

ERP

CRM

WEB SERVICE

INTERFACE

WEB SERVICE

24/3723/01/2006

INTERAZIONE

RPC – Remote Procedure Call (on-line)Chiamata a procedura o metodoRichiesta formattata per la specifica destinazioneScambi messaggi sincroni

WEB SERVICE INTERFACE

DBMS

WEB SERVICE INTERFACE

DBMS

DO – Document Oriented (batch)Richiesta XMLComunicazione asincronaDocumento di riferimento comune

WEB SERVICE

25/3723/01/2006

TECNOLOGIA

XML Definire i dati di un messaggioWSDL Descrivere i servizi che processano un messaggioSOAP Identificare i metodi per inviare e ricevere un messaggioUDDI Metodo per pubblicare i servizi offerti e per reperire servizi

offerti da terze parti

DATA INPUT

SCHEMAWSDL

PROCESSORESOAP

PROCESSORESOAP

PROGRAMMAO DB

DATA OUTPUT

DOCUMENTO XML

OVER INTERNET

Schema opzionale

Schema opzionale

Schema opzionale

Sender Receiver

WEB SERVICE

26/3723/01/2006

SOAP

Permette la comunicazione tra programmi attraverso InternetRemote Procedure Calls (RPC) attraverso HTTP (o SMTP)

Permette la comunicazione tra differenti sistemi operativi, linguaggi, tecnologieUn messaggio è un documento XML che contiene:

Envelope: identifica il documento XML come un messaggio SOAPHeader: (opzionale) informazioni si come elaborare il documentoBody: (necessario) contiene il messaggio vero e proprioFault: (opzionale) contiene informazioni sugli eventuali errori riscontrati durante la computazione

WEB SERVICE

27/3723/01/2006

WSDL

Web Service Description LanguageDocumento XML Descrive

L’interfaccia di un web service come insieme di possibili operazionio Un insieme di: port type (WSDL 1), interface (WSDL 2.0)o Un inseme di binding per ogni type/interfaceo Un insieme di: porte (WSDL 1), endpoint (WSDL 2.0) per ogni binding

Non descriveInformazioni sul comportamentoo Semanticao Ordine delle operazioni

WEB SERVICE

28/3723/01/2006

UDDI

Universal Description, Discovery and Integration (UDDI) permettedi individuare l’opportuno web service

Tramite direct publish il Service Provider invia il Service Descriptiondirettamente al Service Requestor attraverso meccanismi direttiTramite dynamicpublish il ServiceRequestor recupera il ServiceDescriptionattraverso un URL conosciutoTramite serviceregistry si interroga un DB UDDI che fornisce il ServiceDescriptor piùidoneo

WEB SERVICE

29/3723/01/2006

TOOL DI SVILUPPO

APPLICATION SERVERTomcat 5.5.12http://tomcat.apache.org/

Un implementazione di SOAP per l’application serverAXIS 1.3http://ws.apache.org/axis/java/releases.html(seguire la documentazione)

Un ambiente di esecuzione per l’application serverJ2SE – JRE 1.5.0_06http://java.com/it/download/index.jsp

30/3723/01/2006





BIBLIOGRAFIA


31/3723/01/2006

INTEGRATION

Fornisce la sorgente centrale della logica di business che determina le regole, le condizioni e le eccezioni relative agli scenari di workflow che possono presentarsi in una soluzione

INCAPSULARE LE INTERAZIONI TRA WEB SERVICE IN UN PROCESSO DI BUSINESS DEDICATO

Partner service

Partner service

Processservice

Processservice

Partner service

Partner service

Partner service

Partner service

Processservice

Processservice

Partner service

Partner service

Partner service

Partner service

ORCHESTRATION ENGINE

EAI

32/3723/01/2006

CORE COMPONENTS

BROKERTrasformazione dei datiMerging di documenti da diversi sorgentiProtocol switchingSTEP 1: ritrovare i dati necessari sul DBSTEP 2: validare attraverso lo schema associato i dati individuatiSTEP 3: trasformare i dati da uno schema all’altroSTEP 4: validare i dati ottenuti secondo lo schema di destinazioneSTEP 5: inserire i dati nel DB destinazione

EAI

orchestration

broker

Application BApplication A

ORCHESTRATIONIncapsulare ed eseguire le logiche del processo di businessInvocare il broker per manipolare dati, integrarsi con applicazioni esterne,…

33/3723/01/2006

ARCHITETTURE

HUB & SPOKE

orchestration

broker

Application B

Application A

BASIC

orchestration

broker

Application B

Application A

SERVICE-ENABLED

IntegrationLayer

IntegrationLayer

adapteradapterCentralizedhub logicBusiness service

EAI

34/3723/01/2006

ARCHITETTURE [cont]

MESSAGING BUS with service integration layer

Application B

Application A

Info

rmat

ion

pipi

line

Info

rmat

ion

pipi

line

Deliver to nextsubscriber

Business services

Wrapperservices

Wrapperservices

Wrapperservices

Message bus

adapter

EAI

35/3723/01/2006

ARCHITETTURE [cont]

ENTERPRISE SERVICE BUS

service.-oriented ESB integration environment

Orchestrationfrom vendor C

Orchestrationfrom vendor C

Broker fromvendor A Orchestration

from vendor A

Broker fromvendor B

Registry

EAI

36/3723/01/2006

PROGETTO ENTERPRISE SOATelecom & Junior Consulting – PILOT TIM-LA7

1a. Authorize (http)

2b. AuthorizeResp (http)

3a. Recharge (JMS)

3b. R

echa

rge

(JM

S)

OUTPUT

INPU

T

EAI

37/3723/01/2006

RIFERIMENTI BIBLIOGRAFICI

“Enterprise SOA. Service-Oriented Architecture Best Practices”D.Krafzig, K.Banke, D.Slama – Prentice Hall PTR, 2004“Service Oriented Architecture. A field guide to integrating XML and Web Services”T.Erl – Prentice Hall PTR, 2004http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/aqualogic/www.tibco.comhttp://devresource.hp.com/drc/resources/lcm4ws_overview/index.jsphttp://www.systinet.com/products/sr/overviewhttp://tomcat.apache.org/http://ws.apache.org/axis/

enterprise soa service oriented architecturetorlone.dia.uniroma3.it/sistelab/consel.pdf ·...

Documents