I want to setup a "chain" for a business application model and this is what I envision:

> TCPchannel or named pipe >
DataLayer Service
> TCP channel or named pipe >
Business Object Service (Using Business Object library)
> TCP Channel or named pipe >
Business Presentation Service (Using Presentation Library & Business Object Library)
> wsHttpBinding with two channels > Certificates only (intranet/ VPN) & server certificate with UserName (typical web access) >
Web Hosted Client and Winforms Client (Using presentation library)

Essentially, I have a third-party ORM that works very nicely to create the data layer from my classes without having to manually create any SQL or Stored procedures (the CRUD operations are abstracted to a single interface which performs nicely).

The Business Object Service is essentially a library of DTO (Data Transfer Objects) implementing proper interfaces for Data Contracts and Service Contracts. The business model self-validates all objects, but does not control filterable criteria for security, or any user-based security for that matter.

The presentation tier is a form of MVP (Model View Presenter) and provides the client accessed security which are implemented on the server-side and proxied on the clients. (very similar to remoting).

Thus, the clients are very thin and only require updates when any view (client form) is improved and/or the interfaces for any presentation service requires modifications on the client. Changes to business logic that do not effect the presentation interfaces can be implemented without direct effect to the client.

I am just starting the test model and was wondering if anyone sees any potential problems



Re: Windows Communication Foundation (Indigo) Does this model look "feasible"?

Todd West

At this abstract level the factoring sounds fine. I'm not clear on why presentation, objects, and the data layers need to be separated out as separate services; from this description the complexity reduction and performance gain of implementing those three layers in a single service seems attractive.

Re: Windows Communication Foundation (Indigo) Does this model look "feasible"?

Kevin Hoffman

I'd have to agree with Todd here. It looks fine, but I would also be interested in the reasoning behind having so many "moving parts". I'm all for decoupling and componentization, but if you find yourself in a situation where you have a "straight line" consumption scenario:

service --- (consumed ONLY by) service 2 --- (consumed ONLY by) service 3

Then you might gain a huge benefit in doing some consolidation.

Re: Windows Communication Foundation (Indigo) Does this model look "feasible"?


Actually there are a few reasons.

1. A separation of presentation leads to very "testable" user interfaces and forces a consistent pattern for user interaction.

2. The client receives a thin installation package. There are numerous libraries that conprise the business model, removing as much of the distributed business logic as possible is desireable. As mosts developers know, very few implementations don't have separate dependencies. This model removes as many deendecies required for a client as possible.

3. A database has its own unique separation and typically massive support requirements. Databases do not have as many flexible communication channels as services do. There are many who push as much business logic as possible into the database itself and they are entitled to their particular decisions. I believe those type of designs are less flexible and quickly force the selection of "a" specific database. From my experience, potential clients may already have invested substantially in a database infrastructure and if their choice differs from "the" database the application becomes developed around, then it is much more difficult (if not virtually impossible) for a potential client to accept the huge investment cost of implementing a new database infrastructure.

This model is flexible and there are very few restrictions on choosing a particular database. In fact, any major database will work with virtualy zero code changes - the ORM supports all major databases and the connection for the ORM simply needs to identify the correct provider. Its a one-line code change to switch. This is HIGHLY desireable!
Thus, the separation of a DataLayer has substantial benefit.

4. Presentation needs to be separated not only for testing benefits, but the separate library is what the clients depend on and defines the dependencies necessary to be installed on a client. Now - technically - there doesn't need to be a separate "service" to publish the presentation interfaces, but the separation of logic is necessary and these logical boundaries "can" be hosted in a single service. Its semantics to have a single service versus named pipes with separate distinct logical boundaries running on the same server. Making these boundaries VERY distinct has numerous developmental advantages.

5. Take the authentication portion of security. The presenter or presentation service when hosted separately also separates the requirements for authentication. The channel from presenter to busness logic is within in a DMZ a makes clear what elements do not need or require propagated client credentials. The presenter authenticates and filters requests appropriately and acts with its own credentials for passing on requests. When this boundary is not distinct, then the business logic may be adding significant overhead and complexity to have client credntials passed around unnecessarily.

There are many more reasons, but is the model choice making any more sense based on what I just stated