Architecture

Models, Ontologies & Applese Architecture

Introduction:

With the advent of XML, several vertical segments and User-Groups have started to define their own markup languages such as MathML, Financial Markup Language etc. In designing such languages, they are defining ontologies and shared vocabulary of their own domain. Ontology is now accepted as a fundamental building block of Business-to-Business (B2B), Business -to-Consumer (B2C) Communication and E-Commerce. Several Organizations such as Biztalk.org, Ontology.org etc are putting efforts to establish standards. Ontology can also be used in Knowledge Management, which is another emerging area of Applications. Currently there are independent tools for developing each of these functionalities. Such fragmented approach leads to increased cost, reduplication and increased complexity.

The major design goal of Applese is to bring ontological concepts into the core application design process itself. This integration of Ontology at the Application Design stage would allow the emergence of functionalities like Business-to-Business Communication, Knowledge-Management etc seamlessly and in an integrated fashion.

Applese Architecture is a foundation of 4-layers based on ontological and meta-modelling concepts. The immense advantage of such a Framework is the predefined architectural concepts that the Framework provides. Such concepts are an immense advantage in drastically reducing the time required for defining the product architecture. Such architectural concepts can effectively jump-start a project and drastically reduce the time-to-market.

Model-Based Code-Generation Technique

Developing a software system can be seen as a succession of model construction, with the source-code one writes viewed as being one of the successive layers in a hierarchy of models. In a current software development scenario, use-case diagrams would be the initial source model and the source-code, the destination model. Each model has its own domain of concern. Most of the developmental know-how for the destination model is present in the source models in the form of design pattern models and architectural framework models. By utilizing these recurring patterns, it is possible to generate the successor model from the source model.

If a new facet of the successive model is not captured, one could add a new attribute to the source-model to account the new facet. The source-model is taken to be the meta-model for the destination model as its attributes define the structure of the destination model it generates. Model-based Code-Generation Technique is this methodology of developing several layers of models and using those models to drive an automated procedure to generate the source-code for implementing the model on a platform.

Ontology engineering provides an efficient methodology to this activity of dealing with models and Meta-Models. Ontologies facilitate the separation of domains of the successive layers of models. The ontology of a model is the set of the concepts and the relations that are relevant to the domain that is to be modeled.

Ontologies & Software Engineering

Several Communities have different definitions for the term 'Ontology'. For the Knowledge Base community, ontology is defined as a system of primitive vocabulary/concepts used for building artificial systems". Ontology is used in philosophy with the meaning of "Theory of Existence". In the AI community, ontology is defined as "an explicit representation of conceptualization". Gruber 1992]. It is legitimate, for a particular community, to adapt the notion of ontology to its specific needs and it is clear that the software engineering view will differ from the natural language processing view by emphasizing different aspects of the concepts.

For Software Engineering Purposes, A suitable definition is given by Nicola Guarino, that "ontology is to possibility what logic is to truth". This is supposed to mean that ontology is concerned with the possible relation between a model and a system it is supposed to represent, in a similar way that logic is intended to deal with the possible relation between formulae, the formal value of truth and the intuitive notion of truth.

There are several related terms that have to be compared and contrasted such as vocabulary, data dictionary, taxonomy, ontology and mereology. A vocabulary is a language dependent set of explained words. It does not seek universality or formality. A data dictionary is a technical form of a vocabulary used in the specific context of computer systems. A data base schema defines aspects of a database, such as attributes (fields), domains and parameters of the attributes. A taxonomy is a hierarchy of concepts in terms of basic isA & partOf relations.

An ontology is an explicit and precise description of concepts and relations that exists in a particular domain such as a given organization, a study field, an application area, etc. There are several levels and kinds of ontologies. The main properties of an ontology are sharing and filtering. Sharing means that an agreement may exist between different agents based on the acceptance of common ontologies, that they have the same understanding of a given concept. When two people are talking about an Invoice, they are talking about the same concept. Filtering is linked to abstraction. We are considering models of reality. These models, by definition, take into account only a part of the reality. Their usefulness is based on their ability to filter out a lot of undesirable characteristics. An ontology defines what should be extracted from a system in order to build a given model of this system.The definition of ontology here corresponds closely to the classical definition of a meta-model

There are three kinds of information (levels) inside a given ontology:

  1. Terminological: This is the basic set of concepts and relations constituting the ontology. It is the definition layer of the ontology. The IsA and IsPartOf Relations between the various concepts are also defined.
  2. Assertional: This part is the axioms layer of ontology. It is a set of assertions applying to the basic concepts and relations, e.g.:
              If X is a Man AND Y is a Man AND
              EXISTS Z who is son of X and father of Y THEN
              X is a GrandFather of Z 
    
  3. Pragmatical. Any other information that could not fit in a) or b).

Applese Architectural Layers

Applese uses three layers of abstraction each concerned with a separate domain. The Top layer, called Meta-Model Layer, consists of concepts such as "Process","Roles" etc. A Business Object Model is built over the Meta-Model consisting of Business Documents such as WorkOrders, Journals etc. Data or "Persistance Layer" is the underlying medium in which the records of the Business Objects are stored.

Meta-model e.g. "Process", "Credit" etc.

Model e.g. "Work-Order","Credit-Amount" etc.

Data e.g. "USD 500","John" etc.

Persistance Layer

The Persistance Layer is the bottom-most layer in the Applese Architecture. The Business Objects developed with Applese rely on relational databases to store the state information. The Persistance Layer makes it possible to isolate the application's object model from the underlying relational database. Persistance Layer also defines how the data is transported between the client and the database. The information specific to the Persistance Layer are stored as properties in the Connection Object of the Applese Data Object. The properties of the Connection Object are given below.

DriverName : The name of the jdbc driver to be used to connect to the database
DSN : The name of the database source
Transport : The method in which the data transfer takes place. The Data Transfer can be either as direct jdbc or through Servlet. When the transport layer is specified as jdbc, the client directly connects to the database server and updates the database in a typical client-server model. When the transport is specified as servlet, the data from the client is converted into XML and transported to a servlet which in turn connects to the database server and updates the database. When the transport layer is specified as servlet, a three-tier architecture is employed for the data transportation.
IP Address : The IP address is the location of the servlet. The Client uses this address to find the servlet, which acts as the middle layer.

The connection-object also contains the user-name and password information required to establish the connection with the database server.

Object-Model Layer

Applese is a forms-centric framework. Forms are the visual-counterparts of the business objects. For the end-users, the business objects are Forms. A Business Object typically would consist of several database tables, which are dependent on one-another in a parent-child relationship. Applese defines this structural relationship between the database tables of a business object in a tree as follows:

Basic Tree Structure

       (+) Document
            (+) Tables
                (+)  Groups
                     (+)  Data-Elements

The basic unit of reference in Applese is a document or form or business object. Each Form can consist of one or more tables. Each Table consists of groups of columns. Each Document correspond to RDBMS View, Each Table correspond to RDBMS table and Each DataElement to database column. Group does not have a direct analogy in RDBMS. Groups only have User-Interface Signficance. For example, an address group would consist of individual columns like street, county, state, country, pin-code etc. While creating database tables, groups would be ignored.

Document = View

Table = Database Table

Group = None

DataElement = Database Column.

Apart from the Structural Definition, the Document layer also defines the behavioral aspects of the business object through events. A developer can specify the individual behavioral aspects of the business object by defining the events through the event-editor. Apart from events and methods specific to the business object, there are methods and events related to the persistance of the object. Each Business Object has an object-level insert, delete and update methods with finer classifications such as pre-insert, post-insert, pre-delete, post-delete, pre-update and post-update. In a similar fashion, each table in the business object also has table-level insert, delete and update methods having finer classifications like pre-insert, post-insert, pre-delete, post-delete, pre-update, post-update methods.

MetaModel Layer

Applese relies on relational databases for persistance. In Relational Database, the data-types supported inherently are restricted to a specific set. Applese allows definition of user-defined data-types as objects in a Meta-Model Layer. For example, Date-Of-Birth can be defined as a sub-type of Date. These objects also act as data-elements in a xml that is used to transport data in Business-to-Business Transactions etc.

Along with Object-definition, MetaModel Layer can also specify the default user-interface of the object. For objects which take a value from a range such as Unit-of-Measurement, the range can also be specified as value-list.

In the current version of Applese, all business objects extend a standard business object named AppDoc. In future version, Several Document Types such as Requisitions, Schedules, Receipts etc will be pre-defined as extended objects of the basic business object. Developers will also be able to extend their own business object sub-types.

In Applese, MetaModelFactory defines this terminological part of Ontology. Ontology can be used to generate assertions also. For e.g., if there is a data-element in a document called date-of-creation, then assertions like periodic reports (documents created between any two dates, documents created during last-month etc.) can be generated. Assertions based on ontology would be incorporated in the following versions of Applese.

Component Framework Adapter Layer

Distributed Enterprise Applications have to be developed within a Component Framework. Currently there are two major competing Component Frameworks namely Enterprise JavaBeans (EJB) promoted by the SUN and Distributed Component Object Model (DCOM) promoted by Microsoft. In Applese, the Component Framework can be wrapped over the Document Layer as a separate layer called the Component Framework Adapter. Currently EJB alone is supported. In future versions, DCOM Framework will also be supported. Frameworks such as CORBA could be added as an additional layer to Applese without any major changes.

Future

It is acknowledged that Object-Oriented-Technology is progressing towards a much more abstract development level called model-oriented technology (MOT). MOT would empower the end-user himself to assemble components with distinct functions together to create a new functionality. Model-Oriented Code-Generation Technology is a smoother transition between the OOT and MOT and Ontology is one of the key components, which would enable this transition.

Applese has a simpler semantics than one can envision to enable easier assimilation of the technology. Future Versions of Applese would include richer semantics adding much more intelligence into the tool.