Hi Rocky
I am new to CSLA. Have seen a few of your videos and read a bit from your book and it's great.
We are developing a business application where we would like our business logic to be behind a WCF layer. This will be consumed by a silverlight client but in future will have more clients like a mobile one, web clients for some specialized functionality. Also in future we intend to expose a public API facade from our WCF layer.
We would like to use CSLA in our Silverlight client. An initial study shows me that the facade has to have 5 methods that are Create(), Fetch(), Update(), Delete(), Execute(). There is a routing mechanism in place which routes to the correct BusinessObject on the server based on some parameters behind the scenes in a default WCFPortal implementation.
Questions are
1)To communicate with a CSLA service, should all our clients need to be built up on CSLA ?
2)We would like to expose business operations through our WCF facade layer which behind the scenes do insert, update, delete based on some business logic rather than just the Create,Fetch, Update and Delete operations. Most importantly for the public API we must expose more meaningful business methods. Is it possible with CSLA not to be restricted to Create, fetch, update, delete, execute methods and define our own facade layer ?
3) Is it possible that our Service (.svc files) be hosted in a separate application rather than in the web application where the silverlight application is hosted ?
The intention is just to achieve loose coupling as most of the business applications do.
- A service that talks on standards such as Http & SOAP and exposes a proper business layer as facades.
- Any type of client should be able to consume the service to extend the functionality..
I will be really grateful if you can take out some of your precious time to post a reply.
CSLA supports two basic models for distributed apps:
Either way you use the data portal, but in different ways. And the core architecture of your system is different. I use the word system, not application, because in the loosely coupled SOA model you have multiple applications by definition - so we have to talk about it as a system.
I've blogged about this a lot - select the "Service-oriented" tag at http://www.lhotka.net/weblog to see those posts.
In short though.
If you want to exploit the productivity and automation provided by the mobile object architecture, you should look at using CSLA on your client and server and communicating via the data portal. This is an n-tier architecture and is not loosely coupled - which is why it is so productive, feature-rich, and relatively low-cost.
This is NOT a good architecture for a WP7 or other mobile app though, because you have such limited control over when, or if, the user updates the client. It is a great architecture for ASP.NET apps, WPF apps, Silverlight apps, or Windows Forms apps - because in those technologies you can have total control over client updates, thereby ensuring they stay in sync with your server.
If you are building a mobile client, or want to support unknown clients by exposing a service interface, then you should do just that: expose a service interface. That means being service-oriented, and that's more complex and expensive. By definition, you are now creating an application that has a "UI" composed of XML or JSON message contracts.
Conceptually you can think of a service interface as being just like a web interface, except you send and consume XML/JSON instead of HTML. In fact that's a healthy way to think about it.
Do you trust a web client? No? Of course not - you validate, verify, and recheck anything you get in a web postback.
The exact same paranoia is required when implementing a service interface.
The primary difference is conceptual - with a service interface the service is a standalone app. It is not a tier. It is not in any way part of the consuming app, nor is the consuming app in any way part of the service. They must be viewed as separate apps.
Given all that, you should understand that CSLA can be used to create the consuming app, or the service, or both. But even if you use CSLA to create both - you should never think about sharing code. As soon as the two apps share code, they are tightly coupled and you are no longer SOA. Period, end of story.
For my part, I'd probably build the Silverlight app as an n-tier app, using the data portal to communicate between the application code running on the Silverlight client and the application code running on my app server - all one app, but with multiple tiers.
And I'd probably use those same objects to build a service interface (SOAP or REST). I already have the objects, they are already running in my server environment, so if possible I'd reuse them.
Then I'd create a totally separate app for the mobile device. Let's say it is WP7. I might use CSLA to build that client app too - but it would be a 1-tier app that calls the services running on my server. This mobile app is sometimes called an "edge app" because it runs on the edge of my service-oriented system.
The formal and unchanging service contract provides the loose coupling, allowing the Silverlight app and server objects to change over time, without changing the service interface. Changing the service interface is a big deal, because it breaks the contract with all service consumers - so you have to have a careful and clear versioning and migration story for that (part of why SOA is not cheap).
If you've been around long enough, you might remember how VB6 worked with COM interfaces and "binary compatibilty". Those exact same versioning rules apply to SOAP services, and similar rules apply to REST services. If you didn't do VB6/COM work, I'm not aware of another really good analogy (I should probably work on one - as time goes by fewer and fewer people have that experience).
In terms of reference material.
The Using CSLA 4: Data Portal Configuration ebook I'm currently writing covers the n-tier scenario quite thoroughly, including sample code with a Silverlight client.
The most current information about building service interfaces with CSLA objects is Chapter 21 of Expert 2008 Business Objects.
Hi Rocky
Thanks a lot for a quick response and for taking out the time to write a detailed explanation. It pretty much addresses most of my questions. Not only that it provides guidelines to help selecting way forward.
We will give more thought into this before deciding on an approach. I will post more when I have more queries. Thanks again.
Regards,
Irfan
Hi Rocky
Sorry. Just another question. I am a bit unclear on the Data Portal concept. As I understand is,
- DataPortal is something like a service (e.g. CSLA's WcfDataPortal) is this correct?
- What is the difference between a local and remote data portal? Is it that the local dataportal resides in the same app domain as the consuming application? If yes then how does SOA come into play with a local data portal?
These questions may sound completely basic but as I said, I am new to CSLA.
Irfan
You may consider getting the Using CSLA 4 ebook series, or at least the Using CSLA 4: CSLA .NET Overview book - it is hard to replace that information via forum threads.
The data portal itself uses a set of design patterns and technologies to abstract the communication between client and server, and to enable the mobile object concept in CSLA.
In local mode the data portal runs the client-side and "server-side" code all on the client.
In remote mode the data portal's client-side code invokes the server-side code on a server. The communication is handled by something called a data portal channel. Channels loaded using a provider pattern, and CSLA comes with WCF, Remoting, and Enterprise Services channels. You can create your own as well - but usually the WCF channel works well.
The data portal itself is service-oriented, but it provides n-tier functionality to the application. This is because the mobile object architecture is an n-tier architecture and so is not service-oriented.
The Using CSLA 4: Data Portal Configuration ebook I'm working on right now (chapters 1-3 are online, 4-5 yet to go) provides a lot of detail about what I'm describing here.
Thanks again Rocky. We might consider getting these books now or might be as a final version is available. I already have an older version of the book and am refering to that for concepts. Thanks again for the assistance.
Hi Rocky!
We are at the beginning to develop an application. Right from the start we have to make architectural decisions. First we want to build a web application followed by other UI technologies (Windows and/or Outlook AddIn). As soon as the web app is done, other 3rd party applications (devloped by ourselves) should consume the new application, mostly read operations. Some of my co-workers have the idea to build a webservice, and right on top the different UIs. The webservice will be also consumed by the 3rd party applications.
I am against this idea because we have to expose all the buisness behaviour through the webservice. That means that the 3rd party applications can access for example the write operations which should be allowed for the application's UIs only.
My colleagues argue that there should be one central application (bussiness tier) for all the UIs. In my opinion we have to build two webservices, one full blown for the UIs and another light webservice for the 3rd party applications.
A second idea is to write a n-tier application like you have suggested above. I understand a n-tier app as one application with one UI. Technically it is possible to implement an n-tier application (WcfPortal) with multiple UIs. I don't know if this is a good idea. One question I have is versioning. What happens if one UI is up to date and another has an old behaviour (maybe a business object with a missing new property).
My preferred way is to build seperate 2-tier applications for each UI. Each of the applications talk directly to the database through the BLL and DAL.
What would you suggest to do? Maybe Irfan can share his experience with his application, too, if he reads this post.
Yavuz
Copyright (c) Marimer LLC