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
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.
As Rocky has not responded yet, let me quote him:
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 .
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:
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. :)
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):
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.
Copyright (c) Marimer LLC