Archive

WCF

Yesterday I installed the first server of a Sharepoint Server 2010 farm. The installation went fine but I had problems when I tried to open a site using Sharepoint Designer 2010. Basically I was not able to connect and the Designer didn’t give any explanation. In the event log of the server I found this error:

<Event xmlns=”http://schemas.microsoft.com/win/2004/08/events/event&#8221;>
  <System>
    <Provider Name=”System.ServiceModel 3.0.0.0″ />
    <EventID Qualifiers=”49154″>3</EventID>
    <Level>2</Level>
    <Task>5</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime=”2010-04-24T08:49:47.000000000Z” />
    <EventRecordID>2555</EventRecordID>
    <Channel>Application</Channel>
    <Computer>w3.example.com</Computer>
    <Security UserID=”S-X-X-XX-XXXXXXXXX-XXXXXX-XXXXXXXXXX-XXXX” />
  </System>
  <EventData>
    <Data>System.ServiceModel.ServiceHostingEnvironment
    +HostingManager/12547953</Data>
    <Data>System.ServiceModel.ServiceActivationException: The service
    ‘/_vti_bin/client.svc’ cannot be activated due to an
    exception during compilation. The exception message is:          
    A binding instance has already been associated to listen
    URI ‘
http://w3.example.com/_vti_bin/client.svc&#8217;. If two
    endpoints want to share the same ListenUri, they must also
    share the same binding object instance. The two conflicting
    endpoints were either specified in AddServiceEndpoint()
    calls, in a config file, or a combination of
    AddServiceEndpoint() and config. . —>
    System.InvalidOperationException: A binding instance has
    already been associated to listen URI
    ‘
http://w3.example.com/_vti_bin/client.svc&#8217;. If two endpoints
    want to share the same ListenUri, they must also share the
    same binding object instance. The two conflicting endpoints
    were either specified in AddServiceEndpoint() calls, in a
    config file, or a combination of AddServiceEndpoint() and
    config. at
    System.ServiceModel.Description.DispatcherBuilder
    .InitializeServiceHost(ServiceDescription description,
    ServiceHostBase serviceHost) at
    System.ServiceModel.ServiceHostBase.InitializeRuntime() at
    System.ServiceModel.ServiceHostBase.OnOpen(TimeSpan timeout) at
    System.ServiceModel.Channels.CommunicationObject
    .Open(TimeSpan timeout) at
    System.ServiceModel.ServiceHostingEnvironment
    .HostingManager.ActivateService(String normalizedVirtualPath) at
    System.ServiceModel.ServiceHostingEnvironment
    .HostingManager.EnsureServiceAvailable(String
    normalizedVirtualPath)
    — End of inner exception stack trace — at
    System.ServiceModel.ServiceHostingEnvironment
    .HostingManager.EnsureServiceAvailable(String
    normalizedVirtualPath) at
    System.ServiceModel.ServiceHostingEnvironment
    .EnsureServiceAvailableFast(String relativeVirtualPath)
    </Data>
    <Data>w3wp</Data>
    <Data>2956</Data>
  </EventData>
</Event>

I was thinking that the WCF tried to bind the client.svc to the same address two time. I found the problem to be in the name used by the server and in the bindings in IIS.

In this installation I’m using a split DNS (eg the internal IP domain is equal to the external IP domain). The FQDN of the server is w3.example.com. The Windows name is W3 and the Windows IP domain is example.com. I bound a web server certificate (principal name is w3.example.com) to the server. Then I defined https://w3.example.com as the main URL of the server and http://w3.example.com and http://w3 as alternate URLs. In the correspondent IIS web site I defined these bindings:

ip address protocol virtual server port
* http   80
* https   443
* http w3.example.com 80
* http w3 80

There was a conflict between the first (generic) binding and the third binding. The (WCF) client services (and other services, too) try to bind the same endpoint two times.

I solved the problem deleting the first binding.

Advertisements

Oggi io e un mio collaboratore siamo quasi impazziti per capire come mai le chiamate seguite da una portlet Java (ospitata in un IBM WCS) non funzionavano con un servizio REST/POX scritto in WCF. La cosa interessante è che le chiamate al servizio effettuate da un paio di (veramente piccoli) script PowerShell di prova funzionavano. Era evidente quindi che si trattava di un problema di comunicazione fra i due mondi. I problemi spaziavano dalla dalla indicazione della codifica alla mancanza di namespace e di campi. Il tutto dovuto fondamentalmente allo stack Java troppo vecchio (con l’IBM WebSphere Portal Server 6 non sarebbe successo).

image

Per fortuna che il WCF ha delle ottime funzionalità di tracing che ci hanno aiutato a isolare i problemi. E, nonostante questo, ci abbiamo perso delle ore.

Forse l’ho già detto ma io penso che il WCF sia proprio un gran bel pezzo di software!  🙂

A causa di un problema di specifiche supportate troppo vecchie da parte di una vecchia versione di portale IBM WebSphere Portal Server, ho dovuto cimentarmi nell’esporre in WCF un servizio tramite REST e POX. Andato a caccia di un po’ di esempi nell’SDK e dopo qualche esperimento in poco tempo ho avuto il servizio attivo. Indubbiamente il framework è molto potente e permette il controllo praticamente totale del dialogo. Però utilizzare un modello REST con POX vuol dire scendere ad un livello più basso cioè “lavorare con le tubature”. Efficace ma sicuramente meno elegante.

IBM ha rilasciato PowerShell for WebSphere MQ, un Support Pac per MQ sulla piattaforma Windows che ne permette la gestione tramite PowerShell. MQ è un middleware IBM che permette la comunicazione di differenti programmi su differenti piattaforme tramite un sistema a code distribuite. E’ un software estremamente affidabile e longevo che abbiamo usato con successo in molteplici scenari multipiattaforma. Ovviamente è un ottimo software utile in scenari di integrazione di sistemi (o in certe implementazioni di architetture SOA).

Non è la prima volta che IBM si integra egregiamente con Windows (il DB2, per esempio) e non è neppure la prima volta che si avventura sulle nuove caratteristiche rese disponibili da Microsoft. Ma, riguardo MQ,  molto interessante è il canale MQ per WCF. Questo software integra il Windows Communications Framework con MQ utilizzando SOAP per JMS. In altri termini rende facile la comunicazione fra sistemi .NET 3.x (e in ultima analisi Windows) e sistemi collegabili a WebSphere MQ come WebSphere Application Server o il CICS. Significa che si potrebbero integrare queste potenti tecnologie IBM (legacy e non) con i nuovi potenti framework di Microsoft. Peccato sia solo un proof of concept e per di più con alcune mancanze fondamentali e quindi non utilizzabile in produzione.

Uno dei progetti che sto seguendo in questi giorni prevede l’integrazione in architettura SOA di un sistema di radio terminali con Windows CE e Wi-Fi con altri sistemi tra cui un iSeries e alcune applicazioni WebSphere. Trattandosi di un progetto pilota in un “Java Shop” (più propriamente un utente IBM WebSphere) abbiamo simulato la presenza di un ESB mediante una semplice applicazione J2EE (processi, coreografie e business object sono molto semplici quindi il discorso ci stava).

Dal punto di vista tecnologico quando si fa integrazione di sistemi eterogenei esiste un forza che contrasta l’obiettivo. Io la definisco genericamente “impedenza”. In pratica se due sistemi si devono parlare queste impedenza fa di tutto perchè ciò non avvenga. Un sistema completamente chiuso senza alcuna documentazione e nessuna possibilità di utilizzarne i dati e/o le transazioni porta l’impedenza all’infinito. Se ho N sistemi l’impedenza totale è data dalla combinazione dell’impedenza di ogni interazione possibile. Oltre a questo l’impedenza aumenta quando i due sistemi devono essere fortemente accoppiati (come al limite in un classico client server). Per semplificare l’integrazione occorre diminuire il valore di questa impedenza. In tal senso, dato che riduce il numero di interazioni e semplifica l’uso della tecnologia di integrazione, un ESB diminuisce questa impedenza. SOA lo fa ulteriormente estendendosi anche alla parte “organizzativa”.

Tornando al nostro progetto, per diminuirne l’impedenza abbiamo deciso di utilizzare .NET per l’integrazione dei terminali e il server di gestione degli stessi. In altri termini il software sui radio terminali è scritto in .NET Compact Framework mentre il server dei radio terminali è nato come una applicazione .NET Framework. Per far parlare i terminali con il server e, soprattutto, il server con il nostro pseudo ESB abbiamo utilizzato il Windows Communication Framework (WCF). Il nostro pseudo ESB utilizza poi Java per comunicare con altri sistemi Java e con l’iSeries (tramite JTOpen 400).

Chiaramente l’impedenza di due elementi che utilizzano lo stesso framework per comunicare è veramente bassa. Fatta l’interfaccia e pubblicato i servizi la scrittura del client su radio terminale ha richiesto poche ore. Lo stesso è accaduto tra gli elementi Java dove si è perso più tempo nel decidere cosa fare che nel farlo.

L’aspetto che però, come sempre, più mi ha colpito è la comunicazione fra WCF e J2EE. Se si tolgono alcune noiosità l’impedenza tecnologica tra J2EE (su WebSphere Application Server 6.1 ed Eclipse 3.3) e WCF (su .NET 3.5 e VS2008) è veramente bassa. Gli standard WS-qualcosa semplificano la vita ma soprattutto i tool sono in grado di utilizzarli in modo efficace (non era così ai tempi di .NET 2.0). Alcuni aspetti di scrittura di codice ripetitivi e noiosi si possono aggirare utilizzando furbescamente e in modo parametrico la reflection sia in Java che in .NET. Ed è interessante il fatto che io stia parlando della parte bassa dello stack senza scomodare tool come Biztalk o WebSphere Process Server.

Se aggiungiamo il fatto che entrambi i framework parlano con il proprio legacy (IBM J2EE con mainframe/COBOL/DB2/CICS/IMS/iSeries/ecc. e Microsoft con COM/DCOM/COM+/WIN32/ecc.) ci si rende conto di trovarsi di fronte a delle possibilità molto ampie.

Certo utilizzare questi tool richiede una certa esperienza (ci è capitato persino di trovare WebServices assolutamente perversi e praticamente inutilizzabili) ma, in definitiva, quando si parla di interoperabilità tra i due mondi sia le tecnologie Microsoft che quelle IBM/J2EE possono essere utilizzate con fiducia.