Web Services Software Factory, the solution to all our problems?

I just came back from a seminar on Web Service Software Factory (hereby referenced as WSSF), and I just cannot resit the urge to share my feelings on the subject.

The presenter introduced WSSF as the solution to a lot of problems; Straggly Code Base since each dev/architect has his/her own way of building a service, Varying Quality Levels depending on who did what and Bad Productivity caused by lack of re-use of both code and knowledge. Let’s see (from my point of view) what the current version of WSSF offers when it comes to reducing these problems. Now, this is going to look very critical and you might even think that I don’t appreciate the efforts of the PAG team. I assure you that I do. I’m just saying that the Service Factory as it is today doesn’t live up to the promises this particular presenter made.

Straggly Code Base*

I think this is a serious problem with very few (if any) good solutions, and the WSSF in its current state certainly isn’t one of them. The underlying problem is, of course, that our development platforms constantly evolve (to the better). This means that every time we start building a new service there will be some new feature, technology, utility class library or toolkit that we really should take advantage of in order to build a better service quicker. The WSSF is simply one of these. Since its built by the PAG-team, it isn’t even supported and will most likely be evolved without much compatibility. The recent release of the WCF version made this clearer than ever. I sort of expected the ASMX->WCF migration to be easily integrated, but no such luck. The WCF Service Factory is clearly separated from the ASMX Service Factory. You decide which one to use and then you’re stuck with it (unless you go through the gruelling 8 step process involving a lot of copy-paste and manual modifications).

Getting to the point I wanted to make. WSSF might make it easier to build the service you’re building today, but I doubt you will use it five years from now. In fact, I’d bet that five years from now someone will look at your service and say “Wow, the data access component in this thing is really difficult to follow. Was there some kind of tool used to generate it?”

Varying Quality Levels

Let’s not kid ourselves here. A bad developer will always create bad code, no matter what tool he/she uses. In fact, if you don’t understand why services built using WSSF are layered like they are or why it is good practice to do Contract First development, then you are bound to make mistakes. So what you’ll end up with is a service that looks like it follows good design practices, but in fact is just as messy as anything else.

Bad Productivity

The biggest problem with the current WSSF offering (in my opinion) is that all recipes are one-time wizards without knowledge of the current code. Whenever you want to make a change to the generated code, you’ll either have to do it manually or you’ll have to run the recipe from scratch again. This may be fine when dealing with the simpler tasks such as adding a new property to a data type. But when you’re dealing with the Data Access classes it quickly gets complicated. I really really hope that the PAG team are working on more Domain Specific Language-like plugins instead. In fact, I think that a good DSL that could help us with mapping data types from the Business Entities to the Service Contract would increase productivity much more than the entire WSSF.

Conclusion.. or something like that..

I strongly believe that in an enterprise that wishes to keep its IT systems reasonably current and its IT department happy, you’ll have to deal with the fact that your code base won’t be a haven of conformity. If you have some junior developers you don’t just hand them a guidance package and say “Follow this and everything will be fine”, you make sure to review their code and you make sure they have a good mentor. If you suffer from bad productivity there are probably many, many things you can do to optimize the way you work (and yes, a tool or two can help – at least to a point). An example of a real productivity booster is another (much more mature) offering from the PAG-team, the Enterprise Library!

When it comes to WSSF I think the PAG team have made a very good effort but I’m sure that they too realize that this technology (Software Factories) is still at a very early stage. It is absolutely a step in the right direction and I’m really looking forward to getting my hands on the next release and the ones after that. Adding some visual DSL tools and getting rid of many of the wizards would make the WSSF extremely interesting.

Please let me know what You think! Have you successfully used the current WSSF and built a better service faster because of it (and will you use it the same way next time)? I’d love to be wrong on this one!

* Straggly Code Base
Is there a better word than Straggly (it’s a direct translation of the Swedish word “Spretig”)? What I mean is when each service is built differently from the last one; maybe it’s layered differently, maybe the naming convention changes or maybe a new Visual Studio extension is used to generate the contract.

4 responses to “Web Services Software Factory, the solution to all our problems?”

  1. Interesting comments. Im just starting out with WSSF. I have downloaded the bits and watched the videos but never got round to building anything yet. In terms of handling changing existing code though, maybe V3 will help? theres a bit more support for preserving the model. In terms of the data access though, they are using entlib under the covers and a standard repository pattern anyway so that should be easy enough to understand if you know the pattern. I think this is a general problem with the huge codebases generated by any OR mapping or other codegen tools (ie) just diving into the code is impossible – you have to understand at a higher level whats going on and then try to debug – so theres now more stress on keeping the core changeable code in the business layer and leaving the DAL to be just plumbng. this way if a new LINQ based DAL will be half the size of the current one, we could rip and replace. Its not going to be all that clean to do it with stuff in production, but maybe one day the tooling will allow us to do this. I also think that the reason theres so much clicking and wizards involved is precisely because they dont want to be a one click code gen tool.. a factory should provide in context guidance and keep you focussed on what you do, not do everything for you …

    my two cents worth..


  2. My experience with the Web Service factory (or more accurately responses from people TO the factory) is as follows:

    Enterprise Architects relate (falsely) the Wizard/Recipe nature of the factory to magically producing a useful Service – in reality the devil is in the details.
    Developers consider it ‘to complicated’ and opt for a more simple approach without all the different layers and additional Request/Response classes.
    Developers consider it ‘to time consuming’ and opt for a faster approach whereby a ‘working’ service can be built more readily.

    The complication/productivity issue is analogous to justifications for not performing unit testing – the perception of productivity in the short term is considered more important than long term loss of productivity. I recall a project I worked on whereby when I inquired why unit tests were not being written, the response was “We don’t have time for that”. Sometime later the project was repeatedly delayed predominately due to the number and severity of bugs and design issues as a result of the “we don’t have enough time for that” ethos.

    I don’t agree with the aforementioned justifications – it is simply what I have experienced in the ‘real world’.


  3. You may take a look at the latest WSSF V3 Modeling Edition with full DSL support. I think that many of the caveats mentioned above will be no more valid.


  4. Well…Having used the WSSF ( which at this point hasn’t been updated in 22 months, really, if you go by stable releases ), I can say that I have to agree with Anders. Honestly, I can across this article out of SHEER LUCK, but I can’t find any fault in his reasoning, and the points he’s bringing out are still just as relevant, still just as timely as when he first made them.

    Yes, the WSSF Modeling Edition is MORE declarative. But you still have to do so much gluing of things together. For instance. If you generat your business entities using the Repository Factory ( also available on CodePlex ), you can’t drag them into the designer surface as say “here’s the class I want the DataContract modeled after. Interoperability like THAT is what some of the stuff from the P&P group from MS needs to work out.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

About Me

Consultant, Solution Architect, Developer.

Do note that this blog is very, very old. Please consider that before you follow any of the advice in here!


%d bloggers like this: