Business Objects Architecture
Arjen Jansen
Pyrrho Advanced Industry Solutions B.V.
Almere, The Netherlands
arjen@pyrrho.com
January 2012
Model View Control
My first introduction with Object Oriented Programming was back in the nineteen-eighties. This program paradigm was - by my knowlegde - invented and developed by Xerox Inc.
They called it Smalltalk. It is a program interpreting environment with a lot of nice concepts. One of these I would like to mention in particular: the
concept of Model-View-Control(ler) (MVC). With MVC a loosely coupling between view and data/logic was introduced. And this is exactly what we need in the design
of a proper Business Objects architecture. Applying loosely coupling to your architecture automatically implies the concept of multi-tiers. Let me introduce the
"old" concept of MVC to a modern Business Objects architecture.
One object, multiple appearances
Whatever architecture we design for our Business Objects system, there will be a need for interaction with users. Nowadays a lot of different devices are
available that could act as interaction stations. These interaction stations range from character based terminals to smart-phone mobiles. Though you may not want to use
them all at this moment, your system certainly needs to be ready for possible enhancements in the future. Therefore, it is a good idea of using a separate tier in the
architecture for the logic of how data has to be presented on a specific interaction station.
This approach will give a clear distinction between view- and data-logic. Having to make changes in your
view logic will keep the data logic untouched. Besides, it will be easy to achieve to support multiple types of interaction stations.
With the introduction of loosely coupled tiers to our architecture we have to define how the information between the different tiers will be exchanged. This is where
MVC gets into the picture. At the server tier - running the data/logic - we will introduce the "model" object and at the client tier - running the view logic -
the "view" object. If data has to be sent between these two tiers, we will use a "control" object {ref R. Prins}.
The three types - model, view, control - of objects have in common that they are a representation of the same Business Object. But that is probably all that they have in
common. Depending on the tier, the Business Object has to serve a different role.
Data/Logic Server Tier
In this tier the "model" appearance of the Business Object encapsulates all its data attributes, transition/state information with business logic rules,
and the interaction with other objects.
Further on we will describe in detail the life and behaviour of the Business Object in this tier.
View Logic Client Tier
In this tier the "view" appearance of the Business Object has to be presented to the user. The user should be able to manipulate its attributes and to indicate
the transition it would like to
perform on the object. Of course, all of this dependent on the level of authorisation. But showing only data attributes of the Business Object might not be enough to
present meaningful information. To give the user a full understanding of the Business Object, some additional attributes from related Business Objects might be necessary.
Therefore, a retrieval request for a Business Object should also have the ability to ask for these additional attributes.
Business Object Exchange
The uncoupling in Client and Server tier requests for the exchange of Business Objects between these two. As we have seen above, each tier will have its own representation
of the Business Object. These representations will not necessarily have the same format. So before the Business Object can be delivered to the other tier, it has to be
translated into an exchangeable structure. At the same time we want to minimize traffic between the tiers. To implement this correctly, a self describing message of
the whole Business Object has to travel between the tiers. When sending from Client to Server tier, this message has to be accomplished with information about the transition to perform.
This will be the "control" appearance of the Business Object.
Presentation Tier
I would like to introduce another tier to the architecture. The need for this additional tier has been urged with the introduction of the world-wide-web
and its associated webbrowsers.
While I've proposed the traversal of complete Business Objects between Client and Server, you don't want to propagate this full Business Object to the webbrowser. The
solution is to create another tier between webbrowser and Server tier. So the webbrowser is not equal to the Client tier. Let us call the webbrowser, the Presentation tier.
The Client tier will exchange full Business Objects with the Server tier but will filter all irrelevant attributes for the Presentation tier. So at the Client tier security
filtering on attributes and transitions of the Business Object will be performed. This tier will also take care of the transformation to and from the appropriate markup
language like HTML. Because the Presentation tier only contains limited information about the Business Object, the Client tier has to preserve the full Business Object
information. The Client tier has the responsibility to merge Presentation tier information with the preserved Business Object before submission to the Server tier takes place.
Let us take a closer look at the various appearances of Business Objects, now that I have introduced the concept of MVC to our Business Object architecture. All three
- model, view, control - appearances are a derivation of the Business Object. So the Business Object will be at least the union of model, view, and control characteristics. But
whatever the combined description of the Business Object will be, it should never include something of none-business nature.
Model Object
The "model" object exists at the Server tier. This tier has to offer a range of services like:
lifecycle service: each Business Object has its own lifecycle.
persistency service: offering a Business Object to or retrieving a Business Object from the Database Management System.
locking service: prevent users from overwriting each other's actions on Business Objects.
transaction service: to support commit or rollback of transitions on Business Objects in case of success or failure.
concurrency service: multiple users should have concurrent access to Business Objects.
collaboration service: a transition on one Business Object may invoke an additional transition on another Business Object.
Although the Server tier has to offer these services, they are not part of the business domain. This means that the Business Object may
not contain any information about these services. Because we are designing an architecture for a Business Objects system, but don't want
to have mentioned any none-business related issues in our Business Object descriptions, we have to put some restrictions on our system.
Earlier, we have narrowed down our architecture to serve a specific range of applications - Enterprise Scaled Business Information Systems - and they have
their own characteristics. For these type of systems we can define a fixed set of patterns to describe the options, sequences, and
collaboration of the various services. Pour the patterns into frameworks or beans and let the "model" object follow them on
the execution of a transition.
While the Business Object may not contain any technical related issues, the architecture to run these Business Objects will. Let us take
a closer look at some technical aspects. In fact, the architecture itself will be only of technical nature and won't have any knowledge of
business related specifics. And this is of major importance, because it's the architecture that needs to solve issues like performance, platform
independency, and distribution to name just a few. So back at the drawing table, take a look at the following picture:
A square has been drawn in the middle of the picture indicated by the term "Server Engine". The "Server Engine" illustrates the
process of our Business Objects system at the Server tier. Assume the system is running and will only act on external events. One of the possible events
could be the arrival of a "control" object. At the moment this happens, the system has to execute at least the following steps:
parse and transform the "control" object to a "model" object.
execute the requested transition on the "model" object. This includes the execution of business rules and the invokation of transitions on
other "model" objects.
request the Database tier to make the updated "model" objects persistent.
inform the requestor with the result of this transition.
In the picture above you see three different versions of the same Business Object in the "Server Engine". Let me explain why they all are necessary.
At the left side you have the "control" object. It is obvious why this one exists. However, its lifetime will be very short. Created on arrival of
the self describing message, it will directly be transformed into a "model" object. Once this has been done, it might be destroyed. Now the system
has to continue with the "model" object, so why do we have two versions of this?
The system has to make a distinction between - what I call - a
transient and a persistent version of the same "model" object. Firstly, it might be that a business rule needs some information from the last committed
version of the Business Object. This specific version will be the persistent version, while the transient version will be the transformed "control" object.
Secondly, it might very well be that during the execution of the requested transition another event arrives. Assume that this event queries for the
same Business Object. It will not be
allowed to expose an uncommitted version of this Business Object outside the running transaction. So there always has to be a consistent - persistent - version
available to support concurrent requests.
View Object
At the "View Logic Client" tier I have introduced the "view" object as a derivation of the Business Object.
The "view" object could be offered as a programming interface, e.g. an IDL description, to a developer and let him build a user interface on top of this. The view and
business logic are nicely separated in a multi-tiered architecture. However, if a modification of the Business Object takes place, the programming interface will change too. Most of
the times the developer has to adapt the code of the user interface to reflect these changes. Especially within a dynamic environment or a project with small
iteration steps this might happens a lot. Would there be a solution to make this more flexible and adaptive to changes in the Business Objects model?
Take a look at the picture above and notice the difference of the "programming interface" between left and right object. The
left object will need a separate interface for each member of the Business Object, while the right object will only have one for all members. The programming
interface of the right object will be independent for changes in the members of the Business Object. But is this really a step ahead? If the programmer has
to supply the member names themselves you cannot make use of name and type checking during compilation. However, this can be solved by making use of some
kind of "member library".
The above picture shows how both "view" object and "member library" could serve as input for the creation of some type of user dialogue. Take
these two inputs as a start to build the user interface application.
I've shown the need for a "member library", but where would this come from? Remember that a Business Objects model was going to be the input source
for our Business Objects solution. The model contains a description for each Business Object, including its members. But it encapsulates a lot more information about
a Business Object. In fact, the model should be a complete description, including information about the Business Object's state diagram, inheritance relations,
association types, etc. And this not only for one Business Object but for all Business Objects within our domain. So won't it be possible to build a generic
user interface application that is completely driven by the supplied Business Objects model?
In that case you could concentrate on the development of a view component that should be able to
interpret the Business Objects model and to present this in a user friendly way. The advantages will be numerous. No single line of code of the view component
has to be adapted for whatever changes made to the model. At the same time it could support any Business Objects model. So developing another Business Objects
solution has its view component instantly available.
Control Object
It is evident that after the introduction of the "model" object and the "view" object there has to be a way of communication between these
two. It also became obvious that the Business Object exists in various appearances at different tiers. In this system of collaborating objects, it won't be
possible to assign one tier as the owner of the Business Object. If the Business Object has been delivered from model to the view tier, the requestor has taken over responsibility
from the model tier. If the requestor makes any - authorised - changes and asks for a - also authorised - transition, the model tier leaves nothing but execution
of this transition. Therefore, it is important for the Business Object to travel around in its full state. It is this representation of the Business Object that
is called the "control" object. A self describing message that will travel between the various tiers to accomodate a flexible and loosely coupled architecture.