Below I have attached the outline of the architecture for the Murray Bookshop applications that the students of HIT8099 have been working with. Any comments are very welcome...

Message Based Architecture of the Murray Bookshop

The Murray Bookshop is a “virtual company” that forms the basis of the Enterprise .NET subject at Swinburne University of Technology. Students of HIT8099 extend the application, with each semester building on the previous semester. The bookshop has been running for one year and currently includes a web site that allows customers to browse the products on offer, and place and track orders. A Windows application is used by warehouse staff to fill orders, order shipping, and mark orders as collected. As this is a virtual company, a Windows service is provided to simulate employees and customers. This service places orders and performs warehouse operations at timed intervals.

This document outlines the core architecture used in this project. This architecture is designed with several key areas namely: layered architecture, stateless business components, message based communication, and loosely coupled components.

Layered Architecture

Applications built for the Murray Bookshop use a layered architecture consisting of a presentation layer, business layer, and data access layer. The architecture used is based upon the recommendations in Microsoft's Patterns and Practices book titled Application Architecture for .NET: Designing Applications and Services available at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp .

Implementation Notes:
Database access is not available to the presentation layer components.

Stateless Business Components

The Murray Bookshop uses stateless business components to help avoid concurrency issues at the business layer. This also helps reduce issues related to access via the web, as these components are typically accessed via a web application, or web service.

Implementation Notes:
Avoid instance variables within business components.
Use local variables for interacting with database components (as these contain state information).
Do not use Business Entities.

Message Based Communication

Messages are used for communication between components across layers. To facilitate this, a set of classes has been included in the core assemblies. These classes contain the details sent to the service to make a request, and returned from the service in response to this request. This simplified the process of changing the communication channel used as these classes are Serializable and encapsulate all information to be exchanged between parties

Implementation Notes:
The Murray.Core.Common.Messages namespace contains the message classes.
Each service offered by the bookshop has a Request (Message) and a Response .

The FetchCustomerOrderMessage is used to request customer orders to view on the accounts page of the web site. This request is sent from the web application to the IManageOrders component when then generates a FetchCustomerOrderResponse , which is then returned to the caller. The FetchCustomerOrderMessage contains the details required to make this request including the customer's code, the order status filter (indicates all orders, outstanding orders, or previous orders), as well as the page requested, and the records per page. The FetchCustomerOrderResponse contains the response from this request. The response contains the requests details, the total number of pages, and a dataset with the results.

Several parts of all requests will be consistent across all requests and responses. For a request message this includes the page requested, the records per page, and also a search filter (not used in this example). For the response this includes the requests details, and the total number of records. This functionality is encoded in the BaseSelectRequest and BaseSelectResponse .

Future Considerations/Changes:

Currently the individual message classes are contained within the core assembly. This reduces the ability to work on the individual projects in isolation. This location is currently used as these classes are needed in the database, business, and presentation layers. If this was reduced to the presentation and business layer the classes could be located in application assemblies rather than the core assemblies.

With .NET 2.0 generics will allow more functionality to be moved into the base class messages. This may allow all message to use just these base classes, though requests will then require a Parameters class (example).

Loosely Coupled Components

The business components are only accessible via interfaces. The user of these classes loads the component via the ComponentLoader and GenericFactory classes. For example the OrderManagementService implements the IManageOrders interface. This class can be loaded via the OrderManagerLoader 's Load method. This method reads the assembly and class details from the associated app.config file, loads this assembly and then constructs an object of the configured class.

This structure allows for communication between the presentation and business layer to be changed. During testing locally installed business components can be directly used, while in production a proxy can be installed locally that communicates with the application server. Additionally this allows for changes to be made to business components without requiring modifications to the user interfaces. This will allow easier deployment of bug fixes and minor business changes.

Implementation Notes:
The current applications include an adapter that used COM+/Enterprise Services to allow communication between the presentation layer on the web server and business layer on the application server.