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.
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.
Copyright (c) Marimer LLC