WSCF.blue Beta-2

Beta-2 of WSCF.blue is now available.

The big feature of this new beta is the standalone Data Contract Generation and we have also put in some other fixes and addressed some outstanding issues (as well as rolling up fixes since the last beta).

The feature list is as follows. The “More Information” links point to posts on Alex’s blog with screenshots and lots of details.

• The Generate Data Contract Code feature is now available and supports the selection of multiple XSD/WSDL source files. (More Information)
• When the Enable WSDL Endpoint option is chosen a reference to the Thinktecture.ServiceModel.Extensions.Metadata.dll assembly is automatically added.
• Support for VB.NET has been added to the code generation.
• You can choose if operation methods on the service class will throw a NotImplementedException, call an implementation method in a partial class, or will be defined as abstract methods. (More Information)
• Force the SOAP actions (Action and ReplyAction) applied to each operation contract follow the standard WCF format: <namespace>/<service>/<operation>[Response]

Hope you find this release useful. As always , keep the feedback and suggestions rolling in. Enjoy 

WSCF blue: Beta-1

WSCF-blue, the WCF successor to the popular WSCF (Web Services Contract First) tool is now available in its first beta release at CodePlex. I’m delighted to be a part of the team working alongside guys like Christian Weyer, Buddhike De Silva, Edward Bakker and Alex Meyer-Gleaves.

If you aren’t familar with the tool, basically WSCF provides tooling to approach web service development in a contract first manner, specifically WSDL/XSD first rather than code-first. WSDL is often the favored ‘neutral’ ground for specifications to be agreed on in large projects where interoperability is key between heterogenous technologies. It is also common to find that the WSDL for web services is the first thing to be discussed between an application development team and a service provider (in any development / integration project). So , having a tool that allows you to work with WSDL and XSD in a consistent, reliable manner without getting bogged down in the intricacies of WSDL and associated specifications is a must. WSCF aims to address the lack of tooling in this space (especially in the .NET world).

WSCF is a Visual Studio 2008 add-in that provides the following features

• A WSDL Wizard that allows the developer to step through the creation of a WSDL from one or more XSDs
• A DataContract Generator (similar to XSD.exe, XSDObjectGen.exe and Svcutil.exe) that generates the . NET equivalent of the XSD types
• A Service/endpoint stub (SVC) generator and
• A client proxy generator.

In the current beta release, the stand-alone Data Contract generation option is NOT available, but that is something we will be addressing as a priority and should be available in the RTM release. However,  data contracts are generated as part of the service side stubs and client side stubs.

You can either install the MSI which makes the add-in available for an open solution (as the context menu for an XSD or WSDL) or if you are using the source version, you can debug the add-in directly using F5 which launches VS in the experimental hive as is normal for all add-ins.

I have been an regular user of WSCF since its ASMX days and found the quality of the code generated to be very high. We do hope you find that this tool goes some way toward addressing your needs with WCF development and are all keen to get feedback, bug reports and feature suggestions. With the number of project templates that are available for WCF (Web Site, Web Site -Remote IIS, WCF Class Library, WCF Service Application) and the rules that some of them have around structure, it has been quite a bit of work to get the features such as SVC generation sorted and I’m pretty sure that there will be other scenarios you are involved with where the tool needs improvement or enhancements.

Here are some other posts on the beta release by the other members of the team

• Next generation of a success story: WSCF.blue for WCF goes Beta 1
• WSCF.blue Beta 1 is out!
• WSCF blue – Are you doing contract first?

Keep an eye on the CodePlex space for information relating to the roadmap etc. Do check it out and let us know what you think of it.

What’s new in WCF 4?

Christian Weyer has been writing a very interesting series of posts on some of the new features of WCF 4.  There is still a long way to go for the release, so as with all products / technology stacks, it is wise to anticipate change. However, there is some really good stuff here and if all of this makes it into RTM in this form (or a better one), it should help quite a bit in doing advanced stuff with WCF.

Here is a list of the posts. Also a note on the disclaimer from Christian’s posts : all the information was gathered based on a close-to-Beta 1 build of .NET Framework 4.0 and Visual Studio 2010. Details may vary and change

•  Simplified configuration – or: “Look ma: my config shrinks!”
•  .svc-less Activation – or: “Look ma: my [REST] URLs look good!”
•  Dynamic service and endpoint discovery – or: “Look ma: I just need the contract to talk to my service!”
•  Standard endpoints – or: “Look ma: streamlined infrastructure and system endpoints!”
• Discovery announcements – or: “Look ma: I can see when my service goes online or offline!”
•  Routing Service – or: “Look ma: Just one service to talk to!”
• Protocol bridging & fault tolerance with the Routing Service – or: “Look ma: Really just one service to talk to!”

Happy reading !!

Waltzing with WSDL

One of my immediate goals for MockingBird is to have the “Configurator” UI done where you can just pick a WSDL on file or point to a URL and have the tool shred it and generate sample request and response messages into the correct folders (and generate the Handler Configuration) after which the user can then do any extra XPath based configurations to make the system more dynamic. Sounds easy enough, doesnt it? Well, thats what i thought too, until i delved into the intricacies of WSDL Parsing.

The class most people use is ServiceDescription and to be fair, it gives some information about the WSDL but navigating it is not easy at all and its not all that intuitive after you get to the point of listing all Operations inside the PortTypeCollection. There is also another big issue with trying to use ServiceDescription alone and that is the fact that WCF by default gives you multipart WSDLs. So getting hold of the WSDL from a WCF endpoint is not straightforward but one class that comes to the rescue is DiscoveryClientProtocol as Mike Hadlow points out in his article. This behavior can be changed as pointed out by Tomas Restrepo in hs post on “Inline XSD in WSDL with WCF” and Christian Weyer takes it up a notch in his article on Flat WSDL in WCF.

Anyway after pondering this a while, I decided it would be in my best interests to factor the code into a WSDLRetriever and a WSDLDescriptor. The Descriptor takes a dependency on WSDLRetriever (an interface of course, so its easy to mock) and expects  a single WSDL XDocument which it can work with. Now with this approach I dont care if the endpoint (if the WSDL is not on file) is a WCF endpoint or not, the Retriever does all that work. So the Descriptor can do its work and with that sorted i wrote up the first few tests for the Descriptor using a mock Retriever. So far so good.

Now, along with the requirement stated above, I also want to build a nice UI, where, you can not only do a single click to generate messages, but you can exercise finer control over the message content before storing them in the appropriate folders. So imagine if you will, a tree view which shows all the operations and the messages in them and immediately under the message name, the name of the complex type and additionally the body of the type (not in the tree node, but in an associated panel).

Of course, I’m not trying to write a completely generic WSDL parser, but something thats immediately usable by MockingBird and for other tools which can use a WSDL as input.

I had a look around at some blog posts and samples but none seemed to go as far as I wanted. I also took a look through the code for WSCF Blue  but couldnt make immediate use of that API. (I’ve since chatted with Buddhike about that so there may be something i could do with WSCF libraries in future). I looked at WebServiceStudio as the license allows reuse of the code there, but the code structure is simply awful. It works as is but everything is so deeply tied into the UI that it will take a feat of coding to extend it or pull out any reusable logic from it. I tried re-factoring a local copy but gave up pretty soon. So I had to work through the requirement myself.

Anyway, parsing WSDL is not easy at all. Once you get to the operation and message, you then have to wak through all schemas and their associated object tables to pick out the correct complex type corresponding to the message. This took me the best part of a few hours. Given that the user will not supply any namespaces, it gets very hard indeed. Thankfully the Schema Object Model is very decent. I used LINQ to XML for little bits such as extracting endpoint information (which also required me to resort to XPath extension methods because LINQ insisted i give it qualified names but I didnt know what the namespaces were !!) but for the schemas in WSDL, i think the SOM is better than LINQ. But I’m happy to be proved wrong!!

So I’ve got it to the point where it brings back the complex types. Now to generate sample instances from that for which I’ve got some resources. Once thats done and a simple Retriever implemented it wont be hard to put a UI on that because none of this is tied to the UI.

Thats it for now, a sort of ‘progress’ post for those waiting for the GUI for MockingBird and also to point out some of the dragons that await those who venture into the WSDL arena. Talk about ‘design by committee.. its a minefield!!

Couple of really good articles are Understanding WSDL by Aaron Skonnard (an old one, but an excellent read) and Walking the SOM by Stan Kitsis

Till next time

Workflow Services & Application Protocols

Its taken some time (and a lot of procrastination) but I’ve finally decided to properly get into WF and WCF and as a Biztalk guy, one of the things that most interests me is Workflow Services. I’ve known the basics of all of this for a long time but never dived into it, so i started sort of working backwards and chose Workflow Services as my starting point (no use in trying to learn the old Data Exchange mechanisms of WF V1 now really). I picked up some nice videos from Channel 9 and some from the VS2008 Training Kit.

I soon got into the video titled Building WCF Services with WF and within 2 minutes ran into something that disturbed me so much I had to write this immediately. When talking about the advantage of writing WCF services with WF, Pravin says that one of the pros is that “Application Protocol is enforced” and goes on to give an example where if we had a service where there was an AddPurchaseOrder and also a CreateCustomer, we (as service implementors) might expect that the Customer would be created first before the Purchase Order. But the client would not know this by looking at the WSDL. So we set up a flow in the WF and expose these methods at some point and if the client calls them out of sequence we can throw exceptions etc.

I dont know about you, but IMO, this would not be good service design. Let me try to explain. First of all I wouldnt mix two widely different documents in the same service unless this was merely a ‘composite’ which internally invoked the CustomerService and the PurchaseOrderManagement service. Even if it was a composite, the contract specified by this composite should allow the client to give the customer info (or a pre-existing ID) along with the other PO info all together and then communicate with the Customer and POMgmt to create the customer or update an existing record and then pass stuff between them all through well defined messages.  Those backend services are still valid on their own and can accept messages being sent directly to them from other clients but the composite is providing some extra functionality. Now if the whole process was rather long running and there was state to be maintained in between calls to those backend services then we can make use of low level persistence services in the framework so we could dehydrate the composite while waiting for responses. But I would not make the composite service so ’stateful’ that it exposed two or more methods as entry points and insisted that they be called in a sequence. (its a completely different matter if you are implementing a convoy in Biztalk where you may have multiple receive shapes which are linked together by correlation. Here we are talking about different ‘method calls’). Theres no service provided here just a wrapped collection of methods.

Just creating a few classes (whether declaratively implemented or handcoded) and exposing them over the wire doesnt make them business services. It worries me that devs are going to be throwing together some simple classes , fitting WCF endpoints on top of them and saying “Look, we have SOA” (and worse still, with all the designers, the claim would be “we have model driven SOA”.)  This is like going back to the ‘bad’ old days where people thought they had webservices just because they could stick [WebMethod] attributes on function calls. Let me re-iterate my point, a collection of visually designed classes that can listen on the wire is not model driven SOA. Its just that – a collection of classes, nothing more, nothing less.

So, back to the ‘protocol’ business. Sometime ago there was a lot of talk of web service choreography and a choreography description language to specify a sequence of ordered message exchanges. If the ‘composite’ service (discussed above) was implementing something like this, it would make sense. It shouldnt expose two random entry points and force a sequence of invocation. And if the composite was not providing any other  value other than just stringing together two calls why not just make the contract of the ’second’ service explicit (for instance , require a CustomerNumber or something) that makes it apparent that Customers should exist first and then we could do away with the composite altogether.

But theres nothing wrong with the Workflow Services as such (at least nothing thats immediately apparent considering im just getting into them.. flaws may surface in a few days). It seems like WF and WCF were made for each other and this is a good way of linking the two. I just dont buy the ‘application protocol enforcement’ claim.

What do you think? What ways would you choose to implement sequencing? Does anyone else use the workflow services to enforce sequence?