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.

Blueprints – Down but not out

Some of you may have noticed that the Microsoft Blueprints project has gone quiet and the site taken down from CodePlex and MSDN. I had written a couple of posts about Blueprints in the past and how it was eventually going to take over from GAT/GAX.

Anyway, if you are wondering what’s happening, the answer is that we are making some changes around Blueprints. The Blueprints project was an important incubation whose purpose was to explore process guidance and automation. They helped us (that is, the product teams involved in developing this) gain a better understanding of the requirements for this kind of technology through customer and partner feedback. The reason we took down the external projects was to focus the incubation internally and we are looking at taking this forward so we can support process guidance and automation in a manner that is aligned with VS Team System product direction.

As users of VSTS know, the suite is not based around any particular methodology and can support a range of project methodologies ranging from very lightweight to very formal and process driven. The tooling supports this range of methodologies. Software Factories are an important development discipline which we support and as Jezz Santos  and Edward Bakker  and other thought leaders have written, it is possible to approach factory development itself in agile or very formal ways and its quite often found that a rapid iterative approach works very well with developing factories That said, VS should and will support factory development going forward in a manner thats agnostic of methodology. Exactly how this manifests itself in the product suite remains to be seen but having looked at the features that are available already in Dev10 Beta-1 in the VS Team Architect edition, we can be sure that it will be of high quality.

GAT/GAX will be available in VS10 and the DSL Toolkit has been improved quite a bit and aligns well with the new “Extensions” model so if you havent checked out the latest developnments in the DSL Toolkit space, I would encourage you to take a look. Stuart Kent has a nice video on the new deployment method for DSL Toolkit based packages.

I will post more on this topic when there is more information that I can share and especially when there are bits available to play with. Watch this space .

Dev10 Dive: 1 – Emphasizing TestFirst

I recently downloaded and installed Dev10 Beta-1 and created some images for my team. The Channel-9 video guiding us step by step through the whole process was invaluable. One thing that had me in trouble was the installation of Full Text Search in SQL 2008 (as TFS requires this feature). When i captured the ISO image (as we usually do in Virtual PC) and installed from there, the installation failed. It turns out that the installation media needed to be inside the VM. That done, the rest of the installation was fine.

Anyway, I then got hold of the VS 10 Training Kit and started with the WF labs. Got one full exercise done. The thing that impressed me most, was not actually WF itself (at this particular time), but the fact that when writing the custom activity, the instructions were to first write a test to check the output of the activity. Not only that, there is also a nod to the BDD side of things as the name of the test was “ShouldReturnExpectedGreeting” (or something along those lines) . Now , if you’ve looked at the various blogs around BDD,  one of the first steps (or baby steps if you like) towards proper BDD is to start naming tests like this rather than staid old “TestGreeting” or “GreetingTest“. It may seem like a small thing (and that was my opinion when i started down this route as well), but to me, it made a lot of difference to the way I approached my tests and helped me nail the purpose of the test better , thus also keeping it concise. Aside from this it serves as a form of documentation so a quick glance over your code base (even for your own code when you look at it after a few weeks or months) will bring you or the reviewer upto speed faster than with dodgy or less meaningful names.

In keeping with this emphasis on the test first approach, there is another, older video on Channel 9, part of the same series titled “Code Focussed in VS10” which shows some of the new features that allow us to write the test first and then have the IDE generate the class stubs and method stubs from the test itself. Of course, for those devs using R# and other refactoring tools this is nothing new, but lots of developers dont use them and this is a nice addition to allow us to really write the tests first and stay within the test, fleshing out the class as we go along rather than just writing a failing stub and then switching attention to the class because, unless you are very disciplined once you start working on the class, you tend to leave the tests behind and revisit them later with the attendant refactoring of code and tests.

So, there it was a rather pleasant discovery of a development discipline in a rather unlikely area (considering how design and IDE driven WF is). I’m looking forward to the other labs and I hope this emphasis is in them as well.

VS Color Schemes : Rejuvenating Development

Ok, so I’ve been really late to this particular party, but I gotta say, I’m absolutely thrilled with the effect that changing the color schemes of VS has on improving my coding morale!! I’ve been using several schemes from Tomas Restrepo’s collection and its done wonders for me  (specifically Ragnorak Blue, Grey and Moria Alternate).  Since I’m using VS 2005 and 2008 side by side, I have quite different color schemes for them and it makes things more interesting than the mundane white background. Maybe it’s also age and the fact that my eyes get tired more easily but hey, Consolas at 15pt looks awesome.

Having said this, I also started work on Dev10 and I must say, the OOB color scheme is nice. The new WPF editor renders the fonts much crisper and neater so I’ve been content to leave it without changing to a dark background. I guess we’ll have to wait a while for some new schemes to emerge. Quite sure the new editor has various new options for color schemes.

Another thing that its done, aside from make my IDE look nicer, is that it’s given me a coding boost. In fact, my releasing BizUnitExtensions 3.0 is more down to the new color scheme than anything else  .

So, if you havent taken this particular plunge yet, why not try it out?

BizUnitExtensions_v3.0 Beta-1

Finally made some progress on BizUnitExtensions and have released Beta-1 for the new version which now complies with BizUnit 3.0’s object model. This release specifically centres around the main Extensions and the Extensions.BizTalk  libraries.

Main changes

• The Altova library has now been deprecated as there is much better xml validation support in the .NET Framework so the altova library is redundant.
• The steps for manipulating applications, receive locations and send ports have now been completely overhauled, so there is a separate ApplicationConductorStep, ApplicationGetStatusStep and ApplicationVerifyStatus step and likewise for ReceiveLocations and Send Ports. The GetStatus steps will load the current status into the context which can be useful when we need to use that info in subsequent steps. VerfyStatus will check the status against a given value.
• The ReceivePortConductorEx step in the old code-base has been transitioned to the above mentioned set of ReceiveLocation steps as it really was dealing with locations rather than the ports. There is a new ReceivePortConductor step which allows the bulk enabling and disabling of all the locations in that port.
• Updates to the Orchestration Conductor allowing a STOP action on an orchestration.
• The namespaces and assembly names have all been revised (for example, using the Biztalk steps requires the assembly name to be BizUnit.Extensions.BizTalk.dll) so your existing test cases will need to be updated.

Forthcoming Updates and Releases

• Bram Veldhoen has contributed a fair amount of code including steps to link in with the Pipeline Testing Library. I will incorporate that into Beta-2 as I need to work through all the steps and the associated helpers and utility classes.
• I have updated the Oracle and EntLib libraries as well, but haven’t had any time to test them. As I now have Oracle XE, I should be able to make some progress on that pretty soon. With EntLib, its a little more complicated. As I didnt write those steps myself, I am not too familiar with the code, so it will take a while to update. So for the present, its still using EntLib 3.1. 

Workspace Updates

• The codeplex workspace has also been cleaned up and slimmed down drastically. A lot of the pointers to tutorials etc are all largely redundant anyway.
• The Roadmap page has been completely rewritten. The framework has come a long way since that material was written. The only stuff left there is a list of probable new steps and some ideas for tooling around BizUnit which may make it into some future version of the framework.

Hope you find the updates useful. Let me know if you encounter any bugs or if you have any suggestions.

MockingBird- Beta 2

MockingBird – Beta 2 is now available.

The changes/ fixes are as follows
(1) The system can handle remote WSDL’s now (using DiscoveryClientProtocol). [But this will use the Default network credentials to get the WSDL. There are no facilities as yet for providing this information as settings for the tool).
(2) Fixed the WSDL Browser which crashed when loading WSDLs into the tree view where there were one way operations in the WSDL.
(3) Xml Instance Generator now allows an overloaded constructor where a GeneratorSettings instance can be passed in to control the output.
(4) Documentation has now been split into a User Guide and Technical Documentation and thoroughly revised.

As mentioned in previous posts, the system is very stable (at least for the WSDLs and services I have tested and used it with) , so the fact that it is still officially a beta-2 shouldnt prevent anyone from using it.

Things that need to be done for RTM are

• some additional entry points into the XmlInstanceGenerator,
• adding some “settings” forms where users can set things such as network credentials when dealing with remote WSDLs etc.
• Update the class library documentation
• Use Unity in the Service Studio
• Run the code-base through StyleCop and FxCop. (This last part has me worried . How much am I going to need to rewrite?))

Check it out and, as always, feel free to send feedback.

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

MockingBird – Beta

Whew! I’ve finally managed to get the first beta release of MockingBird out the door, almost 3 months after the alpha. The past 3 months have gone by in a blur with my first major project in MCS and the associated tight deadlines and long hours. Technically its been a good learning experience, but it doesnt leave any time at all for side projects like this one, but I’ve managed to steal the odd weekend here and there and get this done.

The key elements of the beta release are

• The branding and naming is now beginning to work out quite well. As I had written earlier, it started life as MockWeb, then became MockingBird and now I have decided that I like the name “MockingBird” so much its worth promoting to the ‘brand’ or the name of the toolset. The constituent applications now have their own names. The web application with the HttpHandler is now called the “Service Simulator” and the main WinForms application is now called the “Service Studio” which will hold many modules and plugins.
• The Service Simulator has been completely revised using Unity IoC. I feel a lot happier with the design now and i think its more loosely coupled and the DI /IoC has a good side effect in increasing the test surface. The Service Studio doesnt use the Unity configuration yet, but will do so by RTM.
• The little ‘Driver’ GUI of the alpha has now been rolled into the “Service Studio” and is officially called the “Service Invoker”. The layout has changed and now uses tabs so occupies less screen real estate.
• There is a new “WSDL Browser” module in the service studio that allows you to load up a WSDL and it will parse the WSDL for you and list all the operations and allow you to generate sample request and response messages.
• The WSDL  Browser in turn makes use of an Xml Instance Generator module that provides a more usable facade over a sample from the MSDN archives. The XIG module can stand on its own and will grow in future releases.

The design principle of the Service Studio is that every piece of functionality must be accessible independently and not depend on a UI. This is one of the reasons it took so long to get this done. I came across quite a few samples of WSDL handling where the authors were willing to share and/or the license permitted extension, but the code was simply too deeply hooked into the UI and did not have any “API” to speak of. In the end I wrote the whole thing myself. I’m still looking for ways to plug it into related tools such as WSCF which I also participate in developing.

There are some limitations in the beta especially with regard to WSDL Parsing.

• The first limitation is that it cannot handle WCF multi-part WSDLs. This will be done by around RTM time or along with the V2 release as V2 should be fully WCF based.
• While developing i tested it with different types of WSDLs but in the final push I focussed on testing it with a local monolithic WSDL and so it may fall over with complex WSDL documents. The WSDL spec allows for a wide variation in the actual WSDLs so its not possible for me to cater to all possible kinds of WSDLs. I hope that if you come across an issue, then the source is easy to fix or that you can share the WSDL with me and I will try and sort out the parsing.
• I also only finalised the testing with a “local” WSDL on the file system. The “SimpleWSDLRetriever” class that I have implemented does not use DiscoveryClientProtocol (although i shall plug in a new class soon that does this) so it cant handle connecting to a non local service and downloading the contract and associated metadata. (As you can see, I know how to address the limitation – just havent had the time to write it   ).

Anyway, those limitations aside, I’m happy with the code base so far and it really is quite stable and if you need to extend and use the source, i think the current structure is easy to understand. On the codeplex space I have written more documentation on how the internals of the system work so hopefully that will be useful to you. If you do end up extending it, I hope you will let me know what you are doing with it and maybe I can incorporate some of those extensions if it will make the product more generic.

As always, please send me feedback, especially if you run into any bugs. Hope you like the new release.

Look Ma ! An evil middleware product!

I couldn’t resist commenting on this issue. I was just doing some final prep for my VBUG talk tomorrow and came across Richard Hallgren’s oddly titled post – Does BizTalk have man-boobs?. Richard writes about a QCon webcast of a session done by Martin Fowler and Jim Webber and writes

“Their main point is that we use much to bloated middleware (BizTalk is mentioned as an example here) and that we should have a more agile approach to implement SOA and ESBs. They’ve used all the agile ideas (testing, isolated testable functionality, deliver small and often, continuous builds etc, etc) and applied them to integration..”.

Richard goes on to make some good points which I totally agree with. Check out the post for details. I commented on the post and decided I would make those points again here and add a couple more, which is also quite good timing (for me) considering I’m speaking on BizTalk tomorrow.

So, I agree that BizTalk is totally unsuitable for small situations and if it is naively (read – most often) used without any performance tuning whatsoever, then its latency can be bad. But if its tuned, it can totally rock (and I know this from MCS colleagues who’ve experienced it in very large BizTalk projects).

BizTalk is big. Yes, totally. But it has to be because it addresses a vast set of use cases. Same goes for its competitors like TIBCO, webMethods etc. If you dont want all the features, dont use them. They are in the box anyway and they wont slow you down if you dont use them. You want content based routing – its in the box; you want long running business processes – check, you want ‘aspect oriented’ interception of messages for tracking , you’ve got BAM. You want monitoring tools – check. You don’t want tracking – turn it off. You dont want business rules – ignore the BRE. The list goes on.

There’s also a case to be made for using something like the ESB toolkit to give you a decent jumpstart on your routing infrastructure.

If you only have a couple of systems to integrate (and you are very sure there wont be more) then go ahead and custom code it. Its not worth buying a product for that.

The problem I have is with some “agilists” who, it would seem, want to custom code every darn thing under the sun. As I commented on Richard’s post, the irony is that the very same folk will then stress the importance of having good, robust pre-built frameworks and good tools to help with the “agile” approach. But wait, those tools have to be on the “acceptable” short list. Take NHibernate for example. An excellent tool, no doubt. And for many folk, since its open source, so it must be sent from above, totally divine, but not BizTalk. That’s way too big. And besides, its from Microsoft. Gasp! horror! It must be evil !!

Some take the view that its about having confidence in your code. I can understand that. Having been exposed to a fair amount of TDD etc, I can attest to the feeling of security when your edge cases have all been tested and you see all those “green signals”. But in an integration scenario where use cases are similar , how many times will you write a test, write the code, refactor, refactor, blah.. till the code comes out of your ears. Pretty soon customers are going to wonder how many times they have to pay for something thats already been written.

If Ican have confidence in code I write, I can have the same amount and more in a product thats been tested out in hundreds of more scenarios than I could imagine. Do these products (such as Biztalk and its competitors – I’m not selling anything here ) have bugs? Well of course they do. But in many cases, you can be just as confident in commercial closed source as in open source. Besides, if pre-built tools werent a good idea, there wouldnt be any open or closed source tools would there?

I’m not partial. Go in for the Neuron ESB if you a want a pure WCF ESB, or go in for something thats gaining a good reputation like NServiceBus. Just don’t give me that story about having to write a 100 tests first and inherit a dozen interfaces before I can deliver anything of value. Bah! Humbug!

Ok, so enough of the rant.. Got to go and write some custom components now 

Speaking at VBUG (Bracknell)

I will be presenting an introductory session to Biztalk 2006 R2 (and spending some time on the WCF adapters) at the local chapter of VBUG in Bracknell. Of course, we will also spend a little while discussing the impact of Oslo and Dublin and the factors to keep in mind when choosing your integration technologies.

Despite the fact that it has been around for ages and has IMO a lot of visibility, it seems that BizTalk Server still remains a sort of niche product with a lot of developers totally unfamiliar with it and what it could give them. The last time I presented on Biztalk,WCF and WF at the VBUG conference  in 2008, we found that a significant number of the audience didn’t know anything at all about BizTalk and from discussing with contacts in other countries as well, it seems that its a familar situation . Well, anyway, I hope I can do something in my own small way towards rectifying that.

So if you’re in the area and Biztalk is unfamiliar territory why not check it out?