Architecture Question

Architecture Question

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


bcrowell posted on Monday, February 23, 2009

I'm building a CSLA app that has two parts:

1) An app that builds a large pool of user objects and configures them using some intensive data mining processes. This pool sits on a server and is constantly being recycled and rebuilt.

2) A web application which, upon a session start, goes to app #1 and asks to retrieve the appropriate user with all of the details intact. I'd like to just bring over the complete csla user business object. From that point, I'd like the object to be able to talk to the database in (local) mode without going back to the server were app #1 is hosted.

The idea here is maximum performance on all counts but I can't seem to get my head around what the architecture should look like both from a wcf vs. remoting vs. SOA standapoint and also, even more relevant, from a csla dataportal setup perspective. Any help would be very much appreciated. Thanks much.

Byron Crowell

SonOfPirate replied on Wednesday, February 25, 2009

I would certainly provide a WCF interface for app #1.  This will allow inter-app communication such as you describe for app #2.

As for the web app, will you always be retrieving the user information from app #1?  If so, then the operations you'll be doing with the database are limited to Update and Delete, yes?  If this is the case, then you can follow the standard approach for the data portal with one exception: in your DataPortal_Fetch method, you'll call the appropriate service method on app #1 instead of going to the database.

Something else to consider is that you clearly have different use cases for your applications even though they both may be working with the same logical data.  As such, I wouldn't try to share business objects per se.  You should use a Data Transfer Object (DTO) with your WCF interface.  Then, in app #2, when you call app #1 to retrieve the user information, you can map the DTO's properties into your business object as demonstrated in the Project Tracker sample application.

Hope that helps.

 

bcrowell replied on Thursday, February 26, 2009

Thanks for the feedback. I'd like app #2 to be able to fetch data as well under certain edge case scenarios. I like your DTO idea although it does complicate matters to some degree. Given this new information (fetching from App #2) do you have any other thoughts?

This is really helpful. Thank you.

Byron

RockfordLhotka replied on Sunday, March 01, 2009

In broad terms, I differentiate very clearly between inter- and intra-app communication.

This means the definition of "app" or "application" is important. I've blogged about this sort of thing quite a bit:

http://www.lhotka.net/weblog/CategoryView,category,Service-Oriented.aspx

Intra-app communication means the layers of your application are communicating with each other. Sometimes those layers may be deployed to different tiers, so the communication crosses process or network boundaries, but it is still communication between layers of your application.

The data portal is designed to enable flexible communication between instances of your business layer, and so is totally designed for this intra-app scenario. It should never be used between applications, only within an application.

Inter-app communication means two or more applications are communicating with each other. In SOA terms this means you are creating a "system" composed of two or more "applications".Almost certainly one of the applications is an "edge application" that is designed to interact with a human.

Inter-app communication is best implemented through a contract-based message passing mechanism. These days that typically means sending XML messages between apps, often over HTTP, using some technology like WCF.

From a CSLA perspective, inter-app communication fits into the n-layer architecture in two places.

If your CSLA app is consuming (calling) services, then the services should be treated just like stored procedures. In other words, your data access layer should invoke the services.

If your CSLA app is providing (exposing) services, then the services should be treated just like an interface. In other words, the XML messages are no different than the HTML that goes to/from a browser, and your service code should be (in concept) the same as the code behind a web page.

Either way, the XML messages are usually transformed into data transfer objects (DTOs) automatically by WCF (or asmx), so you never really interact with the XML itself. Instead your data access or interface control layers interact with these DTOs, and with your business objects.

bcrowell replied on Monday, March 02, 2009

Thanks Rocky,

That podcast was perfect and i recommend it to anyone who's reading this. So I'm building an SOA-based service running on a server over SOAP since that's what Visual Studio really supports well. Then the web client is a stand-alone app that subscribes to that service for some of it functionality. Got it. Many Thanks again.

Byron

bcrowell replied on Saturday, February 28, 2009

Does anyone else have anything to add to my post here? I'm still at a loss on how to set up wcf, and the dataportal for access from both an application server and a client web server. Thanks.

Byron

Copyright (c) Marimer LLC