CSLA.NET suitability for a large SOA implementation

CSLA.NET suitability for a large SOA implementation

Old forum URL: forums.lhotka.net/forums/t/4371.aspx


xvm posted on Tuesday, February 19, 2008

Hello,

1) We are evaluating a few frameworks, including CSLA.NET, for a large SOA application (we have to use SOA). My guys really like the smart-business object concept, but one of the downsides seems to be that one needs to be very careful about creating business objects that are too chatty.

To try and overcome this, one guy did a small prototype where CSLA.NET smart business objects where only used behind the service interface (ie. on the application server) and then exposed that functionality through course-grained shape/value objects via the service interface (ie. web services). In that case the web client only uses the course-grained shape/value objects to/from the service interface, and once through the service interface, they would be converted to smart objects using the CSLA.NET functionalty. Although this is a workable solution, I'm not convinced it is the best, since it feels like you double implementing everything in all smart business objects have equivalent (albeit more course-grained) shape/value objects.

I'm wondering whether anyone else has considered the potential for creating smart business objects that may potentially be too chatty? Does it add a lot of overhead to be aware of this all the time and to try and code around that (if possible)? Or are we missing something?

2) My guys also appear to prefer the MS Validation Block (part of the MS enterprise application blocks) to the built-in validation in CSLA. They've found that the error reporting is more consistent in the MS application block (e.g. always creates error messages rather than sometimes creating exceptions). Has anyone used the MS Validation block together with CSLA.NET (thereby ignoring) the built-in validation? Is this a workable solution?

Would appreciate any feedback or experience on the above...

 

vdhant replied on Wednesday, February 20, 2008

imho when it comes to the SOA world vs the objects inside an application world it is kinda like programming in the large vs programming in the small. They deal with two different domains of interest.

I think that when you're creating business objects (and not necessarily CSLA business objects but any object that performs a lot of grunt work/business logic internally within your application) and looking at what objects you will send around the network, I think that these are intrinsically two different things. I personally think it would be a mistake to try and attempt (particularly that you have mentioned that it is a large project) to make use of the exact same objects for both internal (i.e. business objects) and external (i.e. objects sent over the network) use.

I would be much more inclined to design business objects internal within the service with very little regard to the interface that uses it (i.e. the service) and then build the service interface separately. The reason why i say 'Interface' here is because the point that i am getting to is the exact same augment for not putting business logic in you user interface. What you are describing (i.e. trying to come up with an object model that is both course and yet well abstracted and encapsulated) is exactly the same as putting business logic in the user interface except here you are trying to put business login into the service interface. Imagine binding yourself to an object model that matches your user interface…

This becomes extremely important when it comes to interfacing with different systems/services (the same importance that comes when you have the same business objects used by many user interfaces). Imagine for a minute that you have a service that currently talks to one other server. Given this, at the point in time when you created your design, you create an object model that manages to work for both sending data over the network and for internal processing within the server. This might work alright for the short term but what happens when you have another server come online after the initial development is complete, that you may or may not have control of and needs to talk to the original service. In this case one of the services is going to have to conform to the other. Most likely if you don’t control the new service and you are the one needing that service, you will have to create a façade service that sits in front of your original service to do the transaction (or use something like BizTalk). So you have gone to all this effort of trying to create an object model for both internal and external use and you have had to create another service anyway.

There are a lot of other reasons I could go into but smarter minds that mine have covered this territory before and as much work as it may seem to create another layer of objects on top of your business objects in the long run you will far better off. Even from an ongoing maintained point of view if you use the same object model for internal and external and you want to make changes internally as we say in Australia you are up sh** creek without a paddle, versioning has pretty much just become an impossibility (or at least very very difficulty) and again I draw the same parallel to putting you business logic in you UI.

So in short I think that internally having a ‘chatty’ system is fine because it allows for a lot of flexibility (as well as abstraction and encapsulation) when it comes to developing and changing business concepts and logic over time. And for you service interface it is your job (not necessarily yours but who is ever is doing the design/architecture) to create a service interface that provides a coarse grained view and access of the domain you are working with. So I think that the ‘one guy did a small prototype’ is defiantly on the right track.

Next, not that I have had experience with the Validation Block, but the validation in CSLA I believe is quite good. When you have said that the CSLA validation is inconsistent because of the exception throwing, I think it is important to note that this only occurs (as far as I can tell) in the save method. Anywhere else the developer can request the broken rules or check whether it is valid. Now in the save method I believe that the system has to throw an exception is the object has broken rules simply from the point of view that you don’t want to save it if it is not valid but you can’t let the system continue if it simply skips the save when the object is invalid because it wouldn’t know whether the system has saved the object.

For arguments sake thought the one (two if you count the list save in 3.5 and probably the same in 3.0) save method is virtual which means that you can override the save method and deal with an invalid object however you want.

Also f or arguments sake if you did want to plug in the Validation Block, CSLA has enough plug-in points that you should be able to do this without too much trouble and the CSLA validation will simply just not be used.

Hope that has helps and let us know how you get on.
Anthony

tmg4340 replied on Wednesday, February 20, 2008

xvm:

Hello,

1) We are evaluating a few frameworks, including CSLA.NET, for a large SOA application (we have to use SOA). My guys really like the smart-business object concept, but one of the downsides seems to be that one needs to be very careful about creating business objects that are too chatty.

To try and overcome this, one guy did a small prototype where CSLA.NET smart business objects where only used behind the service interface (ie. on the application server) and then exposed that functionality through course-grained shape/value objects via the service interface (ie. web services). In that case the web client only uses the course-grained shape/value objects to/from the service interface, and once through the service interface, they would be converted to smart objects using the CSLA.NET functionalty. Although this is a workable solution, I'm not convinced it is the best, since it feels like you double implementing everything in all smart business objects have equivalent (albeit more course-grained) shape/value objects.

This is the best way to do it - in fact, it's the recommended way to do it in Rocky's books.  For starters, your CSLA business objects are not going to play well with this kind of serialization - complex business objects like this tend not to work well in an XML world.  Secondly, as Anthony has pointed out, you don't want to expose your business objects (and all the associated logic) to external sources.  That severely limits your ability to modify the objects - including the business logic that goes into it - and it puts a requirement on the other end to re-produce the entirety of your business object in order to do anything.

While you can certainly look at it as "double work", you have to consider that the "SOA boundary" is just that - an application boundary.  Using SOA means that you're expecting other sources to use your service.  You neither have control over those sources, nor do you necessarily even know about them.  To push something like the CSLA architecture on them as a requirement of your service could be rather onerous (and probably unusable to non-.NET clients).  For example, while the external sources do need to conform to your business rules, they certainly don't have to conform to the CSLA style of business-rule implementation...

Also remember that your objects in your SOA interface shouldn't be much more than DTO's - you wouldn't build the business logic into your SOA object graph.  If you need the business objects in your web interface, then you use those same CSLA objects in your website via a shared library, and you re-constitute the CSLA objects on both ends from the DTO's.  In this case, you're using your "SOA implementation" as little more than a kind of XML remoting scenario - not what SOA is designed for, fairly cumbersome, and not really recommended, but still doable.  Heck, Rocky provides an XML transport for the DataPortal, just to show that it can be done - and then goes on to say it's not a recommended practice.  It adds a layer of complexity for almost no benefit.

If you're seriously considering using CSLA, we're going to strongly recommend that you buy Rocky's current book (and the subsequent e-books), if you haven't already.  You will gain a lot of insight into the framework from reading the books, and there is an entire chapter devoted to CSLA and web services.  Plus, you'll put some more money in Rocky's pockets.  Smile [:)]  The one caveat is that he's currently working on a .NET 3.5 version of CSLA, which should hopefully be available (along with an updated book) by mid-year.  The 3.5 version deviates rather markedly from the current version of the framework in some key areas, so if you're thinking of going/already have gone to 3.5, you might want to wait.

HTH

- Scott

Copyright (c) Marimer LLC