4

I'm at a customer where I successfully developed and deployed a WCF service layer (compiled against .NET 4.5). It works perfectly and everything is dandy.

However, we just got an additional requirement - I'm supposed to rebuild (or at least redesign) the layer to incorporate WSSF. There's no old functionality that we'd need to integrate with and all operations in the services are based on executing SPs in a DB.

Should I do that or is it wiser to argue against it? I'm not certain because I've never worked using WSSF and I got virtually no explanation as to why we should at this particular workplace (which could be that they don't want us to know as well as that simply don't know themselves).

My worries are based on, but not limited to, the following.

  1. The latest release is from August 2010.
  2. There's nothing listed in documentation section.
  3. The license seems to be in conflict with commercial activities.
  4. WSSF isn't widely used as technology today (or is it?!).
  5. The purpose of WSSF is to WCF-fy old service layer (or isn't it?!) only.

Especially #4 and #5 are not the strongest statements in my arsenal at the moment so I'll gladly stand corrected, should anybody have a few wise words to contribute with on the subject.

Konrad Viltersten
  • 36,151
  • 76
  • 250
  • 438

2 Answers2

1

WSSF was a tool that incorporated best-practices for building WCF services. It's been years since I've used it, but basically I recall a wizard that asked several (actually lots of) questions about the service (contract), data (model), etc. What it would produce is a nicely organized solution with several projects with proper naming conventions, verbose declarations like adding IsOneWay=true/false to [OperationBehavior]'s or IsRequired=true/false, Order=n, etc. to [DataContract]. In other words, it generated very verbose code that most of us blow off until we need it.

It did more though, such as structuring your solution so that service contracts were in one project, data contracts in another, and implementation in yet another. It created test projects (I believe). so, very granular layout of the solution. I remember the simplest of services would result in about 6-7 projects in the solution. It was a little intimidating at first until you poked through the code it generated.

Another cool feature it had (at the time many were asking for) was a way to do contract first development. Given an existing web service metadata, you could constuct a new service solution.

Anyway, once it was completed, you just had to do essentially provide implementation for the methods. Personally, I never really embraced it for services development. But, at the time, I appreciated it and often referred customers to it who were new to services development because I knew it would get them off to a proper start.

To comment on your worries though...

  1. That's correct, and it is not getting any resources to update it.
  2. Actually, there is quite a bit of documentation. Just move over to the Home tab and you will see links to it.
  3. Not sure about this. The code it generates is yours. You still have to compile it and it's yours to maintain going forward. No different than any other code-generation tool (as far as I know).
  4. Nope, it is not. Also, consider the time when this was developed, .NET Framework 2 - 3.x. There's been a lot added to WCF since then. There's also been some new guidance on service development. If you're using some of the newer features added in .NET Framework 3.5SP and beyond (which you probably are), then this definitely is not something I would recommend using.
  5. Again, that was one of the nice features (contract first development). But, that really wasn't the main idea. It was a tool to build out the framework for new services too. In fact, new service development was the original motivation of the tool as I recall. Once you took the time to go through the dialogs, you had a really nice solution to start building on.
Rick Rainey
  • 11,096
  • 4
  • 30
  • 48
  • As for #5 - I'm not sure if I'd call it a nice solution. The code I've seen **around here** created by WSSF is dreafully painful to look at and the taxonomy makes me want to go blind. Is that a "local" feature around here? – Konrad Viltersten Aug 20 '13 at 10:21
1

Short story is that it doesn't look good. From MSDN: Web Service Software Factory 2010:

The Web Service Software Factory is now maintained by the community and can be found on the Service Factory site. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. Retired: November 2011

1) So, it looks like it's totally being run by the community. However, looking at the discussion forum there aren't many postings and quite a few have no responses.

2) I find it's fairly common for the documentation tab to be empty at codeplex but there is frequently documentation but not on the documentation tab.

3) In terms of licensing Ms-PL is quite permissive so I wouldn't imagine there would be any issues.

4) Not to belittle it but I don't think it was/is very popular. Definitely not a standard.

5) The intent of the service factory was to provide guidance -- both written and code based. See Web Service Software Factory for a discussion.

Randy Levy
  • 22,566
  • 4
  • 68
  • 94