Selling my book collection at Amazon…

I recently moved to a smaller place and can’t keep all my technical book collection.

I’m selling the books that I already read, no longer need or have duplicates. Some of them are for old .NET frameworks, but if you are maintaining legacy applications with these framework versions, the books from Microsoft Press can be helpful.

There are also books about SOA and SOAP, SQL Server specific books etc. The books are selling pretty fast.

You can access my seller’s collection at Amazon here.

All the prices are set for shipping within the USA only.

Happy coding!

Oh Fiddler, how did I live without you?

This is one of the tools that once you get a good grab of it, you can’t let go…

Fiddler link here

For me it’s invaluable the information it gives me to debug my custom soap headers or my JSON streams.

One trick though, if you are hosting your services on a webserver on your own development box, use the machine name instead of localhost on your HTTP requests or Fiddler won’t intercept them.

Other than that the TextView/XML View is the perfect tool to see what you’re sending on your SOAP request:

Happy SOAP envelop debugging 😉

Client proxy stub generation nightmare. SVCUtil generates colliding types. Beware of the porttype name and your data types…

This is one of the things that drives us insane from time to time. You may call this a bug, a lazy developer encapsulating bad code on a code generation tool, or just bad luck, but I quite some hours on this issue.

We have Java services that need to be consumed from C# client proxies. We do have a contract first approach and have the types defined on schema files and the service contracts are defined on their corresponding wsdl 1.2 files.

We validated the wsdl and xsd files with Altova XmlSpy and did the code generation with the svcutil tool several times, as well as the Visual Studio 2008 Add a Service Reference Tool.

The code generation  goes on fine, but the project that contains the proxy classes does not build. There are conflicting type names under the same namespace.

This does not happen with the Java client proxy generation tools, the Java code builds fine.

Here’s part of the problematic wsdl:

<?xml version=”1.0″ encoding=”utf-8″?>
<wsdl:definitions xmlns:tns=”http://service.some.com/Driver/” xmlns:soap12=”http://schemas.xmlsoap.org/wsdl/soap12/” xmlns:xsd=”http://www.w3.org/2001/XMLSchema” xmlns:comm=”schema” name=”Driver” targetNamespace=”http://service.some.com/Driver/” xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”>
<wsdl:types>
<xsd:schema targetNamespace=”http://service.some.com/Driver/”>
<xsd:import schemaLocation=”Schema.xsd” namespace=”schema” />
<xsd:element name=”UpdateDriver”>
<xsd:complexType>
<xsd:sequence>
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”driverId” type=”xsd:int” />
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”driver” type=”comm:Driver” />
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”driverRelation” type=”xsd:int” />
<xsd:element minOccurs=”0″ maxOccurs=”unbounded” name=”claims” type=”comm:Claim” />
<xsd:element minOccurs=”0″ maxOccurs=”unbounded” name=”convictions” type=”comm:Conviction” />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name=”AddDriverConviction”>
<xsd:complexType>
<xsd:sequence>
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”driverId” type=”xsd:int” />
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”convictionDate” type=”xsd:date” />
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”convictionType” type=”xsd:int” />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name=”UpdateDriverConviction”>
<xsd:complexType>
<xsd:sequence>
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”driverId” type=”xsd:int” />
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”convictionId” type=”xsd:int” />
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”convictionDate” type=”xsd:date” />
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”convictionType” type=”xsd:int” />
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<wsdl:message name=”CreateDriverRequest”>
<wsdl:part name=”parameters” element=”tns:CreateDriver” />
</wsdl:message>
<wsdl:message name=”CreateDriverResponse”>
<wsdl:part name=”returnValue” element=”tns:CreateDriverResponse” />
</wsdl:message>
<wsdl:message name=”UpdateDriverRequest”>
<wsdl:part name=”parameters” element=”tns:UpdateDriver” />
</wsdl:message>
<wsdl:message name=”UpdateDriverResponse”>
<wsdl:part name=”returnValue” element=”tns:UpdateDriverResponse” />
</wsdl:message>

<wsdl:portType name=”Driver”>
<wsdl:operation name=”CreateDriver”>
<wsdl:input message=”tns:CreateDriverRequest” />
<wsdl:output message=”tns:CreateDriverResponse” />
</wsdl:operation>


</wsdl:portType>

<wsdl:binding name=”DriverSoapBinding” type=”tns:Driver“>
<soap12:binding transport=”http://schemas.xmlsoap.org/soap/http” />
<wsdl:operation name=”CreateDriver”>
<soap12:operation soapAction=”http://service.some.com/Driver/CreateDriver” />
<wsdl:input>
<soap12:body use=”literal” />
</wsdl:input>
<wsdl:output>
<soap12:body use=”literal” />
</wsdl:output>
</wsdl:operation>
<wsdl:operation name=”UpdateDriver”>
<soap12:operation soapAction=”http://service.some.com/Driver/UpdateDriver” />
<wsdl:input>
<soap12:body use=”literal” />
</wsdl:input>
<wsdl:output>
<soap12:body use=”literal” />
</wsdl:output>
</wsdl:operation>

</wsdl:binding>
<wsdl:service name=”DriverService”>
<wsdl:port name=”DriverPort” binding=”tns:DriverSoapBinding”>
<soap12:address location=”http://www.example.org/” />
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

and the schema file:

<?xml version=”1.0″ encoding=”utf-8″?>
<xsd:schema xmlns:this=”schema” targetNamespace=”schema” xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>

<xsd:complexType name=”Driver”>
<xsd:sequence>
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”person” type=”this:Person” />
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”driveInNASince” type=”xsd:date” />
<xsd:element name=”driverLicence” type=”xsd:string” />
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”provinceOfLicence” type=”xsd:int” />
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”graduateType” type=”xsd:int” />
<xsd:element name=”hasTrainingCertificate” type=”xsd:boolean” />
<xsd:element minOccurs=”1″ maxOccurs=”1″ name=”hasAutoInsuranceBefore” type=”xsd:boolean” />
<xsd:element name=”previousInsurer” type=”xsd:int” />
<xsd:element name=”previousPolicy” type=”xsd:string” />
</xsd:sequence>
</xsd:complexType>

</xsd:schema>

The generated code had a Driver Interface defined and a driver partial class defined.

After quite a few hours trying to figure out what was wrong (we changed the namespace names, the type names etc), a colleague pointed out the name of the port on the wsdl file.

Voilá!!!

On the service definition tag in the wsdl we put:

<wsdl:portType name=”DriverService“>
<wsdl:operation name=”CreateDriver”>
<wsdl:input message=”tns:CreateDriverRequest” />
<wsdl:output message=”tns:CreateDriverResponse” />
</wsdl:operation>

<wsdl:binding name=”DriverSoapBinding” type=”tns:DriverService“>


Now the interface is generated with the name DriverService and not Driver, so there is no collision with the data contract types, whew…

Happy development!!!

Web Services Contract First doesn’t guarantee Interop always

I found this very good article that answered part of the questions I had on my previous post.
The part that is enlightening regarding WSCF as how despite that it might be less productive than Code-first, might offer better Interop in the long run is:

What? Code-first is interoperable?

Well sure! You generate schema from code, proxies consume schema and generate a representation of the schema for the caller’s platform. Of course the serialized type has to be meaningful to the caller, so a DataSet in .NET though serializable makes a horrible candidate for cross platform interoperability. Aside from this, one of the biggest interoperability issues between platforms has to do with runtime schema support. Schema is a vast standard that has much more capability than many parsers have support for. Thus, interoperability can be an issue whether you begin with schema (contract-first) or when you generate schema from objects (code-first).

Ok, ok, the article is dated 2005, but don’t be too hard on someone who has been doing windows forms and CAB for the past year :-p
Designing Service Contracts with WCF

Web Services Contract First???

I know we .NET developers have been spoiled for a while.

We go on VS2005 and create a new web site project, select the type of project as web service and voila, we land on a page where we can start typing new methods for this class and mark them as web methods with a single annotation. VS2005 does all the plumbing for us creating the wsdl and even publishing the web service for us with another click.

But, is this good enough?

If your enterprise is fully .NET, there is no harm, but if you want to inter-operate with other platforms, they might not understand what your WS said…

VS2005 implements WS-I Basic Profile 1.1, but I believe you can still use .NET types such as special collections…that won’t have a Java counterpart.

WSCF existed for a long time on the Java world, VS2005 comes with two command line utilities that can serve to the purpose (xsd.exe and wsdl.exe) but, imho, they are hard to use.

You can always request to your manager a license of Altove XMLSpy…
Or go for this freeware tool made by thinktecture:

WSCF

The tool is good if you define all of your types in a single .xsd file. If you have several files with your types and you import from one namespace into one of your schema files, you might have troubles…

Also the pumbling this utility generates is only for SOAP web services, not for REST web services.

I talked to the Java guru in the office and he mentioned that WSCF was long gone from the Java world, with Eclipse, he only had to define his business payload and the plumbing was done for him on any transport protocol he would choose…So they sort of had to define the payload first, not exactly the contract first…

That triggered my curiosity. I wonder if there is anything like it on VS2008 with WCF…

If you know and can lit the path, please comment. I’m planning to play with this on the next few hours.

Happy coding!