SOA and CSLA

ljon posted on Monday, May 22, 2006

I am new to CSLA and I am wondering how does CSLA fit in with SOA? Is the DataPortal SOA.? The company I work for is in the process of converting our current application to .NET and have contracted an consultant that has proposed an SOA approach that includes Web Services for the DataAccess and Business logic tiers and claims the CSLA is not compatible with SOA.  

Thanks

ajj3085 replied on Monday, May 22, 2006

SOA would be another consumer or 'UI' of the business layer.


The dataportal is just a way to move business objects from a client to a server to continue running.

You may want to do this, for example, so that your business logic runs on a webserver, then when the BO needs to save, the dataportal would send the object to an application server behind the firewall which is where the data access code would run.

HTH
Andy

guyroch replied on Monday, May 22, 2006

I agree with ajj3085.  If the consultant says that CSLA is not compatible with SAO, then he his saying so blindly, without knowing what CSLA is all about.  He is in for the money.

ljon replied on Monday, May 22, 2006

Thanks, I have read alot of material since I posted this question and think the SOA proposed to us by this consultant is not the best  use of SO. I don't think it should be used as an n-tier in the application. Thoughts?

If I do have a true SO service that I need to use would I utilize the DataPortal to call it? Hows does CSLA work with SOA?

Thanks again.

Igor replied on Monday, May 22, 2006

As Rocky has not responded yet, let me quote him:

• "SOA is not useful INSIDE applications. It is only useful BETWEEN applications. If you think you can replace your TIERS with SOA concepts, you are already in deep trouble"
• "SOA is an idea philosophy and concept to help cross trust boundaries. If you don't cross a trust boundary, you don't want SOA in there causing complexity"
• "In the end, I think the trust boundary mindset is most valuable guide for SOA. Using SOA is expensive (in terms of complexity and performance). It is not a price you should be willing to pay to have your UI talk to a middle tier. There are far simpler, cheaper and faster philosophies, concepts and technologies available for such interaction"

The quotations are from http://www.searchcsla.com/Details.aspx?msn_id=8081 . See more here: http://www.lhotka.net/Articles.aspx?id=40048e03-6f9e-44a4-8322-80cb5de8303a (read #13) and even more here:   http://www.lhotka.net/WeBlog/SearchView.aspx?q=soa .

Hope the quotations are correct, and sorry if not: I collected them "for internal purposes only" some time ago when we had a similar discussion in my organisation; please verify using the original sources.

 

jimkcx replied on Monday, May 22, 2006

I agree with the other responses. I would suggest that your consultant define "SOA". It seems to me that you could break the issue down as follows:

1. CSLA is compatible with SOA and the consultant doesn't know CSLA.
2. CSLA is compatible with SOA and the consultant doesn't know SOA.
3. CSLA is compatible with SOA and the consultant doesn't know CSLA or SOA.
4. CSLA is compatible with SOA and the consultant knows it or doesn't care, but is eager to sell services/technologies/architectures he/she knows.
5. CSLA is not compatible with SOA.

I suspect that it's a combination of 1 through 4. I would argue that CSLA in many ways epitomizes key SOA concepts. I'll stop short of asserting that CSLA "is" SOA because then someone will challenge me to define SOA. :)

RockfordLhotka replied on Tuesday, May 23, 2006

Those sound like my quotes

I would not personally characterize the data portal as a service-oriented construct. It enables a mobile objects, which is in many ways the opposite of the SO world-view that treasures mobile data above all else.

The key thing, to me, is that SO is a great thing, but it doesn't replace existing technologies (like n-tier client/server). Instead of replacing them, SO augments them by adding a new way to tackle some historically tough issues around inter-application communication and integration.

In that light, CSLA is totally complimentary to SO.

It is very valuable to consider that a "service" is a procedure that fulfills some specific business requirement. You can view a service as an implementation of a use case, and in that case it makes all the sense in the world to implement services in an OO manner. Sure the interface to the service is procedural, but the implementation of a service can be pure OO. Because a service is non-interactive, you can implement the most pure OO models inside a service, where behind the UI or in other environments we almost always have to compromise the OO models to accomodate the need for interactivity.

btw, real service-orientation is (at a minimum):

1. Message-based (method signature is always result=service(request))
2. Not point-to-point (client doesn't directly call server, but rather goes through intermediary)
3. Loosely coupled (you can version the client or server independantly of each other - in theory at least)
4. A way to cross a trust boundary (client assumes server is broken, server assumes client is broken - there's no trust between them and thus at least all validation logic is duplicated)
5. Share contract only (no sharing of code, components, assemblies, databases or anything except the contract (API and message schemas) are ever shared between client and server)

In short, web services do not an SOA make - you need message-based contracts in your API, and your client needs to be independant from the server - which typically means using a message bus or orchestration engine (like biztalk) between the client and server.

What most people seem to think is SOA is actually just MTS/COM+ being done with XML. Most "SOA" solutions involve creating a set of services on the server that look and work just like the "services" we created in MTS/COM+ for the past decade. And they involve a client making synchronous calls to that API in the same way we called MTS/COM+ server components way back in VB5.

That's not SOA - that's just client/server done with inferior technology. But since Web Services are used, it is "service-oriented". A cute play on words to get higher rates and/or sell overpriced product.

Again in short, it is not possible to use SOA to communicate between tiers. If you are doing that you are doing client/server. SOA is used to communicate between independant applications. So to adapt a client/server app to SOA means each tier becomes an entirely separate app that communicates with other apps through messages. A very different approach, and one that, frankly, is overly complex for many scenarios where client/server works extremely well.