Services

Model Architecture

SwiftRadius can help with the crucial architecture stage of a project. This is where all of the various technologies are selected, and the interactions between them are defined. Hardware, operating systems, databases, and development platforms are selected in this phase. This selection factors in the requirements of this particular engagement, as well as the existing operations and skills at the client site.

As the toolset is being defined, it is imperative to define the interactions of the technologies, and to define the logical tiers in the application. SwiftRadius has developed its Model Architecture, which is broad enough to apply to most enterprise systems. By applying the concepts in our architecture, you can start down a path that will leave maximum flexibility in your application design without incurring extra cost. The Model Architecture is equally appropriate for Microsoft .Net and Java/J2EE projects, or even combinations of the two.

The key component in the Model Architecture is the separation of the application into logical tiers. Each tier performs a number of specific functions, and depends on the tiers below it for services as necessary. Furthermore, each tier has no knowledge of the implementation of the tier below it. This indirection is invaluable, as it allows changes in one tier to be totally isolated from the other tiers. This is accomplished by the use of interfaces for calls between tiers. Thus, if the implementation changes, the caller is unaffected.

Model Architecture

Data Access Tier

The Data Access Tier is responsible for reading and writing data from one or more physical data stores.   While these data stores are typically relational databases, legacy applications such as mainframe data may also be accessed.    Implementation technologies may vary widely, including but not limited to

  • SQL Data Access Objects (may invoke stored procedures as well, although no business logic should be implemented in the database)
  • Object/Relational Mapping tools such as Hibernate or TopLink.

Service Tier

The Service Tier is perhaps the most important of the tiers, and also the tier that most often is poorly implemented. This tier should implement the logic to perform a specific set of business tasks, as defined in a use case. This typically includes

  • Validating the inputs.
  • Executing the required steps in the appropriate order.
  • Managing transactions in positive and negative situations.

All data read and write operations are requested from the Data Access Tier using Data Access Interfaces, which separates the business logic from the data stores that are in use. This dedicated business logic tier can be used for any number of clients and integrations without re-implementation. Therefore, this tier has no reliance on any of the presentation or integration technologies that may be in use.

Presentation and Integration Tier

The Presentation and Integration Tier is responsible for calling business logic for the purpose of presentation to an end user, or delivery to an external system.

Browser clients are prevalent in today's enterprise system, and are often the focus of an implementation. Many systems have been built in a "Model 1" architecture in the past, where the business logic is implemented directly in the JSP / ASP /PHP code. This model has many drawbacks, and most browser applications are now served by a "Model 2" architecture, using a Model-View-Controller (MVC) pattern, as depicted in the upper left corner of the Model Architecture diagram. (More detail on Model 1 and 2 architectures.) This has the benefit of separating presentation logic (the "View") from the data and business logic (the "Model"), with all interaction between the two coordinated by the controller. There are a number of popular MVC implementations for the Java environment, such as Struts, WebWorks, and the Spring framework. The MVC pattern can also be implemented for .Net by implementing a Front Controller pattern in ASP.Net.

A common problem in MVC implementations is that while the business logic and data access are separated from the View, they are tightly bound to the MVC implementation, and are quite difficult to re-use for other clients or integrations. For instance, the Struts framework has a facility for validating user inputs, but this validation is useful only within the MVC implementation. This is why the Model Architecture stresses a distinct Service Tier, separate from any one MVC implementation.

Web services are a primary benefactor of a distinct Service Tier. By having carefully implemented business logic distinct from any one MVC implementation, it is easy to expose business logic as a web service without having to re-implement any part of it. Web services can be deployed using the .Net Framework, or Java implementations such as Java WSDP or Apache Axis. Care must be taken to properly secure any web service, including authentication, authorization, and encryption as appropriate.

Asynchronous integrations can also be implemented relatively easily in the Model Architecture, since inbound messages can be mapped onto existing business logic with only a thin layer of additional code. This allows support for JMS, MSMQ, and EAI technologies in cases where the use case is asynchronous and/or where guaranteed delivery is required.

Desktop clients are required in some applications, where the web user interface is not rich enough, or where stand-alone functionality is required. The focus of a desktop client build can be on the user interface, as the generic business logic tier can be re-used yet again.   Stand-alone functionality can be accomplished with a desktop implementation of the relevant business logic and data. A provision for synchronization and replication with the enterprise application would be implemented in such a case.

Benefits

The benefits of the SwiftRadius Model Architecture for your organization include

  1. Ability to leverage the generic Service tier to add new clients or integrations with a fraction of the effort normally required.
  2. Web developers are able to work independently from business logic and data developers, and at different speeds, as test implementations of business logic can easily be set up.   This removes many project dependencies between teams.
  3. Business logic can be isolated from changes to the physical data stores.
  4. Business logic is implemented in an object-oriented language, and can take advantage of best practices such as interfaces, object composition, and design patterns.   These benefits are lost if business logic is implemented in a procedural language, such as a database stored procedure.
  5. Facilitates key techniques that improve quality and prevent the degradation of the application over time, such as Test Driven Development and Refactoring.

Latest News

More News »

Getting in Touch

We invite you to contact SwiftRadius with your business issues and opportunities. Please visit our Contact Page for more information.

Model Architecture

We have developed our Model Architecture for Java and .Net web applications, which can be used to guide your design and implementation.