Cloud as a Story - Vunvulea Radu

These days I had to update a component that is used in Microsoft Dynamic AX. I don’t know to work with AX, but some time ago I had to write a component in C# that calls a WCF service of a 3rd party and is used by an AX application. The client proxy from C# component was update with the new client proxy; the code was also updated with the new logic. The unit-tests were updated also and we had a full green. Perfect, we send the component to AX team to update the reference to the component. They come back to us with a big ugly error: Error in deserializing body of reply message for operation … WTF, we had the same endpoint. We had a client proxy that works on our unit-tests and a command line test application, but when AX make calls using our component we get this great error message. The oddest thing is that we receive this error even if the message that is returned from the endpoint has only 20 characters. Before updating the AX worked great with our component. Looking over the int...

On the internet, there are a lot of companies that sell information or different functionalities that are exposed like as web-services. This week I had the “opportunity” to update a client application that use remote services from a 3rd part provider. And now the story begins. In the last 12 months, there were more than 9 new versions of the service that were roll out by the 3rd part. Not all the clients use the last version of the services of course, because of this they had to support also the old versions of the services. What was their solution for this? To create for each version a new method exposed in the same endpoint and service. Because of this for an operation like GetDriver we had the following possible calls: GetDriver(), GetDriver_V2(), GetDriver_V3(), GetDriver_V4(),GetDriver_V5(), GetDriver_V6(), GetDriver_V7(), GetDriver_V8(),GetDriver_V9() Imagine that this is happening for a lot of operations that are exposed. Beside this, not all the operations were updated, ...

If in my last post I talked a little about the limitations of Service Bus Topics, I think that this is the moment to see one of the greatest features of this service. Service Bus Topics has a lot in common with Service Bus Queues. In one of my posts I describe how we can integrate WCF with Service Bus Queues, but this can be done with Service Bus Topics as well. In a large system, we have a lot of services that communicate between them and there are cases when a WCF service do more than one thing because the endpoint of that WCF service is the entry point and this is the only way how we can ensure that a couple of actions are executed when the services is called by a specific client. Because of this is not very easy to add, remove some behaviors to an endpoint and also the load balancing in this case can be nightmare. Using WCF services exposed using Service Bus Topics can be our solution. Very easily a client can call a service that is only a façade to more than one service. Based on ...

In acest post am discutat despre cum se pot pune informatii in header-ul unui mesaj care este trimis prin WCF. In cazul in care incercati sa folositi aceasta solutie pentru un client pe Silverlight, o sa observati ca desi serverul adauga proprietatiile in header-ul mesajului acestea nu ajung la client, chiar daca pe sarma sunt adaugate. Din Silverlight nu avem acces la toate proprietatiile care sunt trimise in header. Avem acces doar la cateva proprietati. De exemplu una din propietati este StatusCode. Acesta are valoarea 200 daca apelul s-a terminat cu success. Datele care le punem in header pentru un client Siverlight, trebuie sa fie puse ca un nou Header. Mai jos gasiti cum puteti adauga un nou header de pe server, iar clientul cum il poate accesa. Al doilea parametru pe care l-am setat cu empty string reprezinta namespace URI pentru header-ul nostru. public class ServerTokenInspector : IDispatchMessageInspector { public void BeforeSendReply(ref Message reply, object corr...

De obicei intr-o aplicatie client-server folosim WCF pentru a putea comunica intre client si server. WCF este un framework destul de complex si desi este usor de integrat intr-o aplicatie, cand dorim sa facem ceva mai complex putem sa ne trezim pierduti intre tot felul de documentatii si carti despre WCF. In acest post o sa prezint cum putem adauga in header-ul mesajului care se trimite la client un continut custom( date suplimentare). O sa pornim de la urmatarea cerinta: fiecare mesaj care vine de la server trebuie sa vina insotit de un token unic a serverului. O solutie la aceasta problema ar putea fi ca fiecare mesaj( contract) pe care il primim de la server sa fie incapsulat intr-o clasa de tip Response care contina tokenul nostru. Aceasta solutie este destul de buna, dar ce ne facem daca avem nevoie sa adaugam alte date pe langa token? O sa fie nevoie sa facem update imediat la clienti, servicile pe care le expunem prin WCF trebuie versionate si alte probleme de acest gen. Plus ca...

In ultima perioada din ce în ce mai multe servicii publice în format REST au apărut pe piaţa. O problema destul de neaşteptata apare pe partea de client: Cum sa consumam un serviciu REST? Din start, .NET ne oferă doua variante destul de simple pentru a putea utiliza un serviciu REST: WCF Client - Service Contract; WebRequest; Pentru a putea consuma un serviciu folosindu ne de WCF avem nevoie sa ne declaram un contract (ServiceContract) în care sa specificam operaţiile care ne sunt puse la dispoziţie. [ServiceContract()] [XmlSerializerFormat()] public interface ICarClient { [OperationContract] [WebGet( ResponseFormat = WebMessageFormat.Xml, UriTemplate = "Car/{id}?userkey={userKey}")] Car GetCar(string id,string userKey); } La acest nivel am definit prin atributul WebGet locaţia acestei resurse (UriTemplate) relativa la adresa setata în fişierul de configurare. Urmatorul pas este sa ne configuram un endpoint in fisierul de configurare de forma: <system.servicemodel> ...

Cat de cunoscuta vi se pare eroarea aceasta? Prima parte din eroare mi s-a parut foarte cunoscuta in prima faza dar totusi e usor enigmatica. Problema cea mai mare la acest tip de eroare este ca nu ne spune exact care este cauza. Mai jos o sa gasit trei cazuri comune cand aceasta eroare apare Assembly-ul nu poate fi gasit in locatia data. In funcție de setarile proiectului unu sau mai multe assembly-uri nu se gasesc in locațiile specificate. Unu din assembly-uri este compilat pentru o alta arhitectura de procesor. De exemplu incercam sa rulam 3 proiecte care se refera intre ele. Unul din ele este compilat pentru x86, iar restul proiectelor sunt compilate pe o arhitectura de tip x64. Sunt compilate pe versiuni diferite de .NET. Un assembly este compilat pentru .NET 2.0, iar altul pentru .NET 4.0. Desii toate cazurile au soluții simple, din cauza ca rulam aplicatia din IIS, o parte din erori sunt vagi si apar doar la runtime. De exemplu daca avem un assembly care contine un serviciu WCF ...