EXPRESS and the 3-tier Architecture

We can picture a mapping between the way EXPRESS does things and the 3-tier architecture. This mapping depends on what type of system EXPRESS is providing an interface for.

EXPRESS can provide RESTful Semantic Web Services as an interface for systems that have complex business logic or for systems that have datasets and want to provide them with simple access. In addition to dividing systems into complex business logic systems and dataset access systems, we can divide them into legacy systems (non-web or non-Semantic) and Semantic systems (based on Semantic technologies like OWL or RDF and have Semantic metadata).

So in total we have 4 categories of systems that EXPRESS can be used to provide RESTful Semantic Web Services:

1. Legacy systems with complex business logic
2. Legacy systems providing dataset access
3. Semantic systems with complex business logic
4. Semantic systems providing dataset access

The mapping between EXPRESS and the 3-tier architecture can be viewed as follows

1. Legacy systems with complex business logic

• Presentation Tier = Semantic Interface
• Application Tier = Business Logic
• Data Tier = Database

2. Legacy systems providing dataset access

• Presentation Tier = Semantic Interface
• Application Tier = CRUD to SQL mappings.
• Data Tier = Database

3. Semantic systems with complex business logic

• Presentation Tier = Semantic Interface
• Application Tier = business logic.
• Data Tier = Triple store or some semantic

4. Semantic systems providing dataset access

• Presentation Tier = Semantic Interface
• Application Tier = CRUD to SQL mappings.
• Data Tier = Triple store or another Semantic database

This mapping raises an important question, if we have two systems one with complex business logic and the other providing only dataset access, and both have similar OWL files how do we show that the complex business one does more than the other.

EXPRESS the Dilemma

As I started implementation, some ideas are popping into my head, I know this should happen more often :) but anyhow...

We can view the Semantic Data in an EXPRESSive system as an interface to the client, which tells it how to interact with the system. The simple CRUD operations affect the Semantic interface in the same way no matter what the system is. What differs however is the business logic which is triggered or reflected by the CRUD operations on the Semantic interface.

There are two levels of actions associated with EXPRESSive systems: actions on the Semantic interface, and actions by the business logic. In fact there are three types if we count actions in the real world. I will illustrate that with an example, when a customer orders a pizza:

-on the Semantic interface level, an order instance containing the details of the order is created, with connections to related instances such as customer and pizzas.
-on the business logic level, the database is updated and notifications are issued.
-the real world level, pizzas are baked then delivered.

Questions:

• What is this interface? Is it an OWL or RDF file, a triple store, or a triple space.
• Does the client query the interface structures to infer what happened and what should happen?
• Isn’t this the application state? Shouldn’t the client keep track of that?
• Maybe it isn’t the application state, maybe the server state was altered –by the server or by the client- and the server has to show it?
• Why is this interface important? It shows the consequences of the action.

So What does all that imply?

• There will be messages exchanged between the Semantic Interface level and the business logic level.
• In the case of simple data management there is no business logic level.
• The generation of the Semantic interface can be automated.

In the next post I'll either clarify or complicate things further