Architectural Concepts

Home

About Me

Documents and Papers

Architectures

Design Patterns
Creational
Behavioral
Structural

Model-Reflective Architecture

Context-Aware Architecture

Model-Reflective Architecture

There are many approaches to ensure that end-user development/tailoring is made feasible, however their applicability varies depending on the complexity of the information needed and work process executed. This flexibility and adaptability, a pre-requiresite for any end-user tailoring/development, can be ensured through the use of a model-reflective architecture. Model in this sense can communicate either the data model, a work process model, or a software model.

Work process model:
A work process model would be lesser suited to such representation as a work process model would not necessarily convey the information needs.However, if extending the model, e.g. a UML activity diagram with a tailored profile that could easily show which information needs any given user has during the process execution then such a model could be used. Both the use of a work process model and a software model could be ensured through Model Driven Architecture Model Driven Architecture (MDA) is based on the formal groundings of the Meta-Object Facility (MOF), although for all practical purposes it also relies on the UML since most MDA tools perscribe to the UML as their chosen modelling language. Work process models will in the case of information needs have to offer some way of describing which actual information is required at any given step. This could then, as with data model, be used as a basis for generating a service end-point.

Software model:
If the model is in the form of a structural software model then one could treat the model as a visualization or representaiton of a business object. One can even think of the business object as an abstraction of the data model wherein the complexities of the information is hidden in the business object. For instance any cross table references or dependancies would be hidden. Thus one would need a mapping between the representation of the business object and the acutal data model.

Data model:
If the model is in the form of a data model, e.g. a database table, then any alterations to the database could be automatically reflected in the controller and communicated through the view. However, in a mobile information system, the view will often be (on the serverside) a service end-point that mobile clients can bind to. Briefly explained the architecture would allow for changes in the database /  (database)view to be detected by the middleware which could then automatically generate and deploy a webservice which would be advertised to mobile clients. A more refined alternative is the use of Common Warehouse Metamodel (CWM) for data meta-modelling. Data modelling can be utlized for the simplest information needs, wherein the mobile user may not need to make alterations their work process flow, they merely need access to more information in order to perform their current work process more efficiently.

Figure 1: Model hierarchy wherein the top level abstracts the lower one

One can view these different perspectives of information representation in a hierarchical manner, wherein work process provides an abstraction of the software model (business objects) and the software model provides a higher level view of the data model. For end-users it may be far more visually intuitive to work with a work process model, as opposed to a data model. But the complications arise due to the complexity introduced by abstraction. This is where the pattern space may aid developers and end-user developers. For instance the mapping between the business object to data model requires a mapping solution. Not surprisingly there already exists such solutions, in the form of patterns. However, and the basis for much of the rationale behind this work, is that maybe mobile workers need access to this information regardless of where they are, and regardless of connectivity to their service provider. In cases where the service consumer is only sporadically in contact with the service provider there will be a need to manage information access locally on the client device. This could be a challenge as mobile devices may have limited capabilities and battery life.

-to top-

Context-Aware Architecture

Context-aware architecture is based on the concept of intelligent software that is reactive. Essentially the software will adapt its behavior based on either external or internal information, or both. Much research has been done in the area of context-aware systems, especially in terms of mobile solutions. This is due to the fact that mobile solutions will potentially benefit more from utilizing contextual information in their self-management. For example a mobile device with limited battery could use context awareness to limit, or at least notify the user prior to the use of battery draining operations such as video or internet surfing. A more tangible benefit in terms of software architecture and the SOA paradigm would be the use of context awareness in service composition, wherein dependant on the contextual information available to the mobile device it may provide different parameters in a QoS request or brokering/negotiation session with a service provider. Although this is not directly beneficial for an end-user developer it could be used indirectly. When end-users develop and deploy new services which are then available to their mobile workers they could add apt QoS information to the services. This information could then be used during the negotiation sessions between service providers and consumers, so that mobile workers who do not have any interest in receiving notification of or using a given service would not be notified of it either, this could possibly be due to the mobile worker not being in an area with good enough connectivity to successfully be able to use the service according to the requirements stipulated in its service QoS declaration.

-to top-