One of the goals of a large state-wide multi-agency data sharing project my organization is participating in was to start with a partner designed WSDL and then implement it in the underlying technology of the partner's choice. For my organization this technology is Windows Communication Foundation. From it's inception the WSDL had to be simple and interoperable. This is the second time I had started with a WSDL and then created a conformant service.
My organization was one of the few that actually had a good base of experience with web services and NIEM. We were best-suited to provide input into the WSDL and work with the leading partner (the grant receiver and "pockets"). This was a great exercise in a few things:
Virtual project management: Several hundred miles separate all the partners. My counter part at the lead partner is a young guy like me and preferred email over telephone (most times). We hashed out the WSDL and several other items with a few brief to medium sized e-mails.
Interoperability: The lead partner speaks Java, we speak .NET. Other partners speak neither. We learned to meet in the middle and actually came to appreciate the underlying technologies more (for the record I have never been a huge fan of Java - it's mostly the runtimes fault I think, not the language itself).
Architectural leadership: This collaborative, open standards approach required a new outlook on connected systems and leadership in pushing change and promoting it to the other partners who have not caught up with recent developments like SOA, web services, and open standards.
After two cuts we had a WSDL that encompassed the 7 operations we would need and defined the input and output messages. Besides a few naming items (I was new to creating a WSDL from scratch) we ended up with a contract that is clear on the intent of each operation and what inputs/outputs it will have. The outputs were generally simple, requiring only an acknowledgement of message receipt. One of the design goals is to minimize the amount of time web service calls have to wait because much of the processing required will happen after the messages are received.
To implement the WSDL I researched WCF and found that Svcutil would do exactly what I needed. I tinkered with the options and successfully got the WSDL to import in a very short amount of time. The implementation language is VB.NET and everything came right in. I did not like that the importer created a single file with all the requisite classes (data contract, message contract, service contract, and service stub). I had started modeling a few of these early on and so I ended up cutting and pasting a few things but other than that it was very smooth. I saw very few warning messages and overall was happy with the speed and results of using Svcutil.
I sent the sample soap output (captured using WCF tracing) and received positive feedback from the lead partner. The message conformed to our contract and we will be able to proceed with a test soon.
Now, I wish I could say that another partner involved had the same luck. This partner is particularly behind in the web service area so in lieu of seeking training and developing their own knowledge base they purchased a magic box product. I will not name this vendor as they have at least admitted to their fault in this. This particular product is not able to import a WSDL the way WCF and Java can. This led to a very sticky situation and some finger pointing that was eventually resolved when the vendor did state the product could not support what we were doing. An unfortunate turn of events as we had already put considerable time into drafting the WSDL and message schemes and had already opted out of the bus approach in favor of the distributed contract based approach.
Due to the agility of the lead partner they were able to create a client to work with the disfigured WSDL generated by the third-party utility (which incidentally is Java based).
I oft wondered when the magic boxes would replace coders entirely but it seems as though we are not quite there. I cannot say I was disappointed at this "set back". The cost of this magic box and its training was about 4 times the cost that will be billed to the grant to have me do the work manually using an open design and open standards that will allow us to change the underlying implementation with minimal impact (other than time involved).
Everything has it's place and I'm sure one day I will have a need for such a device. Until then I will continue leveraging automated tools where handy and doing some manual labor to ensure services and components conform to good designs and practices.