1 EDIFACT - WebHome < Tesi < Fabio's...

Università degli Studi di Bologna

FACOLTÀ DI SCIENZE MATEMATICHE, FISICHE E

NATURALI

Corso di Laurea in Informatica

Materia: Interazione persona-computer

STANDARD PER IL B2B A CONFRONTO:

UNA RASSEGNA

Relatore:

Chiar.mo Prof. FABIO VITALI

Tesi di Laurea di:

LUCA MASELLI

Parole chiave: B2B, XML, ebXML, UBL, BizTalk

SESSIONE III

Anno Accademico 2003/2004

INDICE

Introduzione...................................................................................................7

1 Origini del B2B.........................................................................................11

1.1 Il commercio e l’uomo.......................................................................11

1.2 La comunicazione nel commercio.....................................................12

1.3 Definizione di B2B............................................................................13

1.4 UN/EDIFACT....................................................................................14

1.5 Struttura di un messaggio EDIFACT.................................................16

2 SOAP e protocolli webservice..................................................................21

2.1 I webservice.......................................................................................21

2.1.1 Definizione di webservice...........................................................21

2.1.2 Nascita dei Webservice...............................................................23

2.2 SOAP.................................................................................................25

2.2.1 Prime implementazioni: XML-RPC...........................................25

2.2.2 Definizione di SOAP..................................................................26

2.2.3 L’architettura di SOAP...............................................................27

2.2.4 Elementi di un messaggio SOAP................................................28

3 BIZTALK.................................................................................................31

3.1 La nascita di BizTalk.........................................................................31

3.2 Il consorzio per Biztalk......................................................................32

3.3 Miscrosoft BizTalk Server.................................................................33

3.4 Il framework di BizTalk.....................................................................34

3.5 Requisiti del sistema..........................................................................35

3.5.1 Requisiti di sistema per un server...............................................35

3.5.2 Requisiti di sistema per un client................................................36

3.6 Panoramica su BizTalk Server...........................................................36

3.6.1 Regole e politica della ditta.........................................................37

3.6.2 Ambiente di sviluppo unificato...................................................37

3.6.3 Progettazione di processi aziendali complessi............................39

3.6.4 Sistema di tracciamento realtime per amministrazione e debug.39

3.6.5 Gestione dei partner commerciali di larga scala.........................40

3.6.6 Integrazione in Microsoft Office e Microsoft InfoPath..............41

3.6.7 Semplificazione dell’interazione tra sviluppatori ed analisti......42

3.6.8 Monitoraggio dell’attività commerciale.....................................43

3.7 Acceleratori per BizTalk Server........................................................44

3.8 Adattatori...........................................................................................45

4 ebXML......................................................................................................51

4.1 Definizione di ebXML.......................................................................51

4.2 Perché ebXML?.................................................................................51

4.3 Un sistema ad hoc..............................................................................52

4.4 Panoramica su ebXML......................................................................53

4.5 Struttura di ebXML............................................................................54

4.6 Il cuore di ebXML: la Registry..........................................................56

4.6.1 Modello informativo di una registry ebXML.............................56

4.6.2 Interfacce della Registry ebXML................................................57

4.7 Fasi di funzionamento di ebXML......................................................58

4.7.1 Fase implementativa...................................................................58

4.7.2 Fase di scoperta – recupero.........................................................59

4.7.3 Fase di esecuzione......................................................................60

4.8 Formato dei messaggi ebXML..........................................................61

4.8.1 Header MIME delle parti del messaggio....................................62

4.8.2 Reliable Messaging.....................................................................63

5 UBL..........................................................................................................65

5.1 Definizione di UBL...........................................................................65

5.2 Breve storia di UBL...........................................................................66

5.3 Perché UBL?......................................................................................66

5.4 Struttura di UBL................................................................................68

5.4.1 Esempio di Schema XSD............................................................69

5.5 Il ciclo ordine-fattura.........................................................................72

6 Confronto tra gli standard.........................................................................75

6.1 Il dualismo tra i colossi e gli altri.......................................................75

6.2 Confronto fra livelli...........................................................................76

6.3 Qual è lo standard adatto?..................................................................78

7 Conclusioni...............................................................................................79

RIFERIMENTI............................................................................................81

Fonti in rete..............................................................................................81

Altre risorse in rete...................................................................................83

Fonti Bibliografiche.................................................................................84

5

INTRODUZIONE

Questa tesi tratta alcuni dei più noti standard per il B2B, ovvero quella

categoria di linguaggi, programmi, schemi e convenzioni utilizzati nei

rapporti commerciali tra aziende ed altre aziende piuttosto che tra aziende e

privati.

Il commercio è sempre stato un elemento di fondamentale importanza sia

per la crescita che per il progresso della società.

La comunicazione ne è stato un aspetto fondamentale poiché ha permesso

di espandere le proprie possibilità commerciali al di fuori della comunità di

origine.

Una volta superati i problemi linguistici e logistici, si è pensato di poter

migliorare l’aspetto del trasferimento dei dati. Già negli anni 70 si pensò di

realizzare una serie di protocolli (inteso come insieme di documenti e

procedure) standard che permettessero l’alleggerimento (dal punto di vista

burocratico e cartaceo) dei processi commerciali.

EDIFACT fu la prima risposta a questa domanda, giunta molto prima della

nascita di XML.

I primi sviluppi di EDIFACT furono una serie di norme per la

regolamentazione del commercio internazionale, ma visti gli strumenti a

disposizione in quegli anni, il risultato non fu così apprezzato.

Quello che ne seguì non fu così rilevante come invece la creazione di XML

e dei linguaggi di markup derivati. Grazie ad esso era possibile definire un

numero illimitato di schema per soddisfare ogni esigenza di formato per la

descrizione dei dati.

Nel frattempo Internet si era espansa in modo capillare, accogliendo anche

le piccole realtà nel commercio elettronico. La richiesta di fornire e ottenere

servizi via rete è andata via via crescendo e l’interesse in questa direzione

ha raggiunto livelli non immaginabili.

SOAP, un protocollo basato su XML che fornisce un sistema di

messaggistica per la comunicazione tra partner commerciali, è diventato lo

standard nel suo campo. Il suo meritato successo è dovuto anche

all’utilizzo di HTTP come protocollo di comunicazione, ancora oggi il più

diffuso nell’ambito della rete globale.

Successivamente, affidandosi a SOAP per il formato della messaggistica, si

sono costruiti altri livelli per l’implementazione del modello di commercio

via rete.

ebXML è un particolare insieme di schema XML che basandosi su un

vocabolario di termini comuni, immagazzinati in un registro condiviso,

permette la standardizzazione delle comunicazioni commerciali. In aggiunta

ai molti vantaggi, ebXML ha però dimostrato di avere una lacuna riguardo

la gestione degli specifici payload nei messaggi XML.

Per questo motivo è stato ripreso, dopo averne inizialmente accantonato il

progetto, UBL, che fornisce una serie di librerie per soddisfare una quantità

ancor maggiore –rispetto a ebXML e XML in genere– di specifiche

riguardanti settori ancor più dettagliati dell’e-commerce. Uno dei suoi punti

di forza risiedeva nel fatto che non sarebbe stato coperto da copyright.

La risposta che Microsoft ha dato a questo crescente interesse verso

l’unificazione degli strumenti per il B2B, è BizTalk. Il sistema risulta

sicuramente più omogeneo degli altri proposti dai vari comitati capeggiati

da OASIS, e sfrutta a pieno il fatto di operare all’interno di un sistema

operativo proprietario e pertanto ben noto e totalmente controllabile.

Sulla scia di Microsoft anche altri grossi aziende dell’IT hanno prodotto

pacchetti completi per la gestione del B2B, come IBM, HP, SUN, ecc…

Dopo la panoramica degli standard proposti, viene tentato un confronto tra

di essi, cercando di comprenderne la collocazione nel modello ipotetico di

un sistema per il B2B. Il risultato è che soprattutto per i sistemi definiti

completi (es. BizTalk), non si può trovare un parallelismo esatto. L’alto

stadio di integrazione fa sì che certi livelli teorizzati divisi vengano

implementati in modo monolitico. Per quel che riguarda la scelta di uno o

8

dell’altro sistema per il B2B rimane fondamentale l’opzione di mantenere

l’eventuale sistema pre-esistente o di cambiarlo (e quindi investire risorse e

denaro). Sebbene la proposta opensource di UBL sia allettante poiché

liberamente utilizzabile e modificabile, risulta ancora insufficiente per

definirlo un sistema ideale che, ad oggi, sembra sia a disposizione delle sole

grandi aziende IT che possono fornire un prodotto completo.

L’unica certezza che abbiamo è che il commercio elettronico (e di

conseguenza il B2B che ne è parte consistente) sia fortemente in

espansione. Se si deciderà di supportare altre iniziative improntate sul libero

utilizzo di software (come UBL), probabilmente si otterrà una crescita

ancora maggiore di quella odierna nell’ambito del software per il B2B. Gli

alti costi dei sistemi completi sembrano essere ancora alla base delle scelte

di cambiamento o di adeguamento di una ditta che si pone davanti al

commercio elettronico. Non è escluso quindi (anzi, è auspicabile) che con

un sempre crescente numero di aziende richiedenti i software freeware si

possa giungere ad un mercato davvero libero alla portata di tutti.

9

1 ORIGINI DEL B2B

1.1 Il commercio e l’uomo

Il commercio è sempre stato uno dei punti cardine per ogni società dalla

nascita dell’uomo moderno ad oggi. Esclusione fatta per le comunità

autosufficienti o geograficamente isolate, è stato il tramite per il progresso e

per l’evoluzione stessa del genere umano. Partendo dal baratto si è giunti

alle borse finanziarie, in cui non solo si commerciano i beni, ma anche le

previsioni di successo di tali beni. Si è partiti dalle strade lastricate dai

Romani per agevolare i carri trainati da animali, e attraverso i grandi

navigatori tornati dall’Oriente si è giunti ai corrieri espressi con a

disposizione grandi aerei transcontinentali.

Ma se da una parte non è possibile –con le tecnologie attuali– accelerare

ulteriormente il trasferimento fisico delle merci, si può operare invece

sull’organizzazione del commercio: i contatti, i documenti, i pagamenti;

tutto quanto, in pratica, abbia a che fare con l’iter burocratico di un affare

commerciale. Sono assai remoti i tempi in cui un mercante partiva con le

navi per le colonie e non si sapeva se e quando sarebbe tornato con il carico

di merce acquistata. Oggi possiamo visionare i prodotti su internet,

acquistarli con l’ausilio di carte di credito, sapere momento per momento lo

stato dell’ordine, la posizione geografica della merce e riceverla a casa

senza muovere un dito. E’ ovvio che le infrastrutture necessarie per questo

tipo di attività sono complesse e non è pensabile che non siano tali; devono

però soddisfare un requisito fondamentale, senza il quale anche con le

tecnologie più evolute non sarebbero in grado di fornire un servizio

efficiente: devono comunicare efficacemente tra loro.

Quello che a noi sembra un’operazione lineare e relativamente semplice

come l’acquisto di un prodotto via internet, è il frutto della perfetta

comunicazione tra una serie di aziende fornitrici di servizi diversi, che

avranno come obiettivo finale quello di farci arrivare il pacco contenente il

prodotto da noi acquistato, al più un paio di giorni dopo il momento in cui

abbiamo riempito un modulo on line su un sito che vende on line.

Vediamo perciò che la definizione di commercio elettronico non può

fermarsi all’informatizzazione delle operazioni prima svolte tramite

supporto cartaceo, ma implica il cambiamento radicale di tutti quei servizi

che stanno dietro ad una transazione commerciale, basati soprattutto sulla

collaborazione efficace di tutti gli attori in gioco.

1.2 La comunicazione nel commercio

Come il commercio, ancor più il tema della comunicazione è stato

fondamentale nella storia del genere umano. Sin dagli albori, quando si

intrapresero le prime attività commerciali, il mercante che conosceva

diversi modi di comunicare aveva sicuramente dei vantaggi, perché poteva

relazionarsi con più persone e poteva espandere la sua attività anche a

regioni lontane, sia geograficamente che culturalmente. Di conseguenza

poteva ottenere merci provenienti anche da terre molto lontane e –pertanto–

di sempre maggior valore. Pensiamo semplicemente ai primi esploratori che

partivano dall’Europa con navi vuote e tornavano con ogni sorta di merce

rara proveniente dai paesi lontani. La possibilità di comunicare nel maggior

numero di modi (linguaggi) possibile, quindi, si è sempre tradotta con un

aumento delle attività commerciali e di scambio. La conoscenza delle

lingue, fino al secolo scorso, ha fatto la differenza nel commercio: se ancora

oggi possiamo parlare francese in Africa e in Oceania, inglese in India e in

Australia, spagnolo in America Latina, è perché nelle colonie si è cercato di

appianare –in modo più o meno ortodosso– il problema della differenza

linguistica.

Al giorno d’oggi, in cui nella stragrande maggioranza delle nazioni vige il

libero commercio, e sia per i lasciti dei paesi colonizzatori, sia per

l’aumentata scolarizzazione (e conseguente studio di lingue straniere),

l’elemento che può fare la differenza non è più la lingua, poiché i metodi di

comunicazione sono divenuti alla portata di tutti, bensì una piattaforma

comune di procedure e protocolli commerciali.

Per esempio, supponiamo che lo Stato A debba acquistare dei beni dallo

Stato B, che a sua volta li debba importare dallo Stato C.

Supponiamo ora che tra lo Stato A e lo Stato B ci siano accordi

commerciali per i quali le merci non debbano essere sottoposte a controlli

doganali al fine di velocizzare le procedure di vendita. Se tra lo Stato B e lo

Stato C invece non ci fossero accordi simili, e le merci dovessero sostare

diversi giorni alla frontiera poiché dettato dall’iter burocratico, è

comprensibile che non solo lo Stato B subirebbe ritardi, ma indirettamente

anche lo Stato A.

E’ facile capire quindi che sta nell’interesse di tutti gli Stati avere

facilitazioni, dal punto di vista burocratico, nella produzione, nella vendita e

nella distribuzione dei propri prodotti. Proprio per questo motivo si è deciso

di agire a livello internazionale, per creare una proposta globale volta ad

eliminare i problemi derivanti dalla lentezza e dalla macchinosità della

burocrazia.

1.3 Definizione di B2B

Con l’acronimo B2B si intende Business To Business ovvero “imprese per

imprese”. A questa categoria vengono fatti appartenere tutti i servizi dell’e-

commerce (dati, procedure, etc.) forniti da aziende per altre aziende. L’altro

lato della medaglia dell’e-commerce è il B2C ovvero il Business To

Consumer (impresa per il consumatore). Nonostante le due tipologie di

affari sembrino differenziarsi solamente nel fruitore finale del servizio, in

realtà il framework e le procedure necessarie allo svolgimento dei passaggi

tra le parti sono assai differenti. È infatti impensabile che si adottino le

13

stesse modalità di gestione per la vendita all’ingrosso e la vendita al

dettaglio; questa è una regola del commercio stesso.

Nella tabella sottostante possiamo verificare le principali differenze tra un

rapporto commerciale di tipo B2B e uno di tipo B2C; prendendo in

considerazione degli elementi alla base di una relazione (comunicazione,

input/output dati, applicativi necessari). Risulta subito chiaro che il primo

necessita di più risorse o di risorse più complesse.

Elementi considerati Applicazione B2B Applicazione B2C

Accordi sul processo di

transazione

Accordo bilaterale tra

le parti

Solitamente deciso dal

fornitore del servizio

Protocolli di

comunicazione

HTTP, SMTP, FTP,

TCP/IP, …HTTP

Input dati XML HTML GET/POST

Output dati XML HTML

Applicativo client Apposito applicativo Browser Internet

Due delle differenze che risultano più facilmente individuabili sono il

protocollo di comunicazione e l’interscambio di dati. In uno scenario B2B

sono permessi una grande varietà di protocolli di comunicazione ma

l’input/output è prevalentemente in formato XML, nel caso del B2C invece

si utilizza prevalentemente HTTP per la trasmissione dei dati e HTML

nell’i/o.

1.4 UN/EDIFACT

Nel marzo del 1990, una commissione delle Nazioni Unite si incontrò per

affrontare il tema della comunicazione nel commercio globale. In quella

sede vennero definite delle regole per lo scambio di dati elettronici

nell’amministrazione, nel commercio e nei trasporti. La commissione

prende e sviluppa una serie di regole che prende il nome di United Nations

14

rules for Electronic Data Interchange For Administration, Commerce and

Transport (UN/EDIFACT).

Leggendo gli atti di quel congresso [UNE00] è chiaro che il primo passo

che si intendeva compiere era quello di semplificare la parte burocratica.

I servizi commerciali, infatti, hanno a che fare profondamente con i requisiti

e le procedure del flusso di informazioni necessari per il movimento

internazionale dei beni. Solitamente questo flusso è sempre stato

convalidato sotto forma di documenti cartacei e procedure manuali che li

gestivano; era quindi comprensibile che il primo approccio dovesse

concentrarsi sulla semplificazione e soprattutto sulla standardizzazione dei

documenti per il commercio internazionale.

Gli sviluppi tecnologici, nel frattempo, avevano fornito una gestione

alternativa ai metodi di trasmissione delle informazioni; inoltre la visione

della cooperazione internazionale era stata estesa dall’armonizzazione dei

documenti ad una ricerca più approfondita sull’identificazione delle

informazioni basilari necessarie e lo sviluppo di metodologie interamente

nuove per soddisfarle.

In realtà già nel 1972 si intravedeva la strada da percorrere, quando si

trasformò la commissione denominata UN Working Party on the

Simplification and Standardization of External Trade Documents (gruppo

operativo per la semplificazione e standardizzazione dei documenti per il

commercio estero, attiva dal 1960) in UN Working Party on Facilitation of

International Trade Procedures (gruppo operativo per la semplificazione

delle procedure di commercio internazionale). Lo scopo di questa

commissione era quello di sviluppare una terminologia standard per il

commercio internazionale e di uniformare il sistema da utilizzare per la

trasmissione automatica dei dati relativi.

15

1.5 Struttura di un messaggio EDIFACT

Vediamo la struttura di un messaggio EDIFACT, come risulta dalla

versione del 1988 e definitivamente modificata nel 1990 (registrata come

ISO9735).

In Europa, sotto la supervisione del Western European EDIFACT Board,

hanno lavorato dieci gruppi di sviluppo differenti per creare standard

diversi a seconda della tipologia del campo d’applicazione:

Commercio

Trasporti

Personalizzazioni

Finanza

Costruzioni

Statistica

Assicurazioni

Turismo

Sanità

Amministrazione sociale

Lo standard propone regole sintattiche per la creazione dei messaggi che si

scambiano i partner commerciali. Analogamente al modello ISO/OSI dei

protocolli e dei servizi, lo standard specifica diversi livelli che si

differenziano solo per i set di caratteri. Alcuni caratteri sono riservati per

essere usati come terminatori, separatori e di rilascio. La struttura appare in

questo modo:

16

Figura 1 – Struttura di un messaggio EDIFACT

I segmenti e gli elementi in un messaggio possono essere opzionali. Nella

struttura sono spesso definiti per essere ripetuti e/o innestati. La struttura

del messaggio può essere descritta usando un determinato messaggio tipo

DIRDEF (Directory Definition) oppure tipo KUVAUS (descrizione del

messaggio). Un traduttore potrebbe interpretarlo leggendo tale descrizione.

Figura 2 – Semplice esempio di struttura di un messaggio

17

Lo schema del messaggio dovrebbe essere letto da sinistra a destra e

dall’alto al basso. Quindi nell’esempio di Figura 2 i segmenti di dati

verrebbero letti in questo ordine:

1) AAA

2) BBB

3) CCC

4) DDD

5) DDD

6) DDD

7) DDD

8) CCC

9) DDD

10) EEE

11) FFF

12) FFF

13) GGG

14) GGG

15) FFF

16) HHH

17) III

Un segmento di dati è definito per contenere determinati elementi. Sono

definiti i requisiti (mandatory, obbligatorio o conditional, facoltativo) e i

formati (alfabetici, alfanumerici o numerici e il massimo numero dei

caratteri ammessi).

Ecco un esempio di segmento di dati:

18

Figura 3 – Esempio di segmento di dati

I dati corrispondenti risultano pertanto come segue:FTX+OSI+++This is just informative text'

FTX+OSI+++Text can be devided:in separate parts:or coded.+ENG'

FTX+ZZZ+A+123:NN:BBB'

19

2 SOAP E PROTOCOLLI WEBSERVICE

2.1 I webservice

2.1.1 Definizione di webservice

Ad oggi non esiste una definizione ufficiale del termine webservice; i

concetti che lo implementano sono chiari ma neppure W3C è sceso nel

dettaglio per darne una definizione precisa.

Microsoft [SKO02] rifiuta la seguente definizione basilare, perché troppo

riduttiva:

Componente di applicazione accessibile tramite un protocollo

aperto

Ecco invece come –sempre secondo Microsoft– verrebbero definiti in modo

più adeguato:

I web service rappresentano una nuova piattaforma sulla

quale gli sviluppatori costruiscono le stesse applicazioni

distribuite come hanno sempre fatto, ma questa volta con

l’interoperabilità come massima priorità.

Tra le molte e diverse definizioni che si possono trovare riguardo al termine

“web service”, ne cito due: la prima presa da un sito commerciale, la

seconda da un sito no-profit.

La prima citazione [DAT04] enfatizza l’importanza dell’indipendenza dalla

piattaforma:

I Web service sono un meccanismo per rendere accessibile la

funzionalità delle applicazioni software e relativi dati

attraverso internet utilizzando un protocollo standard.

Questo concetto è chiamato servizio in quanto abilita una

periferica qualsiasi che può accedere ad internet di servirsi di

un altro computer come provider di una funzione ben definita

(il servizio) o il dato. Il web service è pubblicato utilizzando

dei protocolli standard in modo che possa essere trovato,

identificato, verificato ed utilizzato da un altro computer o

periferica che sia in grado di accedervi. La neutralità è la

base del concetto dei Web service. Un web service DEVE

essere neutrale dal fornitore, dalla piattaforma, dal

protocollo e dal linguaggio

La seconda citazione [LON04], più sintetica, fonda le basi dei webservice

sul linguaggio XML:

Web service: applicazione identificata da un URI la cui

specifica può essere definita, descritta e pubblicata mediante

meccanismi basati su XML e che supporta l'interazione

diretta con altre applicazioni mediante messaggistica XML su

protocolli Internet-based.

Entrambe le definizioni centrano l’obiettivo, in quanto i punti di forza di un

webservice sono esattamente l’essere basato su XML e al contempo essere

piattaforma indipendente.

Ecco invece l’ultima definizione [Cau01] che sembra riassumere tutte le

altre in modo completo:

I webservice sono applicazioni modulari auto-descrittive che

possono essere pubblicate, localizzate e invocate da qualsiasi

punto del Web o da qualsiasi rete locale basata sugli

standard di Internet. Essi combinano i migliori aspetti della

programmazione basata sui componenti e quella su web;

vengono distribuiti sottoforma di moduli che possono essere

riutilizzati senza preoccuparsi di come il servizio venga

implementato, del linguaggio e del sistema operativo in cui è

stato scritto, di che moduli sono stati necessari per la sua

creazione. Questa filosofia è anche nota col nome di “black

box reuse”. I web service sono accessibili grazie a protocolli

web come HTTP o SMTP e sono basati su XML.

2.1.2 Nascita dei Webservice

Letteralmente, i webservice sono servizi (forniti via) web. Con l’evolversi

delle tecnologie nel tempo, ci si sta spingendo verso la globalizzazione

della rete internet, non tanto per il raggiungimento di quante più

informazioni sia possibile reperire, quanto per l’aumento esponenziale dei

computer collegati alla rete mondiale. Fino a qualche tempo fa, la realtà di

molti utilizzatori di computer (soprattutto in ambito industriale) vedeva reti

aziendali LAN, anche in larga scala, ma senza che queste avessero un

accesso internet; ogni macchina era fine a se stessa o, al massimo,

all’ambito locale della ditta.

Il passo successivo è stato quello di permettere ai computer un accesso alla

rete, principalmente con lo scopo di ottenere e scambiare informazioni con

computer diversi (es. altre filiali della stessa azienda o collaborazione con

altre aziende).

La nascita dei webservice è dovuta ad un ulteriore passo in avanti: la

sperimentazione di fornire non solo informazioni, ma anche servizi veri e

propri. Si passa dalla semplice consultazione alla richiesta di eseguire

operazioni. La differenza è sottile, in realtà presuppone un meccanismo a

monte assai più complesso ma allo stesso tempo flessibile e quindi

personalizzabile.

Vediamo un semplice esempio:

supponiamo che un ipotetico sito internet renda disponibile l’elenco

telefonico di una città.

Prima dell’avvento dei webservice, tutti i nomi degli utenti telefonici

sarebbero stati riportati tramite diverse pagine HTML contenenti, in ordine

alfabetico, tutti gli utenti:

23

Figura 4 - Esempio di gestione dati senza webservice

Molto semplice, ma assai lungo e scomodo, immaginando un numero

ragionevolmente grande di utenti.

Applicando invece un meccanismo di archiviazione dati e di ricerca tramite

degli script web-based (asp, php o un qualsiasi linguaggio server-side) si

può modificare il modello sopraccitato in questo modo:

Figura 5 – Esempio di gestione dati gestiti con webservice

24

Tralasciando il fattore estetico, dal punto di vista del carico di calcolo, la

seconda soluzione è sicuramente più leggera e veloce in quanto il

caricamento dei dati avviene on demand e la ricerca può essere agevolata

dalle tecnologie che stanno a monte, ovvero dalla parte del server che

risponde. Non solo, ci può essere una politica di selezione che permetta o

meno l’accesso a certi contenuti a seconda dell’utente che sta richiedendo le

risorse, e questo apre infinite possibilità di personalizzazione.

Nel capitolo successivo vedremo SOAP, un protocollo che è diventato lo

Standard per il web service information exchange.

2.2 SOAP

2.2.1 Prime implementazioni: XML-RPC

Quando venne sviluppato XML, verso la fine degli anni 90, subito gli

operatori del campo ebbero a disposizione un nuovo strumento per

esprimere una complessa struttura di informazioni e messaggi in modo

uniforme e auto-esplicativo. Questo portò ad usare XML nella

formattazione dello scambio di messaggi tra i vari sistemi. Un approccio di

questo tipo avrebbe permesso di scambiare messaggi ben formattati tra

un’insieme eterogeneo di sistemi in un modo estensibile, auto-descrittivo e

auto-documentante, senza preoccuparsi di quale sistema operativo o

linguaggio di ambiente fosse presente su quei sistemi.

Una delle prime e più note implementazioni di protocolli di comunicazione

basati su XML è XML-RPC (XML Remote Procedure Call). Nello

specifico permette di richiamare procedure su macchine remote senza

doversi preoccupare riguardo le specifiche dei loro sistemi operativi o dei

linguaggi d’ambiente presenti su di esse. Queste macchine potrebbero

essere ovunque su Internet o più semplicemente all’interno di una Intranet,

unico requisito è che siano connesse via HTTP.

XML-RPC è un protocollo molto semplice e facilmente utilizzabile

(contiene infatti solo XML e nessuna parte di dati binari). Proprio per

25

questo sono state create varie implementazioni per i maggiori linguaggi e

sistemi operativi. A dispetto di questi punti di forza e del fatto che XML-

RPC fosse precursore nel suo campo, non venne scelto dalla maggior parte

di distributori (di software); sorte differente toccò invece al suo successore,

SOAP.

Due importanti lacune di XML-RPC furono la “prolissità” nella

rappresentazione dei dati e la mancanza di una scrittura agevole di questi.

Esso venne messo alla prova attraverso la codifica di strutture e di altri tipi

più complessi di dati come gli array. Quando XML-RPC venne creato,

infatti, l’idea dei tipi di dati XML specificati tramite uno schema XML, era

ancora lontano dall’essere realizzata. Tutta l’esperienza, positiva e negativa,

ottenuta con il lavoro su XML-RPC, venne utilizzata nella creazione di

SOAP.

2.2.2 Definizione di SOAP

La definizione di SOAP data dal W3C, il consorzio che sviluppa le

tecnologie (specifiche tecniche, linee guida, software e strumenti) per

l’utilizzo (al meglio) del Web è:

S.O.A.P. (Simple Object Access Protocol) è un protocollo per

lo scambio di informazioni in un ambiente distribuito e

decentralizzato.

E’ un protocollo basato su XML che consiste di tre elementi:

Un busta (envelope) che definisce un framework per la

descrizione del contenuto di un messaggio e per le modalità

di utilizzo dello stesso.

Un insieme di regole per esprimere istanze di tipi di dati

definiti da una applicazione.

Una convenzione per rappresentare le chiamate di procedure

remote (RPC- Remote Procedure Call) e relative risposte.

26

Può essere utilizzato in concomitanza con una varietà di altri

protocolli.

In questa definizione [W3C00] viene citata la possibilità di integrazione con

altri protocolli per il trasporto dati (FTP, MIME, etc.) ma le specifiche

descritte fanno riferimento esclusivamente a HTTP e HTTP Extension

Framework.

Si è optato per HTTP in modo da ovviare alle problematiche risultanti da un

utilizzo di SOAP per la comunicazione di due applicazioni in un ambiente

in cui siano presenti firewall, proxy, etc.

Nello specifico, un messaggio SOAP, viene implementato come parte di

una richiesta o di una risposta HTTP.

Un altro elemento che ha spinto per l’utilizzo del protocollo HTTP come

tramite di SOAP è stata la sua grande diffusione: si può infatti affermare

con discreta certezza che praticamente ogni computer in connessione di rete

supporti il protocollo HTTP.

Ne risulta che lo scopo finale di SOAP sia di garantire una comunicazione

computazionalmente semplice e leggera tra due applicativi in uno scenario

in cui possono sussistere piattaforme diverse su infrastrutture preesistenti.

2.2.3 L’architettura di SOAP

Il modello classico di scambio messaggi in SOAP prevede un mittente che

manda un messaggio ad un destinatario. A seconda del tipo di operazione

richiesta nel messaggio, il destinatario dovrà o meno mandare una conferma

(risposta) alla richiesta del mittente.

Operativamente, quello che accade quando un applicativo SOAP riceve un

messaggio da un altro applicativo, esegue la seguente sequenza di verifiche:

Identificazione del messaggio in tutte le sue parti.

Verifica che le parti precedentemente identificate siano supportate,

con conseguente tralascio delle parti opzionali.

27

Eventuale inoltro del messaggio verso altre destinazioni se non si è il

destinatario finale; prima dello smistamento verso il destinatario

successivo, eliminazione o aggiunta di informazioni al messaggio

stesso.

Figura 6 – Schema funzionamento messaggistica SOAP

2.2.4 Elementi di un messaggio SOAP

Per facilitare la comprensione del messaggio SOAP, si è pensato di

strutturarlo come una comune lettera postale.

I tre elementi che ne compongono il modello sono:

un Envelope (busta) da contenitore esterno

un Header (intestazione) di varie informazioni per la corretta

spedizione del messaggio

un Body (corpo) con il testo del messaggio

28

Da un punto di vista sintattico XML, devono essere soddisfatte le seguenti

regole:

elemento Envelope: radice del documento (obbligatorio); può

contenere dichiarazioni di namespace ad hoc e altri attributi.

elemento Header: (opzionale); se presente, deve essere il primo figlio

dell’elemento Envelope; può contenere elementi figli, ma solo se

qualificati da un namespace.

elemento Body: (obbligatorio); deve essere il primo figlio

dell’elemento Envelope o il secondo se è presente l’elemento

Header; come l’elemento Header può contenere elementi figli, ma

solo se qualificati da un namespace.

Graficamente si potrebbe rappresentare un messaggio SOAP nel modo

seguente:

Figura 7 – Rappresentazione grafica di un messaggio SOAP

Ecco infine un esempio di ipotetico messaggio SOAP tradotto in pseudo-

sintassi XML<names:Envelope dichiarazione namespace>

<names:Header>

Attributi del messaggio

29

</names:Header>

<names:Body>

Dati da spedire

<names:Fault>

Gestione degli errori

</names:Fault>

</names:Body>

</names:Envelope>

30

3 BIZTALK

3.1 La nascita di BizTalk

Nel settembre 1998, a Las Vegas, Microsoft ospita il suo primo Business

Application Conference in cui rivela la sua visione del futuro delle

infrastrutture informatiche per il commercio. Questa visione fa

pesantemente affidamento sulla tecnologia COM e DCOM (COM

distribuita) per creare un’architettura internetwork chiamata Windows

Distributed interNet Applications (windows DNA).

Microsoft anticipa alle aziende che utilizzerà Windows DNA per creare

processi digitali interni basati su una combinazione di hardware e di

software che viene chiamato Digital Nervous System. Questo fornirà alle

aziende l’opportunità di creare informazioni condivise, di appiattire la

struttura di gestione e potenziare gli utenti nella presa di decisioni. Tutto ciò

per abbassare le barriere che esistono tra i vari partner commerciali.

Nel marzo successivo, a San Francisco, durante il Commerce Solutions

Briefing, Microsoft espone alla stampa la strategia che intende adottare nei

due anni successivi per i suoi prodotti con tecnologie Internet:

un’architettura per il commercio basata sul nuovo (per l’epoca) eXtensible

Markup Language (XML) e che prenderà il nome di BizTalk.

L’intento è quello di riunire tutte le piccole e medie imprese in una unica

rete di partner Microsoft, e che possano utilizzare un framework attraverso

varie piattaforme per eseguire transazioni economiche.

In quel periodo si puntava molto sul crescente interesse che si stava

formando intorno a XML e lo si voleva far divenire lo standard per lo

scambio inter-piattaforma dei dati, proprio come RTF (Rich Text Format)

lo era per lo i file di testo formattati.

Il perché XML era così importante, è facile da capirsi: ognuno poteva

creare i tag (delimitatori) desiderati per spiegare la struttura e i contenuti dei

dati stessi. Era veramente semplice suddividere i dati in tag e referenziarli,

indicizzati, su Web. Il suo punto di forza era che il mittente e il destinatario

del messaggio potevano accordarsi sui tag da utilizzare, e fare affidamento

quindi su applicativi che si occupavano del parsing, agendo di conseguenza

secondo schemi concordati a priori.

3.2 Il consorzio per Biztalk

BizTalk è un progetto nato dall’unione di un consorzio di industrie mondiali

sia del campo dell’informatica che di altri ambiti.

L’obiettivo è quello di implementare il B2B con degli applicativi che

comunichino tra loro anche in ambiente eterogeneo da un punto di vista del

software.

Tale scopo può risultare abbastanza ambizioso visto che fino a qualche

anno fa la tendenza delle aziende era quello di crearsi reti interne per la

gestione delle risorse e di mantenere le fonti dei dati in modo appositamente

privato perché ritenuto più sicuro. Un cambio di rotta come quello che stava

attraversando la politica produttiva, metteva in serio problema l’azienda che

si vedeva rallentata –nel processo produttivo– dalla scelta di rimanere

autonoma, fatta quando ancora non si immaginava potesse esistere il B2B.

La situazione attuale è che il livello di informatizzazione è giunto ad un

bivio a causa delle scelte progettuali del passato. Se si vuole migliorare

ancora e rendersi competitivi sul mercato (sempre più affollato da società

dell’industria informatica o che fanno uso della stessa) occorre rendere

ancor più veloce lo scambio di dati e automatizzare il maggior numero di

procedure possibili per lo scambio di servizi.

Di conseguenza a questi nuovi requisiti di competitività, subentrano anche

problematiche di tipo economico.

Non è pensabile che grandi aziende che hanno investito considerevoli

somme di denaro in sistemi che oggi risultano al limite dell’obsoleto non si

pongano il problema del “come muoversi”. Meglio investire in nuovi

programmi o cercare di adeguare i sistemi esistenti?

La risposta varia a seconda della situazione. Certo è che alla base del

progetto BizTalk c’era anche la volontà di venire incontro alle aziende in

modo non totale: non c’era quindi l’intenzione di obbligare la sostituzione

totale del sistema preesistente.

3.3 Miscrosoft BizTalk Server

BizTalk Server è la proposta di Microsoft per affrontare il tema B2B

nell’ambito del progetto BizTalk.

Il suo scopo finale è quello di fornire una piattaforma inserita nella famiglia

Windows Server che permetta all’utente di integrare in modo efficiente i

sistemi, gli impiegati e i partner commerciali in modo più veloce rispetto al

passato [MIC04a].

Citando il sito Microsoft [MIC04b]:

[BizTalk] è un potente strumento di gestione per i moderni

processi di business sia interni all'azienda che interaziendali.

Il pieno supporto XML e SOAP 1.1 lo rende una piattaforma

programmabile ed estremamente flessibile, in grado di

assicurare veloci e sicure relazioni B2B su Internet.

Al giorno d’oggi, nell’economia mondiale, le aziende necessitano di

integrare applicativi, sistemi e tecnologie provenienti da una grande varietà

di risorse. Per facilitare questo compito Microsoft tenta di fornire il sistema

più integrato possibile ed espande l’offerta con altri prodotti che fungono da

acceleratori e adattatori verso e attraverso i partner commerciali.

E’ ovvio che l’obiettivo chiave della campagna pubblicitaria di Microsoft,

l’integrazione, diventa facilmente raggiungibile dal momento in cui la

33

piattaforma, i sistemi di sviluppo nonché i motori sottostanti sono stati

sviluppati dalla stessa Microsoft.1

Come vedremo più avanti nei requisiti di sistema, BizTalk Server punta

sull’utilizzo di tutte le potenzialità fornite dagli altri prodotti della stessa

famiglia installati sulla macchina.

Per sfruttare ancora meglio le ultime versioni dei suddetti software, si è

deciso, con la versione 2004, di non supportare più sistemi operativi

precedenti a Windows 2000. Anche questa risulta una scelta politica poco

popolare ma necessaria per reinvestire fruttuosamente una serie di risorse

attualmente impegnate nel mantenimento della compatibilità all’indietro.

3.4 Il framework di BizTalk

Proprio perché BizTalk deve fornire una piattaforma comune a tutti per lo

scambio di informazioni, è comprensibile che debba sottostare esso stesso a

regole ben precise, soprattutto per quel che riguarda la sua struttura.

Ecco di seguito come deve essere necessariamente strutturato un messaggio

BizTalk:

<BizTalk_1 xmlns=”namespace”>

<Header>

<Delivery>

<Message>

<From>

</From>

<To>

</To>

</Message>

1 Questo tema, compreso il problema del monopolio di mercato e l’antitrust, sono

argomenti assai dibattuti e che sono stati protagonisti di diversi ed importanti capitoli

della storia del software moderno (alcuni dei quali ancora aperti), ma non verranno trattati

in questa tesi.

34

</Delivery>

<Manifest>

</Manifest>

</Header>

<Body>

</Body>

</Biztalk_1>

La struttura ricorda quella di un documento HTML (non a caso anche

HTML è un markup language), con Header in cui specificare le

informazioni “di servizio” e con un tag Body che contiene gli effettivi

contenuti da spedire.

3.5 Requisiti del sistema

Come anticipato in precedenza BizTalk Server 2004 necessita delle ultime

versioni dei software Microsoft per sfruttare a pieno le sue potenzialità.

Comprensibilmente le installazioni di server e client hanno requisiti ben

differenti.

3.5.1 Requisiti di sistema per un server

Sistema operativo

o Microsoft Windows® 2000 Server with Service Pack 4

o Windows XP Professional sp1 su NTFS file system

o Microsoft Windows Server™ 2003 Standard, Enterprise, o

Datacenter Edition (certe funzionalità avanzate quali Business

Activity Services e Windows SharePoint™ Services è

necessario Windows Server 2003).

Ambiente di sviluppo software

o Microsoft Visual Studio® .NET 2003 con Microsoft Visual

C#® .NET

Gestione e analisi delle fonti dati

35

o Microsoft SQL Server™ 2000 Enterprise, Standard, o

Developer Edition sp 3a

o Microsoft SQL Server 2000 Analysis Services sp 3a

Sistema di comunicazione (intranet e internet)

o Windows SharePoint™ Services

3.5.2 Requisiti di sistema per un client

Sistema operativo

o Windows XP Professional sp1, Windows 2000 sp4, o

Windows Server 2003 (il sistema operativo di questi tipi è

necessario se si utilizza un metodo di autenticazione Single

Sign-On (SSO)2

Sistema di raccolta informazioni

o Microsoft Office InfoPath™ 2003

Browser

o Microsoft Internet Explorer 6 sp 1

3.6 Panoramica su BizTalk Server

Vediamo ora alcuni dettagli della versione 2004 del prodotto di Microsoft.

Come per le versioni precedenti (BizTalk Server 2002 e 2000) un aspetto

fondamentale del programma è l’integrazione in ambiente Visual Studio.

Nel caso dell’ultima versione disponibile questa integrazione è pressoché

totale in Visual Studio .NET.

Di seguito vedremo alcune immagini tratte dal sito Microsoft [MIC04a].

2 Single Sign-On (SSO) è un meccanismo in cui un’unica azione di autenticazione o di

autorizzazione può consentire ad un utente di accedere a tutti i computer e ai sistemi in

cui ha il permesso di accedere, senza che debba inserire più volte la password. Questo

meccanismo riduce la possibilità di errore umano (una delle principali cause di failure nei

sistemi) ma proprio per la “sensibilità” dell’ambito in cui viene applicato, è difficile da

implementare.

36

3.6.1 Regole e politica della ditta

Poiché le regole aziendali cambiano più spesso dei processi, ne vengono

aggiunte sempre di nuove per fornire una certa flessibilità. Queste risultano

dall’astrazione tra i codici dei processi e quelli degli utenti. E’ consigliato

utilizzarle per gestire sia piccole realtà sia, in modo più completo, situazioni

più complesse.

Figura 8 - Microsoft Business Rule Composer

3.6.2 Ambiente di sviluppo unificato

Il programma permette una mappatura tra i differenti schemi dei documenti

XML. Questo grazie al mapper presente in Visual Studio .NET.

37

Figura 9 – Mappatura tra schema

E’ possibile avere una visione grafica d’insieme grazie all’Orchestration

Designer.

Figura 10 – BizTalk Orchestration Designer

38

Anche la creazione di nuovi schemi XML o l’adattamento di quelli pre-

esistenti, risulta facilitato grazie agli editori avanzati.

Figura 11 – XML Schema Editor

3.6.3 Progettazione di processi aziendali complessi

Già inserita nel programma viene fornita le predisposizione per un insieme

di linguaggi per l’esecuzione di processi aziendali (Business Process

Execution Language for Web Services - BPEL4WS), tra cui:

processi innestati

transazioni a lungo termine

correlazioni semplificate

mappatura flessibile tra messaggi

3.6.4 Sistema di tracciamento realtime per amministrazione e debug

E’ possibile tenere sotto controllo il processo aziendale dall’inizio alla fine

del suo iter, sospenderlo, ripristinarlo, analizzarlo in ogni suo singolo

istante.

39

Figura 12 – Orchestration Debugger

3.6.5 Gestione dei partner commerciali di larga scala

E’ prevista una gestione delle relazioni tra migliaia di partner commerciali.

Le relazioni sono separate dai processi per permettere un loro riutilizzo in

modo rapido e funzionale.

Così facendo si possono configurare i profili di nuovi partner, comunicare

con loro tramite protocolli di comunicazione e messaggistica eterogenea,

gestire infine una grande varietà di formati dei dati.

40

Figura 13 – BizTalk Explorer

3.6.6 Integrazione in Microsoft Office e Microsoft InfoPath

Tramite l’integrazione con Office, è possibile guidare i documenti di

InfoPath attraverso un’azienda, e permettere l’inserimento dei dati dagli

stessi documenti al sistema centrale, mantenendo i moduli esistenti o

creandone di nuovi.

41

Figura 14 – Form di InfoPath

3.6.7 Semplificazione dell’interazione tra sviluppatori ed analisti

E’ possibile mantenere come strumento di analisi Microsoft Visio e

riprodurre lo stesso processo nell’ambiente di sviluppo di BizTalk

(Orchestration Designer). Verrà mantenuta la sincronizzazione tra i due e i

dati rimarranno consistenti.

Il confronto tra il processo sviluppato grazie a Microsoft Visio, e il suo

rappresentato in Orchestration Designer, si spiega da solo.

Il fatto di non dover cambiare il sistema di analisi, è indubbiamente un

grosso vantaggio sia dal punto di vista economico, che dal punto di vista del

tempo impiegato nell’istruzione del personale addetto e nell’analisi.

42

Figura 15 – Microsoft Visio

3.6.8 Monitoraggio dell’attività commerciale

Con il Business Activity Monitoring, gli analisti possono definire l’insieme

dei dati sensibili da raccogliere ed interpretare. Gli utenti possono vedere le

attività e -ogni giorno- eseguirne le relative operazioni commerciali. I

processi vengono monitorati e i dati vengono salvati in formati leggibili

anche ai non analisti, grazie alle facilitazioni fornite dall’applicativo

Microsoft SharePoint.

43

Figura 16 – Tracking Profile Editor

3.7 Acceleratori per BizTalk Server

Gli acceleratori sono utilizzati per un largo spettro di scenari commerciali e

industriali, dall’hi-tech alla sanità. Essi forniscono nuove funzionalità e

fungono da complemento tra gli applicativi del sistema Windows Server

System™, riducendo considerevolmente il tempo, le risorse e i costi

associati alla progettazione del sistema, allo sviluppo e alla gestione dello

stesso.

Gli acceleratori sono in pratica un insieme di pacchetti aggiuntivi per i

software già installati in azienda, semplici strumenti, documentazione ed

esempi sviluppati per far sì che il lavoro del sistema venga ottimizzato.

Vediamo quali sono, al momento, gli acceleratori disponibili insieme al

pacchetto BizTalk Server; sono elencati anche i servizi specifici che offrono

a seconda del tipo:

Cactus GDS

o Minori costi di amministrazione

44

o Logistica migliorata

o Facile integrazione

HIPAA

o Risorse affidabili

o Tecnologia avanzata per il settore sanitario

o Gestione fiscale

HL7

o Sistema di messaggistica intelligente

o Tecnologia avanzata per il settore sanitario

o Migliore rapporto del tempo per la qualità

SWIFT

o Messaggistica finanziaria pronta per il futuro

o Possibilità di automazioni fino ad ora mai sviluppate

o Integrazione InfoPath 2003

RosettaNet

o Rapida implementazione

o Maggiore flessibilità

o Riduzione dei costi

3.8 Adattatori

Gli adattatori per BizTalk Server espandono la capacità del prodotto per

rendere effettivamente semplici le installazioni, lo sviluppo e la

configurazione delle soluzioni per la connettività. Il loro obiettivo è di

eliminare la necessità di produrre componenti per le infrastrutture come

supporti per i protocolli di rete, per la traduzione, conversione e la

trasformazione dei dati.

Forniscono quindi una chiave per migliorare l’interoperabilità tra BizTalk e

una vasta gamma di programmi legati al B2B.

45

Di seguito riporto un elenco di applicativi per cui sono stati creati degli

adattatori.

Applicativo Adattatore fornito da

Ascentn Ascentn

BOC Information Systems

GmbH

BOC Information Systems

GmbH

Capco Capco

Captaris Captaris

Cincom Cincom

eCraft Management Solutions eCraft Management Solutions

Fenestrae Fenestrae

Intercim Intercim

J.D. Edwards iWay

Metastorm Metastorm

Oracle Financials iWay

Peoplesoft iWay

SAP iWay

Scala Business Solutions Scala Business Solutions

Siebel iWay

Siebel Systems Siebel Systems

SolutionForge Ltd. SolutionForge Ltd.

SourceCode SourceCode

Sysrepublic Sysrepublic

Temenos Temenos

Ultimus Ultimus

VisionAIR VisionAIR

Visionware Visionware

46

Oltre agli adattatori per applicativi veri e propri, sono stati sviluppati anche

adattatori per tecnologie, assai più diffuse e note dei singoli programmi.

Tecnologia Adattatore fornito da

2392A terminals WRQ

3270 terminal emulation WRQ

5250 terminal emulation WRQ

70092 terminals WRQ

ACORD Itemfield

ACORD AL3 Itemfield

ACORD XML Itemfield

Adabas Attunity

AFP Itemfield

AS/400 File System WRQ

ASCII ANSI Itemfield

ASCII Unicode Itemfield

ASTM Itemfield

Basic Attunity

Btrieve Attunity

C Attunity

Cargo IMP Itemfield

Choicepoint CLUE Itemfield

CICS Attunity, WRQ

CISAM Attunity

COBOL Attunity, Itemfield

CORBA iWay

cXML Itemfield

DB2 WRQ

DB2 for AS/400 and OS/390 WRQ

DB2, UDB Attunity

47


DBMS Attunity

Delimited Text Files Attunity

DISAM Attunity

EBCDIC Itemfield

ebXML Itemfield

EDI x.12 Itemfield

EDI-Fact Itemfield

Enscribe Attunity

FIX Itemfield

Flat Files Itemfield, Attunity

Fortran Attunity

HL7 Itemfield

HTML Itemfield

IFX Itemfield

IMS WRQ

IMS/DB Attunity

IMS/TM Attunity

Informix Attunity, WRQ

Ingres, Ingres II Attunity

JetForms Itemfield

LegalXML Itemfield

Microsoft Excel Itemfield

Microsoft PowerPoint Itemfield

Microsoft Word Itemfield

MQ Series iWay

MVR Itemfield

Naural Attunity

NonStop SQL/MP Attunity

ODBC-compliant databases WRQ

48


Oracle DB WRQ

Oracle DB, Rdb Attunity

Pathway Attunity

PCL Itemfield

PDF Itemfield

PostScript Itemfield

PowerPoint Itemfield

RDMS iWay

RMS Attunity

RPG Attunity, Itemfield

SAP R/3 WRQ

Siebel WRQ

SQL Server Attunity,WRQ

StarOffice Itemfield

SWIFT Itemfield

Sybase Attunity, WRQ

Tuxedo Attunity

Undocumented Binaries Itemfield

VSAM Attunity, WRQ

VT102 terminals WRQ

VT400-7 terminals WRQ

VT400-8 terminals WRQ

VT52 terminals WRQ

WordPerfect Itemfield

XML Attunity ,Itemfield, iWay

Come si può notare, il numero di tecnologie supportate dagli adattatori è

elevato. Per le tecnologie più diffuse, più di un produttore di software ha

49

creato un adattatore; un esempio su tutti (e anche il più logico, viste le

premesse del B2B) è XML.

50

4 EBXML

4.1 Definizione di ebXML

ebXML (Electronic Business Extensible Markup Language) è un progetto

internazionale ideato da UN/CEFACT (United Nation Center for Trade

Facilitation and Electronic Business) e da OASIS (Organization for the

Advancement of Structured Information Standard).

L’obiettivo del progetto è quello di fornire un framework che permetta al

linguaggio XML di essere utilizzato in modo uniforme e consistente nello

scambio di messaggi tra applicativi e utenti in un contesto di commercio

elettronico.

Il vantaggio fornito da ebXML è apprezzabile anche per aziende di piccola

e media grandezza e che abbiano un livello di informatizzazione anche

minimo; la possibilità che viene fornita da ebXML è uno scambio di

messaggi basati su XML che favorisca il commercio elettronico della ditta

con altre strutture (della stessa società o di ditte diverse) geograficamente

localizzate in luoghi diversi.

Questo vantaggio è garantito da un vocabolario di termini comuni che

permette una comunicazione commerciale con messaggistica di tipo

standard.

4.2 Perché ebXML?

Qualcuno potrebbe chiedersi il perché della necessità di un altro linguaggio

basato su XML [Dau04]. Sembra infatti che ogni giorno venga sviluppato o

modificato uno standard XML, e che uno dopo l’altro vengano propinati

indistintamente al settore industriale e al pubblico. Questa corsa senza sosta

causa una notevole confusione, in cui gli utilizzatori delle tecnologie

correlate devono valutare il costo (economico e in termini di risorse) di un

passaggio dagli standard usati fino a quel momento alle nuove versioni in

XML; e il tutto, cercando di mantenere sicurezza e affidabilità.

L’alto numero di linguaggi XML particolareggiati, è parzialmente dovuto

alla semplicità dell’XML stesso; ma esso, da solo, non è infatti sufficiente

per portare a termine progetti senza demandare compiti specifici ad altre

entità. Si devono sviluppare specifiche su specifiche per dare all’XML la

forma necessaria per essere impiegato in ambiti particolareggiati. La

tendenza degli ultimi anni è quella di sviluppare standard sempre diversi,

cercando di riprodurre in XML ogni possibile formato di dati o di

interazione.

A differenza di questi, ebXML non è un tentativo come tanti di

cambiamento dal formato delle transazioni d’affari non-XML EDI

(Electronic Data Interchange). Ciò che lo differenzia dagli altri linguaggi

basati su XML sono importanti vantaggi dal punto di vista concettuale,

principalmente dovuti alla visione ad hoc di ebXML.

4.3 Un sistema ad hoc

Una delle maggiori capacità di ebXML è quella di fornire dei contatti

d’affari ad hoc. Sebbene questa affermazione possa lasciare intendere

malfunzionamenti non programmati ed eventi inaspettati, è in realtà la

caratteristica che permette a ebXML di effettuare transazioni di commercio

elettronico in modo così efficace.

Vediamo un esempio per chiarificare il concetto.

Supponiamo di comperare ortaggi da un supermarket A. Dopo diverso

tempo abbiamo sviluppato una relazione d’affari con il supermarket, basato

sui prodotti forniti e sul processo intrapreso per comprarli, come

l’interazione con i commessi e il pagamento tramite carta di credito dei

beni. Possiamo definire questa relazione ad hoc.

Supponiamo ora che entri nel marcato un nuovo supermarket B, che venda

lo stesso prodotto a prezzi inferiori. Sarebbe nel nostro interesse

intraprendere degli affari con questo nuovo supermarket, e possiamo farlo

perché ci aspettiamo di non incontrare ostacoli: i commessi si

comporteranno come nel primo supermercato (parlano la nostra stessa

lingua) e possiamo pagare la merce con la carta di credito.

Il commercio elettronico, in realtà, ha costi di infrastrutture che influiscono

sul prezzo totale dell’affare. Durante una transazione elettronica, per

esempio, i partecipanti devono affrontare i costi del software, del trasporto

dati, così come decidere le politiche di interazione e sicurezza.

In pratica, se un nuovo fornitore offrisse beni a minor prezzo, potrebbe

accadere di dover considerare i costi del servizio di acquisto come elemento

discriminante. Ad un minor costo del prodotto potrebbe infatti

corrispondere un maggior costo o complicazione del processo di acquisto.

Tornando all’esempio precedente, se il supermercato B avesse solo

commessi stranieri, che parlassero esclusivamente una lingua diversa dalla

nostra e non venissero accettati pagamenti con carta di credito ma solo con

contanti e di piccolo taglio, è facile comprendere che il risparmio ottenuto

sul bene acquistato andrebbe perso nell’adeguamento alle condizioni di

vendita imposte.

Uno dei valori basilari di ebXML è una visione di ubiquità da una

prospettiva tecnologica. E’ costruito su XML, SOAP, HTTP e SMTP, tutti

standard aperti e senza barriere. In teoria, mettere al centro l’ubiquità della

tecnologia, dovrebbe permettere al commercio elettronico un approccio ad

hoc al concetto di libero mercato che abbiamo visto nell’esempio del

supermercato.

4.4 Panoramica su ebXML

Per ottenere un approccio ad hoc, come visto nel capitolo precedente,

ebXML fornisce un framework completo per le interazioni d’affari, tutto

inviato come un insieme di specifiche indipendenti dal partecipante

all’affare. Il framework cerca di soddisfare i seguenti punti:

53

Descrivere il processo e le interfacce specifiche

Condividere il processo con altri partner

Conoscere quali processi può supportare il partner

Descrivere i messaggi per una particolare transizione

Descrivere la politica di sicurezza e la configurazione tecnica da

usare

Se il partner commerciale può fornirci una sua descrizione in questi termini,

è già un buon passo verso lo scopo che ci siamo prefissati.

Molte di queste informazioni possono essere salvate in un registro

condiviso che ha lo scopo di rendere centralizzati gli accordi dell’affare e i

processi. Questa locazione comune è conosciuta come ebXML registry.

Oltre alla registry esistono delle specifiche per l’attuale livello di scambio

di messaggi come per le informazioni sui processi e per la collaborazione.

Questo insieme può essere suddiviso nel modo seguente:

Registro condiviso e centralizzato: Registry Information Model

(ebRIM), Registry Services Specification (ebRS)

Processi dell’affare e collaborazione: Business Process Specification

Schema (ebBPSS), Collaboration-Protocol Profile and Agreement

Specification (ebCPPA)

Messaggistica: Message Services Specification (ebMS)

4.5 Struttura di ebXML

Vediamo ora in dettaglio gli elementi, sia quelli già menzionati che altri

nuovi, di cui è composto lo schema di ebXML [MER01]:

Registry: un server centrale che contiene una varietà di dati necessari

per il funzionamento di ebXML. Tra le varie informazioni che la

Registry mette a disposizione di XML troviamo: Business Process &

Information Meta Models, Core Library, Collaboration Protocol

Profiles, e Business Library. Fondamentalmente, quando si vuole

iniziare un a relazione ebXML in un affare, è necessaria una Registry

54

per individuare un partner adatto e per ricavare informazioni

riguardo agli elementi necessari per rapportarsi con quel partner.

Business Processes: attività che un’impresa può intraprendere (e per

la quale sta cercando uno o più partner). Un Business Process è

formalmente descritto da uno Schema di Specifiche (Business

Process Specification Schema: uno Schema XML e un DTD dettati

da W3C), ma potrebbe essere modellato anche in UML (Unified

Modeling Language).

Collaboration Protocol Profile (CPP): profilo archiviato con una

Registry da un’impresa che vorrebbe intraprendere delle transizioni

ebXML. Il CPP specifica alcuni Business Process dell’impresa e

anche alcune Business Service Interface supportate.

Business Service Interface: i modi in cui un’impresa è capace di

portare avanti le transazioni necessarie nei suoi Business Process. La

Business Service Interface include inoltre i tipi di Business Message

supportati e i protocolli sui quali questi messaggi dovranno

viaggiare.

Business Message: le informazioni correnti comunicate come parte

della transazioni d’affari. Un messaggio contenente diversi strati. Al

livello più esterno deve essere utilizzato in protocollo di

comunicazione (tipo HTTP o SMTP). SOAP viene raccomandato

come envelope (busta, strato esterno) per un messaggio “payload”.

Gli altri strati possono concernere criptazione o autenticazione.

Core Library: un insieme di “parti” standard che possono essere

utilizzate in elementi ebXML più grandi. Per esempio i Core Process

possono essere referenziati dai Business Process. Alla Core Library

contribuisce l’iniziativa ebXML stessa, mentre agli elementi più

grandi possono contribuire specifiche imprese o industrie.

Collaboration Protocol Agreement (CPA): in pratica, un contratto tra

due o più imprese che può essere derivato automaticamente dai CPP

55

delle rispettive compagnie. Per esempio se un CPP afferma “Io

posso fare X”, un CPA afferma “Noi faremo X insieme”.

Simple Object Access Protocol (SOAP): un protocollo di W3C per

lo scambio di informazioni in un ambiente distribuito sottoscritto

dall’iniziativa ebXML. La parte di SOAP interessante per ebXML è

la funzione di envelope che definisce un framework per la

descrizione di cosa contiene il messaggio e come processarlo.

4.6 Il cuore di ebXML: la Registry

Come già visto la Registry è la parte vitale di una implementazione di

ebXML. Essa è abbastanza versatile e capace di rappresentare una vasta

gamma di dati, inclusi gli schema XML, descrizione dei processi,

componenti del kernel di ebXML, modelli UBL, informazioni generiche sul

partner commerciale e componenti software. Per poter supportare una così

grande varietà di informazioni, la Registry è ideata più o meno come un

database, ovvero con un modello di informazioni ben-formato piuttosto che

come un semplice direttorio. Questo è un punto chiave poiché alcune teorie

sostengono che la registry di ebXML sia in contrasto (o competizione) con

la registry dei servizi per i webservice XML come UDDI (Universal

Description, Discovery and Integration).

Nel concreto sono diversi gli obiettivi: mentre sarebbe possibile essere

organizzata in una directory UDDI per una registry, non è vero il contrario

poiché UDDI non è predisposto per gestire una serie dati e classificazioni

così complesse come invece fa una registry.

4.6.1 Modello informativo di una registry ebXML

Il modello centrale delle informazioni in cui è organizzata la registry è uno

schema di classificazione basato su un modello ad albero, in cui le

informazioni sulle aziende e/o partner sono gestite in modo gerarchico. Un

pregio di una registry ebXML rispetto ad una semplice gerarchia ad albero

56

è la capacità di contenere relazioni più complesse. Vediamo per esempio la

seguente gerarchia basata su una struttura ad albero [Bre04]:

Figura 17 - Modello delle informazioni in una Registry ebXML

Nella figura si possono notare alcuni elementi in grigio, questi si riferiscono

agli effettivi oggetti della registry, mentre gli elementi in bianco vengono

chiamate classificazioni.

Notare inoltre che le foglie del grafo possono fare parte di relazioni di

classificazione addizionali.

4.6.2 Interfacce della Registry ebXML

L’architettura della Registry è definita in termini di servizio di registry e di

client di registry. Il primo ha due interfacce per gestire gli oggetti del

modello informativo: gestione del ciclo di vita (lifecycle) e gestione delle

richieste (query). A sua volta l’interfaccia di gestione del ciclo di vita è

suddivisa in metodi come submitObjects, updateObjects, removeObjects, e

deprecatedObjects, che vendono utilizzati per aggiungere, modificare,

aggiornare o rimuovere gli oggetti o le classificazioni al modello

informativo. Analogamente anche l’interfaccia di gestione delle richieste ha

57

metodi come submitAdhocQuery, getRegistryObject, e getRepositoryItem

che servono per interrogare la registry.

Entrambe le interfacce sono definite usando un file in Web Services

Description Language (WSDL) fornito dal comitato tecnico che si occupa

di ebXML (OASIS ebXML Registry Technical Committee).

Alle due interfacce sono legate, in modo concreto, SOAP utilizzato su

protocollo HTTP, ebMS e il protocollo HTTP stesso; questo fa capire la

versatilità di ebXML, che può operare in scenari sia di piccola che di

grande azienda.

4.7 Fasi di funzionamento di ebXML

Accordarsi per una nuova relazione d’affari significa accedere alla registry

di ebXML che, solitamente, viene gestita dalla fase di funzionamento

corrente. L’architettura di base prevede tre fasi:

1. fase di implementazione

2. fase di scoperta-recupero (discovery - retrieval)

3. fase di esecuzione (runtime)

Per ogni fase sono definiti dei processi e dei meccanismi di sicurezza

propri. In generale si possono immaginare le prime due fasi come

un’ipotetica stretta di mano tra i due contraenti l’affare, mentre la terza

come la reale attuazione dello scambio.

4.7.1 Fase implementativa

Inizia con la decisione dei partner di svolgere una transizione d’affari

tramite il framework ebXML. Il partner analizza i suoi processi e li

pubblica nella registry preoccupandosi di renderli compatibili con la

generalizzazione fornita da ebXML. In questa fase deve essere prodotta

un’implementazione, o dalle specifiche del nucleo dei ebXML stesso o da

terzi produttori. Come risultato si ottiene un framework funzionante

58

contenente un insieme di processi e interfacce. Il Profilo del Protocollo di

Comunicazione (CPP) viene istanziato in questo momento.

Figura 18 – Fase implementativa

4.7.2 Fase di scoperta – recupero

In questa fase i partner consultano la registry per vedere (scoprire) i

processi e le interfacce pubblicate dall’altro partner. Tipicamente i CPP di

un partner specifico vengono scambiati in questa fase. Il CPP descrive i

dettagli dei processi, compresi quelli riguardanti la sicurezza, il trasporto e

l’affidabilità.

Figura 19 – Fase di “scoperta e recupero”

59

4.7.3 Fase di esecuzione

Gli accessi alla registry sono terminati nelle fasi precedenti, per cui in

questa avvengono esclusivamente gli scambi di messaggi tra i contraenti.

Le istanze di CPP pubblicate da ciascuno vengono ristrette per formare un

Accordo sul Protocollo di Collaborazione (CPA). Questo è un particolare

accordo legato alle richieste formulate dai singoli CPP. Prima di iniziare lo

scambio dei messaggi con ebMS, solitamente i due contraenti si

preoccupano di verificare la consistenza del CPA creato: quando si verifica

da entrambi i lati la consistenza, comincia lo scambio di messaggi.

Figura 20 – Fase di esecuzione

Facendo riferimento alla figura 20 possiamo riassumere la fase di runtime

in 3 passi:

Ogni partner è responsabile di ottenere i documenti CPP necessari

per accordarsi con gli altri partner. Solitamente queste informazioni

vengono ottenute tramite l’accesso ad una Registry.

Con i CPP ottenuti vengono creati i CPA, che esplicitano la gamma

di scelte offerte nei CPP.

Sotto il controllo del CPA, i partner cominciano le transazioni

tramite ebMS.

60

4.8 Formato dei messaggi ebXML

Il servizio incaricato della spedizione dei messaggi (ebMS) definisce una

serie di elementi che verranno inseriti all’interno dell’intestazione (Header)

o del corpo (Body) che soddisfano le specifiche SOAP per rendere il

messaggio compatibile con le specifiche definite da ebXML Requirements

Specifications (ebRS). Per ottenere ciò si dovranno incapsulare questi

elementi in un multipart MIME che permetterà di inserire degli allegati

nello stesso messaggio SOAP. Schematizzando il messaggio che verrà

spedito si possono individuare due parti:

Header Container, che contiene il vero e proprio messaggio SOAP

Payload Container, allegati contenenti informazioni di diverso

genere

Graficamente si può schematizzare il tutto come nella figura seguente. La

parte gialla (SOAP Envelope con allegati MIME) corrisponde al Message

Pack, la parte verde sopra (MIME part) è l’Header Container mentre la

parte verde sotto (MIME part(s))è il Payload Container.

61

Figura 21 – Formato di un messaggio ebXML

4.8.1 Header MIME delle parti del messaggio

Un messaggio ebXML ha tre intestazioni (header), una per ogni parte

MIME (SOAP envelope e Paylod container) e una per l’intero messaggio.

Vediamo ora la struttura tipica di un messaggio ebXML nella quale si può

vedere l’utilizzo delle intestazioni MIME:

1 MIME-VErsion: 1.0

2 Content-Type:Multipart/related;

62

3 boundary=boundaryValue; type=text/xml;

4 start=<[email protected]>;

5 Content-Description:

6 Optional message description

7 --boundaryValue

8 Content-ID:[email protected]

9 Content-Type: text/xml; charset=”UTF-8”

10 <SOAP-ENV:Envelope xmlns:SOAP-

ENV=”http://schemas.xmlsoap.org/soap/envelope/”>

11 <SOAP-ENV:Header>

...

12 </SOAP-ENV:Header>

13 <SOAP-ENV:Body>

...

14 </SOAP-ENV:Body>

15 --boundaryValue

16 content-ID: <domain.example.com>

17 content-Type: application/xml

18 <invoice>

19 <invoiceData>

...

20 </invoiceData>

21 </invoice>

...Altri Payload container

22 --boundaryValue—

Riga 1 – 6: Header MIME per SOAP con allegati

Riga 7 – 14: Messaggio SOAP

Riga 15 – 22: Payload Container

4.8.2 Reliable Messaging

Con “Reliable Messaging” si intende l’affidabilità del messaggio, non tanto

per il fatto che questo giunga o meno al destinatario, quanto per il fatto che

giunga una sola volta. I protocolli di trasmissione esistenti infatti sono

studiati apposta per rimediare all’eventuale perdita di un messaggio con la

63

http://schemas.xmlsoap.org/soap/envelope/%3E

mailto:[email protected]%3E

ri-spedizione di esso. A sua volta il destinatario deve avere un meccanismo

per poter scartare i messaggi duplicati ricevuti. Solitamente la notifica del

messaggio ricevuto avviene tramite un acknowledgment (conferma) per

ogni messaggio. Inoltre il destinatario deve poter salvare i messaggi

correttamente giunti in modo da recuperare un’eventuale situazione di

interruzione della trasmissione. Di queste problematiche se ne deve

occupare il Message Service Handler.

64

5 UBL

5.1 Definizione di UBL

L’acronimo UBL (Universal Business Language) è un’estensione di libreria

di schemi XML:

L'OASIS UBL è un "Technical Committee (TC)" (comitato

tecnico) di OASIS. Lo scopo dell'UBL TC è quello di

sviluppare una libreria standard di documenti XML per il

business (ordini d'acquisto, fatture, etc.) modificando una

libreria di schemi XML preesistente (xCBL) per incorporare

le migliori caratteristiche delle altre librerie XML orientate al

business. Il TC svilupperà poi un meccanismo per la

generazione di schemi di business relativi alle singole aree

applicative attraverso l'applicazione di regole di

trasformazione sulla base della libreria di base comune UBL.

E' previsto che UBL divenga lo standard internazionale per il

commercio elettronico disponibile a tutti senza spese di

acquisto licenza o altri costi.

Oltre alla definizione suddetta [EBX04] possiamo spiegare UBL come il

prodotto di uno sforzo internazionale per definire una libreria gratuita (non

coperta da diritti o registrazioni) di documenti XML standard per il

commercio elettronico come ordini d’acquisto e fatture.

Sviluppato da un comitato aperto della OASIS, con la partecipazione di una

varietà di organizzazioni per gli standard aziendali, UBL è progettato per

inserirsi direttamente nei già esistenti ambienti commerciali, legislativi,

contabili e gestionali, eliminando la re-codifica dei dati in queste realtà

tuttora basate su fax, fatture, documenti cartacei e fornendo un accesso al

commercio elettronico per le piccole e medie aziende.

5.2 Breve storia di UBL

L’iniziativa UBL cominciò a metà del 1999 con il progetto di creare di un

set di documenti XML standard per l’ufficio con OASIS. Il Comitato

Tecnico responsabile dello sviluppo fu guidato da Sun Microsystems, forse

anche per cercare un’alternativa all’organizzazione tutt’altro che no-profit

BizTalk, guidata da Microsoft, che cominciava a concretizzare i primi passi

proprio verso la fine del 1998.

Verso la fine del 1999 però, poiché OASIS e UN/CEFACT iniziarono una

collaborazione su ebXML, il progetto UBL venne messo da parte.

L’interesse per la creazione di una sintassi XML standard per documenti

commerciali rinacque nel maggio successivo (2000), quando il comitato di

ebXML decise di omettere la sintassi XML standard per il payload3 nella

prima versione del linguaggio.

Il gruppo di lavoro che venne studiava UBL cominciò quindi nell’aprile

2001 come gruppo di discussione di CommerceNet e nel successivo

novembre venne confermato come Comitato Tecnico OASIS.

Dopo diversi anni di lavoro in cui si è studiato quali elementi fossero

necessari allo scopo di UBL, si è giunti, nel novembre 2003 al rilascio della

prima beta, mentre nel settembre 2004 alla pubblicazione delle specifiche di

UBL 1.0 [MeS04]. Per il futuro sono previsti degli ampliamenti delle

tipologie di librerie per soddisfare altre categorie di mercato quali –per

esempio– gli enti governativi.

5.3 Perché UBL?

Dopo essere stato approvato da W3C, XML è stato adottato da una vasta

serie di aziende come framework per la definizione dello scambio di

messaggi per l’e-commerce. Il suo largo utilizzo ha portato allo sviluppo di

3 Payload viene definito come i dati essenziali trasportati da un pacchetto o da una unità di

trasporto. Il payload non include l’overhead, ovvero i dati tecnici necessari per far giungere il

pacchetto a destinazione.

versioni specifiche appositamente create per i diversi settori di impiego dei

documenti fondamentali come gli ordini, le bolle e le fatture.

Ma se da un lato avere documenti altamente specifici al contesto

commerciale era sinonimo di ottimizzazione del lavoro, dall’altro il fatto di

avere documenti in diversi formati per svolgere la stessa tipologia di

funzioni era sicuramente svantaggioso.

Riassumendo, i punti che giocavano a svantaggio della specificità dei

documenti di base erano:

Lo sviluppo e il mantenimento di più versioni dei comuni documenti

commerciali significava multiplo lavoro.

La creazione e il mantenimento di adattatori che rendessero possibile

le relazioni tra industrie con standard differenti implicava un grande

impiego di risorse.

L’esistenza di più formati XML rendeva difficoltosa l’integrazione

con i sistemi di backoffice.

Il bisogno di supportare un numero arbitrario di formati XML era

costoso e non era facile trovare personale con esperienza nel settore

specifico.

UBL è stato pensato proprio con l’intento di risolvere questi problemi

definendo un formato XML interscambiabile e generico che si potesse

estendere per soddisfare le esigenze dei vari settori industriali. Ciò che

fornisce la versione 1.0 di UBL nello specifico è:

Una libreria di schema XML per dei componenti riutilizzabili come

“Address” (indirizzo), “Item” (elemento) e “Payment” (pagamento),

che sono gli elementi più comuni tra i documenti commerciali.

Un insieme più piccolo di schemi XML come “Order” (Ordine),

“Dispatch advice” (Avviso di spedizione) e “Invoice” (fattura) che

sono costituiti dai componenti di libreria di UBL e che possono

essere utilizzati in un generico contesto che va dall’ordine alla

fattura.

67

Il supporto per la personalizzazione di UBL nelle differenti realtà

commerciali.

Una base standard per gli schemi commerciali XML doveva, inoltre, fornire

dei vantaggi come:

Basso costo di integrazione, sia tra le aziende e al loro interno, grazie

al riutilizzo delle strutture dati comuni.

Basso costo del software commerciale: un applicativo che deve

gestire un numero limitato di tag è sicuramente meno costoso di un

altro che deve supportarne un insieme arbitrario.

Minori costi di istruzione del personale, poiché gli utenti devono

apprendere la gestione di una sola libreria: si ottengono così più

utenti meglio istruiti e in minor tempo.

Bassi costi di entrata e quindi appetibilità anche per le piccole e

medie imprese.

Disponibilità per chiunque di un insieme di integratori di sistema.

Strumenti di immissione dati e output standardizzati e quindi meno

costosi.

Da quanto elencato, si capisce che UBL ha come scopo primario quello di

fornire una sintassi comprensibile a tutti i sistemi. Inoltre si prefigge di

operare in aggiunta a dei framework standard per il commercio come –ad

esempio– ebXML, e di divenire quindi un’infrastruttura gratuita e non

coperta da costi di licenza, che estenda i vantaggi dei sistemi EDI esistenti a

tutti i tipi di azienda, dalla grande industria alla piccola ditta. Colmare

quindi la lacuna che hanno lasciato ebXML e i framework simili per quel

che riguarda il payload XML nei messaggi.

5.4 Struttura di UBL

Gli schema di UBL sono modulari, riutilizzabili ed estendibili come ogni

altro schema XML. La libreria di UBL è progettata come

68

un’implementazione del Core Components Technical Specification di

ebXML e si basa su un modello concettuale di componenti

dell’informazione, meglio noti come BIE (Business Information Entities).

Questi componenti sono raggruppati in modelli di documento specifici

come gli ordini e le fatture. Successivamente questi documenti vengono

trasformati in una sintassi di XSD4 schema seguendo l’UBL Naming and

Design Rule (regole di denominazione e di progettazione).

Figura 22 – UBL rispetto allo schema ebXML

5.4.1 Esempio di Schema XSD

Riporto di seguito un esempio di schema XSD utilizzato da UBL.

Nello specifico è lo schema relativo al codice di risposta

(Acknowledgement Response Code); ne esistono altri relativi ad altre

tipologie di definizioni necessarie nello scambio di messaggi in ambito

commerciale come la valuta (Currency Code), allo stato del documento

(Document Status Code), al codice operatore (Operator Code), al codice

identificativo del paese (Country Identification Code) e così via.

4 schema XSD: definizione di documento XML conforme al linguaggio XML XSD1 e XSD2

69

<xsd:schema

targetNamespace="urn:oasis:names:specification:ubl:schema:xsd:Acknowledge

mentResponseCode-1.0" elementFormDefault="qualified"

attributeFormDefault="unqualified" version="1.0">

<xsd:import

namespace="urn:oasis:names:specification:ubl:schema:xsd:CoreComponentPara

meters-1.0" schemaLocation="../common/UBL-CoreComponentParameters-

1.0.xsd"/>

<xsd:simpleType name="AcknowledgementResponseCodeContentType">

<xsd:restriction base="xsd:normalizedString">

<xsd:enumeration value="OrderResponse">

<xsd:annotation>

<xsd:documentation>

<CodeName>UBL OrderResponse document</CodeName>

</xsd:documentation>

</xsd:annotation>

</xsd:enumeration>

<xsd:enumeration value="OrderResponseSimple">

<xsd:annotation>

<xsd:documentation>

<CodeName>UBL OrderResponseSimple document</CodeName>


</xsd:annotation>

</xsd:enumeration>

</xsd:restriction>

</xsd:simpleType>

<xsd:complexType name="AcknowledgementResponseCodeType">

<xsd:annotation>

<xsd:documentation>

<ccts:Component>

<ccts:ComponentType>DT</ccts:ComponentType>

<ccts:DictionaryEntryName>Acknowledgement Response_ Code.

Type</ccts:DictionaryEntryName>

<ccts:RepresentationTerm>Code</ccts:RepresentationTerm>

<ccts:DataTypeQualifier>Acknowledgement

Response</ccts:DataTypeQualifier>

<ccts:DataType>Code. Type</ccts:DataType>

</ccts:Component>

<ccts:Instance>

<ccts:CodeListID>Acknowledgement Response</ccts:CodeListID>

<ccts:CodeListAgencyID>UBL</ccts:CodeListAgencyID>

<ccts:CodeListAgencyName>OASIS Universal Business

Language</ccts:CodeListAgencyName>

<ccts:CodeListName>Acknowledgement Response</ccts:CodeListName>

70

<ccts:CodeListVersionID>1.0</ccts:CodeListVersionID>

<ccts:CodeListSchemeURI>urn:oasis:names:specification:

ubl:schema:xsd:AcknowledgementResponseCode-1.0</ccts:CodeListSchemeURI>

<ccts:LanguageID>en</ccts:LanguageID>

</ccts:Instance>


</xsd:annotation>

<xsd:simpleContent>

<xsd:extension base="AcknowledgementResponseCodeContentType">

<xsd:attribute name="codeListID" type="xsd:normalizedString"

fixed="Acknowledgement Response" use="optional"/>

<xsd:attribute name="codeListAgencyID" type="xsd:normalizedString"

fixed="UBL" use="optional"/>

<xsd:attribute name="codeListAgencyName" type="xsd:string" fixed="OASIS

Universal Business Language" use="optional"/>

<xsd:attribute name="codeListName" type="xsd:string"

fixed="Acknowledgement Response" use="optional"/>

<xsd:attribute name="codeListVersionID" type="xsd:normalizedString"

fixed="1.0" use="optional"/>

<xsd:attribute name="name" type="xsd:string" use="optional"/>

<xsd:attribute name="languageID" type="xsd:language" fixed="en"

use="optional"/>

<xsd:attribute name="codeListURI" type="xsd:anyURI" use="optional"/>

<xsd:attribute name="codeListSchemeURI" type="xsd:anyURI"

fixed="urn:oasis:names:specification:ubl:schema:xsd:AcknowledgementRespon

seCode-1.0" use="optional"/>

</xsd:extension>

</xsd:simpleContent>

</xsd:complexType>

</xsd:schema>

Non entreremo nel dettaglio del codice sopraccitato, poiché è solo un

esempio per comprenderne la natura basata su XML e namespace.

71

Figura 23 – Frammento di schema UBL

5.5 Il ciclo ordine-fattura

I documenti e le librerie che soddisfano la versione UBL 1.0 sono stati

progettati per supportare un tipico ciclo di fornitura che parte da un ordine e

termina con una fattura.

Si potrebbero schematizzare i vari passi di tale processo in questo modo,

come riportato da [MeS04]:

Order

Order Response Simple

Order Response Detailed

Order Change

Order Cancellation

Despatch Advice

Receipt Advice

Invoice

72

Graficamente, quelli appena citati, sono elementi collocabili al centro di un

fitto intreccio di casistiche possibili del percorso ordine-fattura.

Figura 24 - Schematizzazione del percorso ordine-fattura

73

6 CONFRONTO TRA GLI STANDARD

Un confronto tra gli standard visti nei capitoli precedenti risulta alquanto

complesso, soprattutto perché alcuni di essi vengono utilizzati all’interno di

altri.

Non sono collocabili, infatti, tutti allo stesso livello dell’ipotetico modello

ISO/OSI5, o meglio, non sono tutti prodotti di identica funzionalità.

La struttura del messaggio di SOAP per esempio viene utilizzata da ebXML

e da UBL per la trasmissione dei messaggi. UBL stesso necessita di un

substrato solitamente ricoperto da ebXML. Dire quindi che SOAP è più

utilizzato di ebXML o che UBL necessita di meno infrastrutture rispetto a

SOAP non è corretto.

Quello che si può fare è ottenere uno sguardo di insieme relativo ai suddetti

standard nel panorama del B2B, cercando di dare loro una collocazione

approssimativa e di capirne potenzialità e svantaggi.

6.1 Il dualismo tra i colossi e gli altri

Come in molti alti campi dell’informatica, quello che si delinea anche

nell’ambito del B2B è un dualismo tra i prodotti Microsoft e le proposte

degli altri produttori. Forte del fatto che metà dei sistemi di computer

esistenti si basano su sistemi operativi Windows, la Microsoft ha potuto

sviluppare un prodotto che sfrutti a pieno le caratteristiche del sistema

operativo e dell’ambiente da esso gestito.

Quando, nel capitolo 3, si è trattato il progetto Biztalk, si è affermato che tra

tutti i vantaggi portati dal sistema ai processi di commercio elettronico,

5 Il modello ISO/OSI (International Standards Organization/Open System Interconnection) è il

punto di partenza per descrivere i livelli, in una rete, per la comunicazione tra computer. I sette

livelli che compongono il modello, dal più basso al più alto, sono: Physical, Data Link, Networks,

Transport, Session, Presentation e Application.

l’integrazione svolge il ruolo fondamentale. Questo grazie proprio al fatto

che Microsoft può affidarsi ad un ambiente interamente proprio.

Il livello SOAP/webservice, per esempio, viene implementato in vari modi:

la maggior parte delle grosse ditte produttrici di software, hanno la propria

implementazione del suddetto protocollo, sviluppato nel linguaggio e

nell’ambiente preferito.

Di strumenti (o toolkit) per la gestione del webservice ne sono stati prodotti

diversi; di seguito ne elenco alcuni dei più noti:

JAVA Apache SOAP

IBM Webservice Toolkit

SUN Microsystems Webservice Development Pack

HP Core Services Framework

Microsoft .NET Framework

Quello che distingue Microsoft dai concorrenti è la grande varietà di

prodotti che offre a livello applicazione, e tutti –come già sottolineato più

volte– integrati tra loro.

Probabilmente da un punto di vista operativo Biztalk non è il miglior

sistema per il commercio B2B, ma riduce al minimo il lavoro di

personalizzazione/cambiamento degli applicativi necessari, visto che molti

di essi sono già stati predisposti a priori per tale scopo e un’eventuale

adattatore avrebbe la certezza assoluta dell’ambiente in cui andrebbe a

operare.

6.2 Confronto fra livelli

Come non è possibile fare sempre coincidere i livelli del modello teorico

ISO/OSI per la comunicazione in una rete con i livelli effettivamente

implementati in un sistema reale, si incontrano difficoltà anche quando si

cerca di fare coincidere i vari livelli occupati dai diversi standard per il

B2B.

Figura 23 – Confronto tra i livelli dei vari modelli trattati

Nella Figura 23 ho cercato di rappresentare una relazione –dove possibile–

tra un sistema Microsoft e un ipotetico altro sistema che utilizzi SOAP,

ebXML e UBL, il tutto paragonato al modello ISO/OSI.

Il risultato è che le relazioni possibili non sono tante, soprattutto per il fatto

che a priori il modello OSI è teorico e spesso nell’implementazione pratica

si vanno ad unificare più livelli sotto un unico componente. I livelli che si

riescono a fare coincidere tra il primo e il secondo modello (senza tenere

conto di quelli inferiori al Transport) sono pertanto solo quelli di trasporto e

di applicazione.

Per quel che riguarda il sistema con BizTalk (discorso valido anche per

ogni altro sistema citato in precedenza che faccia uso di implementazioni

proprie di toolkit per la gestione di SOAP e dei webservice) il problema è

maggiore perché non è possibile rispettare una categorizzazione

Modello ISO/OSI

Application

Presentation

Session

Data Link

Network

Transport

Physical

Application

UBL

ebXML

HTTP/SMTP

SOAP

Sistema standard BizTalk

BT application

.NET

HTTP

SOAP

77

orizzontale: SOAP e il framework di .NET si mescolano infatti in modo

promiscuo.

6.3 Qual è lo standard adatto?

Anche da un punto di vista economico, si presenta una panoramica divisa in

due: da un lato Microsoft e tutti i sistemi proprietari (IBM, SUN, HP) e

dall’altro l’opensource e UBL.

I primi, costosi ma “pronti all’uso”; i secondi nati esclusivamente per essere

gratuitamente distribuiti e personalizzati, ma –appunto– da personalizzare.

Non è un elemento fondamentale la grandezza dell’azienda (la scalabilità

infatti è ormai mantenuta come caratteristica di base), quanto le risorse che

si vogliono investire per adeguare gli eventuali sistemi esistenti. Per

un’azienda che usa da tempo i prodotti Microsoft, compresi i sistemi di

workflow6, sarà immediato passare a BizTalk Server. Per una ditta invece

che per la prima volta si affaccia al mondo del B2B sarà più opportuno

decidere i sistemi da usare in base alle esigenze particolari.

Esiste anche una terza categoria di aziende, che ha utilizzato sistemi

alternativi di B2B ma non globali (non predisposti alla comunicazione con

altri standard simili) e che vuole uniformarsi in previsione di una

espansione di partnership. Questa ditta potrebbe fare affidamento alla vasta

gamma di adattatori offerti da Microsoft BizTalk Server.

6 Workflow (trad. flusso di lavoro) è l’insieme delle politiche aziendali che si traducono in processi

decisionali, di approvazione, di revisione ecc.. ai quali vengono sottoposti i documenti e/o i

prodotti di un settore di lavoro.

78

7 CONCLUSIONI

Il tema trattato in questa tesi mi ha portato a visionare diversi sistemi

considerati standard per il B2B. Partendo dal concetto di commercio

elettronico improntato sulle aziende sia come fornitrici che come fruitici dei

prodotti e dei servizi, ho passato in rassegna alcuni standard: dalle prime

idee di commercio universale, concretizzatesi con UN/EDIFACT fino al

recentissimo UBL, passando attraverso la comprensione dei webservice e di

SOAP (fondamentali mattoni del livello base dell’e-commerce). Un

capitolo è stato dedicato a BizTalk, il prodotto commerciale della Microsoft

per affrontare il B2B, in rappresentanza della categoria di ambienti software

completi.

Al termine del lavoro di ricerca sugli standard del B2B, l’idea che emerge

dalle realtà esistenti, è che i prodotti completi abbiano un impatto più

vantaggioso rispetto a quelli sviluppati a livelli separati.

Sembra che lo sviluppo di sistemi opensource e quello di prodotti

commerciali viaggino a due velocità diverse.

E’ più che ammirevole il tentativo di creare degli standard che possano

essere utilizzati da chiunque senza dover pagare tasse o copyright: il che

favorirebbe la distribuzione del software a tutti i livelli di impiego, ma non

è sufficiente a tale scopo sviluppare e rendere disponibile gratuitamente

solo alcuni singoli strati del diagramma a livelli (mostrato nella Figura 23).

Allo stato attuale non esistono ancora gli strumenti per creare un sistema

totalmente gestito da software freeware, quello che si può fare è integrare le

parti commerciali con parti gratuitamente distribuite.

Un sistema promiscuo però non è sempre realizzabile poiché i sistemi

completi (BizTalk e affini) non forniscono le stesse prestazioni con

l’introduzione o la modifica di substrati nel loro modello a livelli (anche

perché spesso non rispecchia le divisioni canoniche degli altri modelli).

Dagli esempi trattati in questa tesi, solo UBL risulta essere improntato sulla

filosofia della libera distribuzione; esso necessita un sottostrato tipo ebXML

che a sua volta si implementa grazie alla messaggistica di tipo SOAP.

La scelta sembra quasi obbligata, quindi, per chi volesse utilizzare le

librerie UBL; analogamente, alla ditta che ha preferito BizTalk, viene

velatamente consigliato l’utilizzo di prodotti Microsoft (nonostante esistano

i convertitori).

Per una ditta che si appresta a scegliere un sistema per il B2B, la prima

domanda da porsi è se acquistare una soluzione completa oppure se fare

affidamento su diverse implementazioni per i diversi livelli.

Allo stato attuale delle cose, credo che il livello Applicazione faccia la

differenza, e che i pacchetti “completi” da questo punto di vista forniscano

più attrattive.

In un futuro, magari con lo sviluppo di sistemi completi freeware, si potrà

parlare di concorrenza tra le due tipologie, per ora non ce ne sono i

presupposti.

L’unica certezza è che lo sviluppo dell’e-commerce e conseguentemente del

B2B (e B2C) è in forte espansione. Paradossalmente per una ditta è più

importante avere un sito internet efficiente che una prestigiosa sede legale.

La visibilità offerta dal web non ha paragoni, e chi non ha imboccato questa

strada entro qualche anno sarà tagliato fuori. Stiamo andando verso un

nuovo tipo di commercio, non tanto per le metodologie quanto per i canali

adottati. Chi saprà sfruttare i giusti canali vincerà la corsa all’e-commerce.

80

RIFERIMENTI

Fonti in rete

[Bre04] Kathryn Breininger, “Defining and managing

interoperable registries and repositories”, 2004,

http://www.oasis-open.org/committees/tc_home.php?

wg_abbrev=regrep, 20 febbraio 2005.

[Cra03] M. Crawford, “Toward a Universal Business Language”,

2003,

“http://www.oasis-open.org/committees/download.php/46

10/xml2003.pdf”, 5 marzo 2005.

[DAT04] “Webservice in generale”,2004,

http://www.dataflex.it/it/products/webservicegeneral.htm,

18 febbraio 2005.

[Dau04] Blake Dournee, “Introduction to ebXML”, 2004,

http://dev2dev.bea.com/technologies/webservices/articles/

ebXML.jsp, 12 febbraio 2005.

[EBXM04] Centro Europeo di Informazione su ebXML, “OASIS /

UBL - Universal Business Language Technical

Committee”, 2003, http://www.ebxml.eu.org/It/UBL.htm,

24 febbraio 2005.

[Fer01] F. Ferracchiati, “BizTalk: la nuova soluzione per il B2B”,

2001,

http://www.ebxml.eu.org/It/UBL.htm

http://dev2dev.bea.com/technologies/webservices/articles/ebXML.jsp

http://dev2dev.bea.com/technologies/webservices/articles/ebXML.jsp

http://www.dataflex.it/it/products/webservicegeneral.htm

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep

http://online.infomedia.it/riviste/login/28/articolo19/articol

o.htm, 2 febbraio 2005.

[Lon04] F. Longo, “il Dizionario informatico”, 2004,

http://www.dizionarioinformatico.com/cgi-lib/diz.cgi?

frame&key=webservice, 31 dicembre 2004.

[Mer01] David Mertz, “Untangling the business Web of the

future”, 2001,

http://www-106.ibm.com/developerworks/xml/library/x-

ebxml/, 16 gennaio 2005.

[MeS04] B. Meadows - L. Seaburg, “Oasis Universal Business

Language 1.0”, 2004, http://docs.oasis-open.org/ubl/cd-

UBL-1.0/, 5 marzo 2005.

[MIC04a] Microsoft, “Microsoft BizTalk Server: product overview”,

2005,

http://www.microsoft.com/biztalk/evaluation/overview/biz

talkserver.asp, 2 febbraio 2005.

[MIC04b] Microsoft, “Microsoft BizTalk Server” 2004,

http://www.microsoft.com/italy/technet/prodtechnol/biztal

k/default.mspx, 2 febbraio 2005.

[Sig03] O. Signore, “Integrare informazioni e applicazioni nel

KMS con i web service”, 2003,

http://www.w3c.it/papers/km2003rm.pdf, 31 dicembre

2004.

[Sko02] Aaron Skonnard, “XML files – The birth of Web

Services”, 2002,

82

http://www.w3c.it/papers/km2003rm.pdf

http://www.microsoft.com/italy/technet/prodtechnol/biztalk/default.mspx

http://www.microsoft.com/italy/technet/prodtechnol/biztalk/default.mspx

http://www.microsoft.com/biztalk/evaluation/overview/biztalkserver.asp

http://www.microsoft.com/biztalk/evaluation/overview/biztalkserver.asp

http://docs.oasis-open.org/ubl/cd-UBL-1.0/

http://docs.oasis-open.org/ubl/cd-UBL-1.0/

http://www-106.ibm.com/developerworks/xml/library/x-ebxml/

http://www-106.ibm.com/developerworks/xml/library/x-ebxml/

http://www.dizionarioinformatico.com/cgi-lib/diz.cgi?frame&key=webservice

http://www.dizionarioinformatico.com/cgi-lib/diz.cgi?frame&key=webservice

http://online.infomedia.it/riviste/login/28/articolo19/articolo.htm

http://online.infomedia.it/riviste/login/28/articolo19/articolo.htm

http://msdn.microsoft.com/webservices/understanding/we

bservicebasics/default.aspx?pull=/msdnmag/issues/

02/10/xmlfiles/default.aspx, 5 gennaio 2005.

[UNE90] United Nations Economic Commission for Europe,

“UN/EDIFACT draft directory”, 2000,

http://www.unece.org/trade/untdid/texts/d100_d.htm, 26

febbraio 2005.

[W3C00] A.A.V.V., “Simple Object Access Protocol (SOAP) 1.1” ,

2000,

http://www.w3c.org/tr/soap/, 31 dicembre 2004.

[WIN99] WindowsITPro, “Microsoft BizTalk Initiative”, 1999,

http://www.windowsitpro.com/Windows/Article/ArticleID

/5907/5907.html, 3 febbraio 2005.

Altre risorse in rete

XML http://www.xml.org/

SOAP http://www.w3.org/TR/soap/

OASIS http://www.oasis-open.org/home/index.php

ebXML http://www.ebxml.org/

Biztalk http://www.microsoft.com/biztalk/

UN/EDIFACT http://www.unece.org/trade/untdid/welcome.htm

UBL http://www.unece.org/trade/untdid/welcome.htm

83

http://www.unece.org/trade/untdid/welcome.htm

http://www.unece.org/trade/untdid/welcome.htm

http://www.microsoft.com/biztalk/

http://www.ebxml.org/

http://www.oasis-open.org/home/index.php

http://www.w3.org/TR/soap/

http://www.xml.org/

http://www.windowsitpro.com/Windows/Article/ArticleID/5907/5907.html

http://www.windowsitpro.com/Windows/Article/ArticleID/5907/5907.html

http://www.w3c.org/tr/soap/

http://www.unece.org/trade/untdid/texts/d100_d.htm

http://msdn.microsoft.com/webservices/understanding/webservicebasics/default.aspx?pull=/msdnmag/issues/02/10/xmlfiles/default.aspx



Fonti Bibliografiche

[Cau01] P. Cauldwell - R.Chawla - V. Chopra et altri,

“Professional XML Web Services” , 2001, Wrox.

[Ste90] W. Stevens, “Unix Network Programming”, 1990,

Prentice Hall Software Series.

84

1 EDIFACT - WebHome < Tesi < Fabio's...

Documents

Transcript of 1 EDIFACT - WebHome < Tesi < Fabio's...