Jaa

Come integrare vecchi e nuovi applicativi C/C++ con i Web Services

  • Artikkeli

Con l’uscita della prima beta di Windows 7 (e Windows Server 2008 R2) sono disponibili delle nuove API – Windows Web Services API (WWSAPI) - che permettono ai programmatori C/C++ di integrare le loro applicazioni “unmanaged” (= non .NET) con il variopinto mondo dei Web Services . Le WWSAPI permettono di creare sia la parte client che la parte server (Web Services) in puro stile C. Le applicazioni C/C++ oggi sono ancora fortemente presenti nei reparti IT e (spesso) non ci sono particolari ragioni per doverle riscrivere in codice .NET o Java!! Quindi le applicazioni C/C++ sono ancora una realtà e come tale è giusto che possano facilmente, ovvero a basso costo e senza overhead, integrarsi con tutti quei Web Services che tanto vanno di moda da qualche anno a questa parte.

Come spesso racconto durante i seminari o durante gli incontri con i clienti l’adozione dei Web Services all’interno di un reparto IT (grande o piccolo che sia) può essere suddiviso in due momenti : Enterprise Efficency ed Enterprise Agility. Nel primo caso stiamo parlando di tutte quelle aziende (ad oggi la maggior parte in Italia) che iniziano a sperimentare l’efficacia dei Web Services e li utilizzano essenzialmente come mezzo per facilitare l’interoperabilità tra software che nativamente non si parlano (spesso per ragioni tecnologiche). Facilitare l’interoperabilità signifca essere più efficienti, da cui Enterprise Efficiency.
Man mano che l’adozione dei Web Services da puro strumento di interoperabilità si trasforma in una architettura adottando quei modelli architetturali che vanno sotto il nome di SOA, EDA, SaaS,... allora entriamo nella così detta Enterprise Agility. Ovvero adottando questi modelli rusciamo ad essere più reattivi alle richieste da parte del business perchè il nostro modello permette o dovrebbe permettere i principi dell’application composition. Bene! Tutto questo panegirico per dire che, una volta tanto, sono qui per parlare della parte di Efficiency e non (solo) della Agility. Infatti tramite le WWSAPI sarà possibile mettere in comunicazione i nostri applicativi unmanaged con servizi scritti con .NET, J2EE e tutti quei linguaggi capaci di gestire SOAP 1.1 o 1.2 e HTTP. In realtà le WWSAPI fanno molto di più : permettono l’integrazione degli applicativi anche in scenari complessi basati su stack WS-* !!!

Ah, quasi dimenticavo, da una indagine svolta dalla società  PayScale pare che i programmatori C/C++ abbiano in media uno stipendio più alto dal 2 al 20 % rispetto ai colleghi .NET e Java !!! Programmatore avvisato … :-)

Perchè un’altra libreria?

Perchè le applicazioni unmanaged, essendo una forte realtà sul mercato hanno bisogno di uno stack snello e performante capace di integrare le applicazioni C/C++ con le funzionalità esposte dai Web Services.  Inoltre, non so voi, ma a me nel tempo è capitato spesso di vedere molte forme custom di integrazione alcune delle quali particolarmente fantasiose :-) Oramai i Web Services sono diventati una realtà non solo per le applicazioni utenti ma sempre più spesso anche da parte del Sistema Operativo. Quindi, chi meglio del S.O. può mettere a disposizione una libreria capace di “parlare Web Service”??

Altra richiesta fondamentale è la non dipendenza da altri stack tecnologici. Da anni si possono già integrare componenti .NET con codice C/C++ tramite ad esempio il Managed C++, pInvoke.... Tutte soluzioni però che vedono il caricamente del CLR all’interno dello spazio di indirizzamento del processo unamanged. Questo in molti casi è semplicemente non percorribile per motivi di performance, di security... Morale della favola : le WWSAPI non hanno alcuna dipendenza da altri stack tecnologici come COM, DCOM, .NET o altro... nemmeno ATL!!!! Sono delle semplici API esposte in un’unicqa DLL, WEBSERVICES.DLL, che non ha dipendenze particolari se non quelle classiche di sistema come ad esempio :

  • MSVCRT.DLL (Windows NT CRT)
  • WS2_32.DLL (Windows Socket 2.0)
  • HTTPAPI.DLL (HTTP Protocol Stack API)
  • WINHTTP.DLL (Windows HTTP Services)
  • CRYPT32.DLL (Prima di Vista)
  • BCRYPT.DLL & NCRYPT.DLL (Da Vista in poi)

Solo per Windows 7?

Trattandosi tipicamente di applicazioni C/C++ scritte negli anni non era pensabile che il S.O.di riferimento fosse solo ed unicamente Windows 7 e R2 di W2008. Per questo motivo le WWSAPI saranno disponibili anche per tutti i S.O. ancora coperti da supporto tecnico:

  • Windows XP con Service Pack 2 (SP2) e successivi
  • Windows Vista
  • Windows Server 2003 con Service Pack 2 (SP2)
  • Windows Server 2003 R2 con Service Pack 2 (SP2)
  • Windows Server 2008

La domanda più ricorrente a questo punto è : perchè non Windows 2000? Perchè ormai W2K è fuori dai cicli evolutivi e di supporto.

Download delle varie versioni : https://connect.microsoft.com/WNDP/content/content.aspx?ContentID=11205

WWSAPI e WCF che relazione?

nessuna :-) ormai dovrebbe essere chiaro. WWSAPI non hanno dipendenze con il framework .NET e quindi neppure con WCF. Sono due librerie paritetiche : WWSAPI utilizzate in codice unmanaged; WCF in codice managed! Condividono però una serie di similitudini come ad esempio il modello di programmazione Function-oriented che permette di mascherare al programmatore i dettagli di una comunicazione message-oriented. Altra similitudine è il supporto a scenari più articolati come quelli previsti dallo stack di specifiche WS-* per i Web Services : 

Specifiche di Base:

  • Trasporto
    • HTTP, TCP, UDP
  • XML Encoding
    • Text, Binary, MTOM
  • Metadata
    • WSDL 1.1, XML Schema 1.0
  • Envelop
    • SOAP 1.1 e SOAP 1.2

Specifiche WS-*

  • Addressing
    • WS-Addressing 0.9 e 1.0
  • Metadata
    • WS-MetadataExchange 1.1
    • WS-Transfer March 2006
  • Security
    • WS-Security 1.0 e 1.1 (implementazione parziale)
    • WS-Trust February 2005 e 1.3 (implementazione parziale)
    • WS-SecureConversation 1.1 e 1.3 (implementazione parziale)
  • Policy
    • WS-Policy dalla versione March 2006 alla 1.2
    • WS-PolicyAttachment dalla versione March 2006 alla 1.2
    • WS-SecurityPolicy 1.1

 

Come si può notare a fianco delle specifiche di sicurezza c’è la scritta un po’ inquietante : implementazione parziale. Questo significa che la versione 1.0 delle WWSAPI implementano solamente la sicurezza a livello di trasporto e Mixed-mode Security escludendo di fatto quella parte delle specifiche relative alla sicurezza a livello di messaggio che al contrario è presente in WCF. Quindi riassumendo le caratteristiche del Channel Security avremo:

Trasport Security:

  • HTTP : SSL e Header auth: basic/digest/SPNEGO/NTLM e SSPI
  • TCP: Windows SSPI e SSL

Mixed-mode Security

  • Il trasporto mette in sicurezza la connessione e fornisce la funzionalità di server authentication.
  • Gli Header WS-Security all’interno dei messaggi SOAP vengono utilizzati per il client authentication:
    • Token : Username/Password, Kerberos AP_REQ, SCT, Generic XML
    • Supporto a token SAML e scenari di Federation.


WWSAPI Architecture

Nella documentazione ancora in BETA ogni tanto si fa ancora riferimento alle WWSAPI con il codename Sapphire !

Nella figura sottostante è schematizzata la struttura delle WWSAPI:

image

Figura 1 : architettura delle WWSAPI

Esistono una serie di oggetti trasversali ai layer come ad esempio Errors, Tracing, Heap che permettono al programmatore di gestire facilmente alcuni aspetti della gestione delle WWSAPI. L’oggetto Error ad esempio permette di uniformare la gestione degli errori semplificando anche la complessità dei SOAP Faults mentre l’oggetto Heap permette di fare chiarezza su chi alloca e chi disalloca le risorse impiegate per la gestione delle comunicazioni. Maggiori informazioni sull’uso di questi oggetti e relative funzioni si trovano qui

Come si può notare dalla figura 1 il codice applicativo può lavorare a diversi layer a seconda del livello di dettaglio che si vuole gestire direttamente. In due parole cercherò di descrivere i vari layer mentre una descrizione più esaustiva la si può trovare qui sul sito MSDN.

Il Service Model è il layer più ad alto livello che permette di gestire la comunicazione tra il client e il Web Service con il modello a chiamate a funzioni. Il punto di contatto tra il client e un Web Services anche per le WWSAPI è solo il WSDL e gli XSD che vengono trasformati in codice C (.c e .h) da una utility a riga di comando wsutil.exe (Maggiori dettagli nel prossimo post dove partiremo da zero nell’integrazione con dei Web Services).
Lato client permette di chiamare delle funzioni proxy generate dal tool WSutil.exe mentre lato server permette di concentrarsi quasi esclusivamente nell’implementazione delle funzioni di callback.

Il Channel Layer rappresenta una astrazione del canale di comunicazione e permette di interagire direttamente con le sue poprietà. A mio avviso non saranno molti gli scenari dove sarà richiesto l’accesso a questo livello di dettaglio.

L’ XML Layer/Serialization rappresenta il proprio motore specializzato per i’ XML parsing delle WWSAPI con encoding Text, Binary e MTOM. Queste API esportano un XML Buffer, un XML Reader e un XML Writer che permettono di gestire, leggere e scrivere documenti XML solo in modalità “forward-only”. L’unica nota che mi preme sottolineare è il non supporto dei DTD come spesso avviene in scenari SOAP. Anche in questo caso a mio avviso saranno pochi gli scenari dove è richiesto un intervento a questo livello.

 

Nel prossimo post vedremo come utilizzare queste API passo-passo in diversi scenari…

 

--Mario

Comments