WSSF Woes

Topics: General Discussion Forum
Jun 4, 2007 at 1:04 PM
I have a number of woes about WSSF (and SOA as a whole), and would really appreciate other peoples opinions.

It would also be useful if I summarised my situation:

I am a Windows based OO developer and use a lot of ORM and SRP techniques, and for a number of years now I've been using Rocky Lhotka's remote business object framework CSLA. With this framework I would normally create a set of business object libraries to include all validation, logic, data access, and such. Most of the power of this framework is that the objects can be remoted back and forth between the client and server allowing for validation, dirty data, and object state to be used efficiently without duplication of code. The remoting can be hosted in IIS, or if Web Services are required then this is trivial to implement. I see many benefits to this architecture and have created a number of large applications that have used CSLA that have been very successful.

In January I started a contract in a small team on a greenfield application. The team has come from a C++ background with little knowledge of .NET, software architecture, or design patterns. The application is a back office and will only be used internally to the company. I envisioned a nice tidy smart client application based on a good object library preferably using a framework such as CSLA and CAB, but the team were all keen to do a website to mimic a windows application despite a severe lack of ASP.NET experience. This is something I tried to dispute against but failed miserably. The team have also had a lot of involvement with Microsoft who had worked around SOA using WSSF, so the team embarked upon this architecture. I did question why you would need a web service architecture for an internal application, but what the lead developer and project manager interpret as "the Microsoft way" is the only way in their eyes. So this is how it all started.

I had a look at WSSF earlier on in the year and had a few queries:

1) Validation. You need your web services to be robust so naturally need validation within the services. On the client I would imagine you would also need similar validation either in Javascript for browser validation, or on the webserver before you call the web services. I really do not like this as it means duplicating code over multiple layers, probably by different people in different ways, and what happens if the requirements change and only get implemented in one layer such as the services? Surely this is a sure fire way into code deterioration and tricky maintenance. With a framework such as CSLA the object handles it's own validation and will get used at both the client and server, which to me is ideal. If absolutely necessary then some javascript validation may be required. There are of course other similar issues other than validation.

2) WSSF creates a lot of code spread across a number of different projects. Our team lead knocked up a very small part of the functionality and managed to create approximately 70 classes and a whole host of stored procedures - just for a single web page!! He loved it, I wasn't impressed. I stripped out all the data access code and swapped it for the Data Access block which I modified for MySql. This reduced the data access project to two classes instead of about 35. My biggest woe (and this really is down to opinion) is from having all the seperate projects for business entities (may as well be structs), business logic, data access, data types etc etc. Most of the classes therein contain a single line of code, such as the business logic class will call the data access code and pass back what gets returned. I can see why they have done this, but I often wonder if there really is any need. Surely for a maintenance perspective it would be easier to create an object library and then wrap it with a web service layer. I can envision in a few months a plethora of projects and a logistical debugging nightmare.

I did try and air my concerns at the start of the project but they were adament it was the best way of working. I then went off for three months to fix their legacy C++ code.

Come early April the Project Manager sent an email out to the team expressing his disgust that after three months development there really was nothing to show except for a mess of code, a hacked up web page or two, and a lot of confusion. Many days had been spent by one developer attempting to learn ASP.NET and all it's quirks, and the lead developer had spawned a mass of irrelevant database tables and a few monolithic web services. Due to constantly changing requirements, the team had been going around in circles and trying to hack in changes to the messy code. I've seen code deterioration happen in a lot of development teams, but never to this scale. The Project Manager asked the tea, for their opinions and suggestions so I tried to re-iterate my earlier concerns that had obviously come to fruition. The company also bought in another contractor who was shocked at the mess. We both suggested at least creating a proper object library, but were given responses such as "It's not the Microsoft way" or "It's not the SOA way". I don't know how to fight that kind of statement. They bought in the Microsoft guy once more and spent a week in meetings, only to come out with an idea to properly design an object library.

They also bought us in to tell us the solution they had devised to save the project - pretty much the same method as they'd been hacking out for four months, but with some thought on object design. After a day of training on Use Cases and object design they are adament they know enough to do it all themselves without really involving people like myself who have been doing it for years. The plan is to still use the software factory and still create all the various projects that go with it. Web Services will call web services, and common objects will get implemented over and over again in different service applications "just to make them atomic".

My belief is that WSSF is fine in certain scenarios depending on what you need it for and how you interpret it. I do find it produces a lot of code that is unnecesary in a number of environments. I'm not saying that the WSSF team have done it in the wrong way, I'm just saying that some thought is required to understand if those practices are applicable for your development. For our architecture we will have a number of modules, each with it's own web service solution. WSSF has some shortfalls with this type of implementation where we need to share a lot of common objects. Additionally we should have no real need for data types if we were to create an object model using SRP and behavioural modelling. I think it's important to understand the whys and hows of the software factory, but I personally believe it code be coded in a far better way for our development.

Any generic thoughts would be useful. I'm sorry if this post has been a bit of a rant, but I do feel we have been going around in circles and there's nothing I can do about it except rant on a forum.

I guess at the heart of it I'm really looking for some justification so that I can get on with this project without having all the gripes.