MockingBird v1 RTM

MockingBird v1 is now formally released. With the squeeze in available time for personal projects, it’s taken me nearly 6 months since the beta and only recently did the site see any check-ins. There’s quite a few updates, and enhancements to the suite. Actually the beta was pretty stable with hardly any bugs that needed to be fixed but there were a few feature requests and to be honest, I started getting rather impatient to move to WCF but needed to formalize the v1 release first. Here’s a laundry list of all the features of the new release. The documentation, included with the package has also been substantially updated.

This release will be the last to support the ASP.NET HttpHandler. V2 will be completely revised to support WCF. The change in the engine should be transparent to the end user and of course with WCF we will get a lot more benefits including transport independent request interception. It will also be the last to support an independent “Studio” module as I have some plans for a brand new UI

Simulator functionality changes

· Now supports Enterprise Library logging as well as log4net

· Logging all request and response operations.

· Support for "mapped soap Actions" (when soapActions do not correspond one to one with operation names or when the default parsing of  soap actions cannot be done)

· Supports mapping of operations to request element root names (when soap actions are all the same, such as in Apache Axis web services)

Simulator Packaging changes

· Config for unity and services now externalized

· MockingBird system config now externalized

Simulator Internal changes

· System Configuration Manager abstraction layer for config data storage

· StrongTyped application configuration.

· New OperationNameInferenceEngine

· Support for tokens and token expansion in configuration settings.

Studio Fixes

· Disabling of context menu on all nodes except for message level nodes.

· WSDL Browser "Save As " dialog now supports proper file masks (also takes in the service name and suggests the name for the file)

· No unhandled exceptions in the studio.

· Auto resize of all controls on form size change.

XmlInstanceGenerator Functionality

· Additional entry points to the XIG.

A big thank you to all who sent comments and gave me feedback. I hope you find the updates in this release to be useful.

V2 is going to be really big, so watch this space.

For v2, There are a number of work items published on the CodePlex space  so please weigh in on them and vote for the ones that will be most useful to you and also please feel free to send me suggestions for other features as well as bug reports.

WSCF.blue – Paste-As-Schema

WSCF.blue now has a new feature called “Paste-As-Schema” (which takes inspiration from the REST starter kit’s Paste-As-Type). Alex explains the new feature in detail in his post.

The MSI has now been updated to version 1.0.4. It is still formally in Beta-2. It also includes a few bug fixes in the original Beta-2 (1.0.3) release. Please check the CodePlex workspace for details. Hope you find the new feature useful. If you run into any issues do let us know.

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 

MockingBird@SBUG

The UK SOA BPM User Group (SBUG) is holding a series of mini-meetings over the next few months. These are short live meetings / webcasts. I’m delighted to be presenting my web-service mocking tool , MockingBird at the next mini-meeting to be held on the 29th July.

I will be discussing how MockingBird assists and simplifies integration testing with web services, how it is used in Biztalk and non Biztalk scenarios, how the system works, how it can be extended and the roadmap.

Please check the event link on the SBUG site for details.  All are welcome to join (no membership needed). Hope to see a good turnout

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.

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.

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 

BSF meets Deployment Framework

This post is just to call out some work that Bram Veldhoen has done in linking the Biztalk Software Factory to the venerable Deployment Framework. One thing to note is that the integration was done to the NAnt version of the framework prior to the latest MSBuild version of the framework (5.x). I guess linking into the new MSBUILD version is next on the cards and I’ve chatted to Bram about the possibility of doing something jointly (as if i didnt have enough irons in the fire with MockingBird and BizUnitExtensions ). Check it out and post feedback on the BSF codeplex space.