Sharepoint Designer 2010 can’t connect to the server

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.

Ma quanto è bello il trace del WCF

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).

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!  🙂

WCF e REST/POX

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.

Come costruire un WebServices con WCF che vada d’accordo con WebSphere

Nell’altro mio blog Enterprise Bus (dedicato ad argomenti di integrazione e SOA dal punto di vista pratico) ho pubblicato un post che indica in modo molto semplice come come costruire un WebServices con WCF che vada d’accordo con WebSphere.

IBM WebSphere MQ (MQ Series), PowerShell e WCF

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.

IBM J2EE e Microsoft .NET

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.

La teiera di Petzold

Charles Petzold si è divertito a rifare la teiera in XAML/WPF! E l’ha pure animata!

WCF, IBM WebSphere Process Server e Tuscany

Questo è un post sulle “tubature”.

IBM WebSphere Process Server implementa SCA e SDO, delle specifiche molto note per chi lavora con tool simili. Fondamentalmente usando questo tipo di tool è possibile definire una serie di servizi e di oggetti utilizzati/forniti dai servizi utilizzando linguaggi come WSDL e XSD. Da questi è poi possibile passare a delle implementazioni in vari linguaggi (fondamentalmente Java e C++). E’ anche possibile definire un servizio partendo dal codice stesso. Il canale di comunicazione utilizzato è poi fondamentalmente indipendente dal definizione del servizio (e dal codice che lo implementa, ovviamente).

Scartabellando qua è là mi è saltato l’occhio su un esempio di codice Java che potrebbe costituire un semplice servizio:

    public interface Calculator
    {
        float add(float operand1, float operand2);
    }

    public class CalculatorImpl implements Calculator
    {
        public float add(float operand1, float operand2)     {
            return operand1 + operand2;
        }
    }

Questo codice definisce una interfaccia e una classe che la implementa.  Grazie ad una serie di file di configurazione (in XML)  e/o a delle operazione di deployment il sistema genera il codice che ne permette l’utilizzo remotamente (via code, WebServices o meccanismi analoghi).  In generale i meccanismi che realizzano i “tubi” sono nascosti dai tool. In realtà usando Process Server si procederebbe alla definizione del servizio (tramite un tool basato su Eclipse che fondamentalmente genera WSDL) e poi alla generazione del codice.

In WCF (e C#) si procederebbe così:

    [ServiceContract()]
    public interface ICalculator
    {
        [OperationContract]
        float add(float operand1, float operand2);
    }

    public class CalculatorImpl : ICalculator
    {
        public float add(float operand1, float operand2)
        {
            return operand1 + operand2;
        }
    }

Poi grazie ad una serie di file di configurazione (in XML)  e/o a delle operazione di deployment il sistema genera il codice che ne permette l’utilizzo remotamente (via code, WebServices o meccanismi analoghi).  In generale i meccanismi che realizzano i “tubi” sono nascosti dai tool. 

Perchè mi sembra di ripetermi? 😉

E’ interessante notare che normalmente nel mondo Microsoft si procede scrivendo il codice e poi lo si decora con degli attributi. Infine un tool procede a generare il codice di implementazione e i file di configurazione. Nulla vieta però di partire direttamente dal WSDL.

Direi che oggi la principale differenza fra i due mondi è proprio questa: il programmatore Microsoft solitamente parte dal codice e poi procede a generare la definizione del servizio, il programmatore IBM/Java solitamente parte dalla definizione dei servizi e poi procede a generare il codice. Da notare che questo aspetto riguarda soprattutto i tool.

Tuscany è una implementazione del consorzio Apache di SCA e SDO. Quando sarà terminato la piattaforma Java avrà un meccanismo open source (e quindi diffuso e a basso prezzo) per realizzare una buona parte di quello che si fa con WCF. Se i due mondi saranno in grado di interoperare senza particolari problemi si potrà utilizzare un meccanismo ad alto livello che faciliterà enormemente l’integrazione di programmi su piattaforme differenti.

Come sempre WCF fa parte di .NET 3.0 e quindi gira anche su XP e 2003 ma su Vista viaggia ancora meglio.

WCF potrebbe essere la tecnologia di base per realizzare un Enterprise Service Bus (in senso SOA) su Windows (aggiungendo Biztalk e un po’ di testa). Le implicazioni su Vista sarebbero interessanti da sviscerare e magari ci tornerò in futuro.

Poi WCF ha delle altre particolarità che lo rendono ancora più valido per chi sviluppa su Windows ma questo esula dal discorso.