Istrib is a set of loosely-coupled libraries which aid small and middle-size enterprise applications development. The objective of Istrib is to provide the following free and open .NET components:

• Aspect-oriented extensions
• Light-weight remote services layer (remote facade) components with an extensible container providing declarative transactions, logging and other capabilities
• Fully-functional, developer-friendly persistence layer with automatic object-relational mapping capabilities
• Offline processing services allowing to replicate part of domain model at client side and merge offline changes with server state (automated transfer objects).

Istrib.Aop

Aspect-oriented extensions

During enterprise applications development we discover many cross-cutting concerns. The most important are manual transactions used when we do not want to involve Enterprise Services (COM+) in our application (because it is too "heavy" e.g. we do not need distributed transactions at all). Another typical problems we want to automate are: user operations logging and system busy/idle state reporting (wait cursors). None of these problems can be clearly solved using standard, object-oriented approach. Istrib.Aop introduces dynamic class generation (dynamic proxies) and method execution controllers (method interceptors) which provide wide and flexible aspect-oriented extensions for existing objects (especially services).

Istrib.Services

Light-weight remote services layer (remote facade) components with an extensible container providing declarative transactions, logging and other capabilities

The objective of Istrib.Services component is to introduce light sister of EJB (Enterprise Java Beans) in .NET. After years of using EJB several architectural design pattern have been developed for this technology. We see the most fundamental are: remote facade and transfer objects. These two focus on distributed client-server applications development. Remote facade defines a well-defined boundary between client and server processes to minimize cost of remote calls. Transfer objects pattern aids this policy providing a model of coarse-grained data transfer between client and remote facade. Many designers and architects find some EJB features and patterns (entity beans, application services) as needless in small and middle-size enterprise applications. As we want to provide EJB-similar solution for small and middle-size applications we want to include components for efficient implementation of remote facade and state and stateless session components. We think it is useful to merge remote facade and service layer (application logic layer) patterns in one remote services layer which will be consistent with a Service-Oriented Architecture approach. However the objective of Istrib is to provide a homogenous platform so currently we will not include Web Services in it. The remote service layer will take advantages of Istrib Aspect-oriented extensions in order to assure declarative transactions and logging as we find in other component technologies (e.g. COM+, EJB).

Istrib.Persistence

Fully-functional, developer-friendly persistence layer with automatic object-relational mapping capabilities

We encourage using Domain Model design pattern to implement domain logic in small and middle-size enterprise applications. We find relational approach of Microsoft (DataSets, Table Modules) as an efficient but dirty solution. However we agree the DataSets are fundamental in reporting and presenting information to end users. We base on Domain Model but add a powerful object query language which is able to return relational results (DataSets) which act as Transfer Objects bringing data from server to remote clients. We automate Domain Model pattern implementation by providing a transparent object-relational mapping tool - a persistence layer: Istrib.Persistence. We assume design and development starts from objects and the database model is only a side effect of writing classes code. We delay database concerns to late stages of development process - when efficiency tests and tuning are performed.

Istrib.Server

Istrib.Server joins Istrib.Persistence and Istrib.Services into a default application server solution based on standard remote services and persistence layers.

Istrib.Offline

Offline processing services allowing to replicate part of domain model at client side and merge offline changes with server state (automated transfer objects)

We find the 90% of enterprise applications services are based on load-update-save scheme. However remote services layer causes creation of many transfer objects to serve such services. We think many of load-update-save services may be automated at some level allowing significant decrease of transfer classes count. The scheme is similar to classical database processing. We replicate a subset of business objects at client side. The client changes them and sends back to server. Data consistency check is performed (optimistic concurrency is involved as default - pessimistic may be added by developer). The data is updated. We found an enterprise system may be designed so that "document" objects (processed offline - rarely but in long business transactions) could be separated from "state" objects (processed in short, usually system transactions - such a transaction initiated by a barcode scanner). The "document" objects are the best candidates for automated offline processing aided by Istrib.Offline.