SOA using WSSF and WCSF

Topics: Web Client Software Factory
Jun 1, 2007 at 3:12 PM
I'd like to build a small SOA application to get started on this kind of software development. I'm reading a lot about WSSF and it's advantages to help build SOA applications but I don't know what should I use for the front end of the application. I was thinking on WCSF but it uses MVC pattern and I'm going for SOA...should I still use this factory?

Another huge doubt is about Data Acces Layer... should every web service be in a separate WSSF project with its own Data Access or there should be a common Data Access for every web service in a complete diferent dll? or maybe, I should develop all the web services for my application on the same project...(so they will share the same data access layer)

As you can see, I'm very lost with all this and I'll really appreciate some help. Thanks!
Jun 1, 2007 at 3:42 PM
On first part of your question I believe you first read thru "Creating the Reference Implementation using WCSF and WSSF" article, and judge it yourself whether WCSF is good for your requirement. I like the similarity between WCSF and SCCF so you might as well have a look at SCCF.

On Whether there should be a separate WSSF with its own Data Access project, maybe you can work thru the hands on labs which also thaught you how to have Data Access and the Business Logic in the same project. Making Data Access and Business Logic into separate project is a good choice if later you want to write another data access project which calls other type of DB, on the mean time it also makes is easy to manage and debug should your project grows beyong hundreds of files.
Jun 2, 2007 at 1:36 AM
patrick, I am right now downloading the word document called "Creating the Reference Implementation using WCSF and WSSF" to see if I have a better idea on what this framework can help me out. I've read some blog and forums post about WCSF and I get the feeling that it's kind of not mature enogh at the moment. (doesn't support ajax, etc).
But the real problem for me is that I'm not developing big size applications, most of them are just a bunch of CRUDs and some business logic. I thought (since I know almoust nothing about patterns) that using WCSF would help me build better web clients but at a reasonable effort... and maybe using WCSF in my case would be like killing a mosquito with a cannon.

About the other subject, I'm just gettin started on SOA applications and after a while of reading, I feel like I am 2 years old and I'm learning to speak... what I thought was that in SOA applications, every business process should be a web service, but after folowing the WSSF HOL, I got lost on where to put all the Data Access classes.

So, can you please help me here with some hints or advaices on how to get started with a very small SOA application using WSSF... I will really appreciate! because I still don't know if even developing under SOA, the application should be on a MVC/MVP pattern... or if the whole application should have a shared Data Access project opposed to every web service having its own Data Access.

One last doubt (I promise, he), my WSSF project should include all the web services for the complete SOA application? or should I start a new project for every web service? this will help to clear things up on data access doubt too I think.

As you all can see, I'm very much lost here and I welcome every opinion or advise. Thanks!

Santiago Aceñolaza

PS. Sorry for my bad english!
Jun 3, 2007 at 11:19 PM
Just to clarify. SOA is a kind of backend architecture, while MVP purely deals with the client side of thing. So the 2 don't even touch each other. The web client software factory is also great in that it has a framework to handle external services (not necessarly web services or anything, but it definately works wonder with whatever you generate from the WSSF).

For the data access layer, it really depends. The WSSF allows you to define projects with specific roles, and to access the data layer from any project you wish. So you could have it all in 1 project today, split it up tomorrow... if its just for learning purpose, do it in 1 big lump, one WSSF project (which is in itself many smaller ones). It will make more sense once you start using it.
Whats nice with the WCSF, is that you can have more "local" DALs for more client-oriented part of your project, then plug in WSSF for the more complex stuff. Its really nice.
Jun 4, 2007 at 10:11 AM
I think you need to consider the scale of your application and what the purpose of it is. If you are creating an application that needs to communicate across boundaries/companies then an SOA/Web Service application might fit the bill, but if you're creating an internal application to be used within the company then possibly another architecture could be used, such as remote objects, WCF, CSLA etc.

To use a software factory such as WCSF and WSSF it is definitely worthwhile researching the patterns involved and why they are utilised in the factories. When you understand the patterns then you will be able to guage whether you need them or not, or whether you may need them in the future. The Data Access layer in WSSF provides flexibilty to change the underlying datasource. This is a powerful feature in a changing environment, but for a small app that will always use Sql Server then is this data access layer really necessary?

As for MVC, MVP, MVPC - there is a lot of information on these patterns as they have been used for many years. You need to consider whether your presenters are likely to change due to requirement creep and flux, and is unit testing important if you are creating a small application? You need to weigh up the power that these patterns provide against the need to create the additional classes and code. Saying that, if you get into a routine of creating views and controllers then it would be second nature in a week or too. As said previously, these patterns are implemented in the client and are irrespective of the SOA architecture.

How you create the Service application (and it probably does help to think of it as a seperate application) really does depend on the scale and modularity of your application. If you are creating a small application then it may make sense to have all your web methods in one solution. If you can clearly define different modules within your application then it could be worth seperating you web services as such. You may also need to consider your architecture in this case as a shared object library may be required for common objects - something that WSSF does not really cater for.

WSSF creates a fair bit of code for the Data Access layer. If you are creating a single web services solution then this may be fine, but if you're creating a number of web service solutions then it could be worth stripping out all that and using the EntLib Data Access block - this would give you far tidier code and wouldn't sacrifice any flexibility whatsoever.

Finally, do you need to use WSSF? Would it be simpler to create an object library assembly and a Web Services interface? Do you see a need to seperate your business logic from your types and data access? Do you need the recipies to create your code and sql for you, or are you happier coding it yourself and maintaining control over the code? A lot of it is based on opinion. If you look at the code that WSSF creates and you think "wow, that's great" then use it, but if you look at it and think "hmm, I could do that a better way" then maybe you shouldn't be using it.

Hope this helps.
Mar 29, 2008 at 4:46 AM
Using those bloated framework for a small SOA? You got to be kidding. If you are trying to learn those framework, then using them in your small SOA project as a pilot is fine. But for serious small SOA application, you are going to get some big headache in learning curve and maintainability. It's perfectly OK to do asmx and aspx and that will do the job nicely. Don't get trapped in those frameworks and lost sight if what you really want to achieve.

It's insane if you look at how a simple clicking a Edit button got directed and redirected a million times through the view-presenter and controller, any level headed, business oriented people will puke and faint. Mind you, you can't use new to create object, you have to decorate your constructor with CreateNew. What a waste of time. Under P&P, .Net is following the footstep of Java frameworks and frameworks, mind you, pile of useless, pattern chasing and poor performing software; well, well, why don't we just do Java in the first place.