Towards Semantic Middleware
for Web Application Development

Invited article from the Web Systems topic area

Daniel Oberle¹, Steffen Staab² and Andreas Eberhart¹

¹Institute AIFB, University of Karlsruhe, Germany
²ISWeb, University of Koblenz-Landau, Germany

1. Introduction

Middleware facilitates and manages the interaction between applications across heterogeneous computing platforms. The increasing use of the Web as a channel to access information systems forced middleware platforms to provide support for Web application development. This support is typically provided in the form of Application Servers and recently in the form of Web Services. Application Servers comprise the functionalities of conventional middleware like Transaction Monitors or Object Brokers, but incorporate technologies for Web access. Web Services are a set of XML-based protocols and configuration files to realize distributed systems based on a Service Oriented Architecture (SOA) - a paradigm that factorizes the functionality in loosely-coupled and independent services that can be described, invoked, discovered and composed.

While Application Server and Web Services middleware offer many possibilities for developing web applications, they also bring about new challenges, which we want to address in this paper. Application Servers provide bundled functionality, yet the complexity of managing a distributed application remains a challenge for developers and administrators. For instance, managing component dependencies, versions, and licenses is a typical problem in an ever-growing repository of programming libraries. Web Services let the developer reap advantages roughly similar to the ones found in Application Servers - though based on an open standard set of protocols. However, they also imply analogous problems. Not only do developers and administrators have to cope with the local complexity, they also have to incorporate external, possibly varying dynamic information on third-party services.

Both types of middleware try to counter increasing complexity by managing various issues (transactions, session management, user rights etc.) in an application independent way. This is achieved by generic middleware software configured with the help of administration tools and corresponding XML configuration files. Though this constitutes a very flexible way of developing and administrating a distributed application, configuration files do not provide a high-level of abstraction taming the complexity, even if they are more or less human-readable XML. The reason is that they lack a coherent formal model. Thus, it is impossible to ask for conclusions that come from integrating several descriptions.

In this paper we try to remedy the problems by applying semantic technology, i.e. ontologies and inference engines, in the middleware itself. After providing a short introduction to Web-based middleware and detailing some of its problems in sections 2 and 3, we propose an ontology as harmonizing conceptual model covering aspects from the heterogeneous areas of component and service descriptions (section 4). The ontology is leveraged to support developers and administrators in their complex tasks during development-, deployment-, and runtime in our prototypical Application Server (section 5). We discuss related work in section 5 and conclude in section 6. Finally, we provide a useful compilation of references and links.

2. Middleware for Web Application Development

Middleware is a distributed software layer that sits above the network operating system and below the application layer and abstracts the heterogeneity of the underlying environment. It provides an integrated distributed environment whose objective is to simplify the task of programming and managing distributed applications and also to provide value-added services such as naming and transactions to enable distributed application development. It is about integration and interoperability of applications and services running on heterogeneous computing and communications devices. [Mahmoud]

The history of middleware spans more than two decades. Different types of middleware were developed to tame the ever growing complexity of distributed information systems. E.g. Remote Procedure Calls, Transaction Monitors, Object Brokers, Object Monitors and Message Oriented Middleware (cf. [Alonso, Casati et al.] for a nice historical overview) - in the following referred to as conventional middleware.

This work concentrates on middleware for Web Application Development, viz. Application Servers and Web Services, which will be introduced and contrasted with conventional middleware in the following subsections.

2.1 Application Servers

The increasing use of the Web as a channel to access information systems forced middleware platforms to provide support for Web access. This support is typically provided in the form of Application Servers.

Application Servers comprise the functionality of conventional middleware platforms. In addition, they incorporate the Web as a key access channel to the functionality implemented using the middleware. Incorporating the Web as an access channel has several important implications. The most significant one is that the presentation logic of the application acquires a much more relevant role than in conventional middleware. This is a direct consequence of how HTTP and the Web work, where all forms of information exchange take place through documents. Preparing, dynamically generating, and managing these documents constitute main requirements to be met by an Application Server in addition to the other needs middleware platforms must respond to. [Alonso, Casati et al.]

The core functionality of an Application Server can be described by examining the two competing frameworks Sun's J2EE and Microsoft's .NET. Both are similar in terms of their functionality, subsume conventional middleware, but offer APIs for XML processing, dynamic generation of Web pages or Web Service support. "Vertical services" are added for load balancing, pooling and caching as well as management and security aspects. Also, they foster component-based software engineering with Enterprise JavaBeans (EJB) in the case of J2EE and the Component Object Model (COM) in .NET. The open-source Application Server JBoss [Fleury & Reverbel] is one example implementing the J2EE framework. An exhaustive list and comparison of Application Servers can be found at the [Application Server Matrix].

2.2 Web Services

The emergence of the Service Oriented Architecture [SOA] paradigm is triggered both by the desire to outsource IT development and services as well as network bandwidth being cheap and pervasively available. Distributed systems based on a SOA factorize the functionality in loosely-coupled and independent services. The benefit of a loosely-coupled system lies in its agility and the ability to survive evolutionary changes in the structure and implementation of the internals of each service, that make up the whole application.

The Web-based middleware for such systems is called Web Services subsuming a set of protocols and XML-languages for interface description, invocation, discovery and composition of services. De-facto standards are already available for the interface description (Web Service Description Language [WSDL]), the invocation (Simple Object-based Access Protocol [SOAP]) and the discovery (Universal Description Discovery & Integration [UDDI]). Several competing efforts exist for the composition. Other aspects are included as well, e.g. WS-Security, WS-Policy or WS-Trust - altogether they form an inscrutable set and are labelled [WS*]. The advantage of WS* descriptions lies in their independence from particular implementations.

Thereby, Web services might draw from components residing in Application Servers distributed over different physical locations, organizations, and heterogeneous platforms. Application Servers are an obvious target to support this functionality, as they provide the basic infrastructure (Web server, XML parsers etc.). In the example of JBoss, the developer is only required to mark a certain method with meta-tags in the source-code. JBoss cares for automatically generating the WSDL description and handling the SOAP messages.

In addition, Web services might be composed of larger units, including other Web Services. Support for this "programming in the large" is provided by Workflow Execution Engines, usually implemented on top of Application Servers. E.g., JBoss offers its jBpm (Java Business Process Management). Several platform-independent languages, e.g. [BPEL], have been proposed to define workflows in a declarative way.

Despite this close relationship, designing and developing distributed systems based on a SOA is not a simple matter of "porting" existing applications to the Web. The various aspects, like transactions or security, typically provided by Application Servers in closed, distributed environments are challenged by the decentralized, autonomous nature of the Web.

3. Problems

3.1 Application Servers

Despite the bundled functionality of an Application Server, the complexity of managing a distributed application remains all but an easy task. Managing component dependencies, versions, and licenses are typical problems in an ever-growing repository of programming libraries. In Microsoft environments, this is often referred to as "DLL Hell".

In [Oberle, Eberhart et al.] we have identified several problems related to the management of Application Servers. An interesting case are indirect permissions due to context switches (cf. Figure 1). An example would be the anonymous user who authenticates himself using HTTP basic authentication to access a Web shop. The script on this page, say a Servlet, might connect to the Customer Entity Bean, an EJB, which in turn accesses a Customer table in the database. We assume that the database is only accessible by the administrator. Therefore, the EJB performs an explicit context switch (what is frequently described as the "run as" paradigm). The call succeeds, because the user information will be propagated and the call will also be executed using the administrator's credentials. This case is definitely not a bug; however, it remains a pure manual and tedious task for the administrator of the Application Server to keep track of such indirect permissions.

Figure 1: Example of indirect permission.

Application Servers try to face the increasing complexity by managing orthogonal issues (transactions, session management, user rights etc.) in an application independent way. This means that the responsibility is shifted from the coding to the deployment process. While it is always a good idea to reduce the amount of source code that has to be written, the deployment process can be quite tricky in itself. Consider the J2EE platform as an example. The specification describes the structure of XML deployment metadata (J2EE deployment descriptor). J2EE implementations like JBoss provide a set of tools, which help the user to generate such metadata. However, the tools merely act as an input mask, which generates the specific XML syntax for the user. This is definitely a nice feature, however, she or he must fully understand the quite complicated concepts that lie behind the options for the transactional behavior for instance - and juggle with all of them at the same time. The current deployment tools do not help to avoid or even actively repair configurations that may cause harmful system behavior. Even worse, this problem is duplicated as there is a plethora of deployment descriptors for different kinds of components (Servlets, EJBs, MBeans) and aspects (security, transactions, etc.).

In the example of indirect permission, the administrator would have to analyze two different configuration files as well as the source-code to overlook the situation outlined above. First, the configuration file of the Servlet container (web.xml) states that only authenticated users may access the WebShopServlet:

Second, the WebShopServlet itself accesses the CustomerEntityBean. The servlet's doGet() method serves the incoming HTTP requests. In our case it queries user account information out of the customer table by means of the bean in order to display it to the user. After retrieving a handle to the bean via the Home interface, the getCustomerName() method of the bean is invoked by the servlet.

Third, the deployment descriptor of the CustomerEntityBean, called ejb-jar.xml, states that the bean performs a context switch via the tag. It thus accesses the database table with the administrator's credentials:

3.2 Web Services

Building a distributed system using Web Services lets the developer reap advantages roughly similar to the ones found in Application Servers - however it also implies analogous problems. Not only do developers and administrators have to cope with the local complexity, they also have to incorporate external, possibly very dynamic information on third-party services.

In [Oberle, Lamparter et al.] we have identified several problems related to the management of Web Services. An interesting example is the detection of loops in the invocation chain. Current workflow design workbenches only visualize the local flow and leave the orchestration of messages with the business partners up to the developer although enough information is available in machine-readable format, e.g. BPEL documents. The structure of the local flow combined with publicly available abstract flows of the partners might contain loops in the invocation chain that would lead to non-termination of the system. The developer has a hard time analyzing the complex interaction protocols between business partners.

Much like Application Servers, Web Services middleware requires the developer to handle a multitude of configuration files, viz. [WS*], that factorize Web Service management tasks into different aspects, such as input/output, typing, workflow, or security. The advantages of WS* are that they have already benefited some industrial cases. WS* descriptions are exchangeable and developers may use different implementations for the same Web Service description. The disadvantages of WS*, however, are also visible, yet: Even though the different standards are complementary, they must overlap and one may produce models composed of different WS* descriptions, which are inconsistent, but do not easily reveal their inconsistencies.

Both deployment descriptors in Application Servers and WS* in Web Services middleware allow for convenience and flexibility but they are not able to tame the complexity of management. The reason is a missing coherent formal model which makes it impossible to ask for conclusions that come from integrating several descriptions. The conceptual models underlying the configurations are implicitly encoded in different XML-DTDs or schemas. Hence, discovering such inconsistencies or asking for other kinds of conclusions that derive from the integration of such descriptions remains a purely manual task of the software developers accompanied by little to no formal machinery.

In the subsequent sections 4 and 5 we define a coherent formal model, i.e. an ontology, and put it into action in an Application Server in order to reduce the complexity of management.

4. Ontology

As a consequence of a missing coherent formal model, we propose an ontology covering aspects from the heterogeneous areas of component and service descriptions, policies, quality of service, service level agreements, and privacy. Ontologies formalize concepts and concept relationships (associations) very similar to conceptual database schemas or UML class diagrams [Staab & Studer]. However, ontologies are expressed in logic-based representation languages. Inference engines allow to query and reason with ontologies at runtime.

4.1 Design

Semantics-based management of middleware comprises two layers. First, one formally specifies a conceptual model of middleware in several aligned ontologies, i.e. one formalizes what services "are made of" in general. Thereby, the conceptual model for the middleware proper needs to be built only once, while the conceptual model for the application domain, e.g. web shopping for books, may vary. Second, one provides a formal specification of a concrete set of services and the properties they have by providing semantic metadata that are aligned to the ontologies from the first layer. The semantic metadata formalizes a particular instantiation of a distributed application.

While some of the semantic metadata can be generated automatically, a full specification will always require manual provision. This is usually a rather cumbersome and error-prone work for the developer. Hence, our goal is to decrease the provision costs to a minimum. In [Mika, Oberle et al.] we analyzed existing ontology efforts and came to the conclusion that they typically require a costly modelling for several reasons. Hence, we simplify this task by re-using a proven foundational ontology instead of modelling from scratch. Foundational ontologies are carefully crafted by experts and aim at reuse. The idea behind foundational ontologies has arisen from experience in ontology and software engineering. The experience has shown that ad-hoc conceptual models may adequately reflect a given state of requirements at a certain point in time, however, the extension of requirements has easily led nowhere, because a given ontology proved to be unextendable for new requirements. The problem could often be attributed to a design of the ontology, which was just good enough to meet initial requirements, but not good enough to meet new requirements. Foundational ontologies capture insights from philosophy, logics and software engineering in order to prescribe good ontology engineering practice at an upper level of the ontology. For instance, the ontologies below distinguish carefully between subclassing and functional roles, e.g., an information object may play the role of web service input or output, but is a subclass of neither.

Figure 2: Stack of ontology modules.

Correspondingly to this core idea, we have pursued a modularized and layered approach that adds ontological commitment in a piece-wise manner for maximum possibility of ontology re-use at all layers. Figure 2 depicts the ontology modules where the responsibilities are distributed as follows:

DOLCE (Descriptive Ontology for Linguistic and Cognitive Engineering) [Oltramari, Gangemi et al.] is a typical foundational ontology with rich axiomatization of domain independent concepts, explicit construction principles and careful reference to interdisciplinary literature.

Several additional theories exist for DOLCE that come in the form of ontology modules. Descriptions & Situations (D & S) is such a module and can be considered an ontology design pattern for (re)structuring application ontologies that require contextualization. In [Gangemi & Mika] a detailed description is given.

We have applied the D & S ontology design pattern to formalize Core Ontologies of Components and of Services. While the first axiomatizes typical concepts in an Application Server (most prominently software components and their interrelationships) the second deals with similar aspects of services [Mika, Oberle et al.]. The core ontologies are maintained at http://cos.ontoware.org.

Domain ontologies enrich the core ontologies by additional domain dependent knowledge. We specialize the concepts and associations of both core ontologies for the particular needs of the infrastructure in our prototype (cf. section 5). Several idiosyncracies of the underlying platform come into play and are formalized accordingly.

4.2 Example

Coming back to our example of indirect permission within an Application Server in section 3.1, we now want to present how using the ontology may support the developer. The Core Ontology of software components introduces self-explanatory concepts like Resource, User, RequestContext or AccessRight. Associations hold between concepts, e.g. grantedForUser between AccessRight and User, definedOnResource between AccessRight and Resource, invokes between Resources etc. Associations can also be defined intensionally, i.e. in the form of axioms. We introduce permission in this way which is true when a User is directly granted an AccessRight on a Resource (the following notation follows the Prolog syntax):

We extend the definition by a second rule to grasp also indirect permission. Rule (2) states that a User u1 is also granted permission on Resource r2 if u1 is granted permission on another Resource r1 which in turn invokes r2, performs a context switch and accesses r2. Note that invokes is defined transitively, i.e. the rule also deduces indirect permissions over longer cascades of invocations:

Applying an inference engine allows us to query for user-resource-pairs that are deduced by the rules above at runtime. We will later demo such a query in our prototype (cf. section 5.4).

5. KAON SERVER

We propose the semantic management of software components and Web Services in an Application Server in order to simplify the development and management of distributed applications. The key idea is to leverage the ontology of section 4 and support developers and administrators in their complex tasks during development-, deployment-, and runtime. This is achieved by integrating ontology infrastructure in the Application Server allowing for reasoning and querying at runtime.

This section presents the rationale underlying our prototype, entitled [KAON SERVER], by presenting its architecture, the choice of the representation language, implementation issues and a multimedia demo of reasoning with indirect permission.

5.1 Architecture

Figure 3 shows the overall system architecture. At the bottom of Figure 3 several potential sources of semantic metadata are depicted. The sources provide input for the framework regarding the semantic management of software components. This includes deployment descriptors (e.g. ejb-jar.xml), Web and Application Server configuration files (e.g. web.xml) or annotations in the source code. The information is parsed and integrated into the ontology as semantic metadata. Both are fed into the inference engine which is embedded in the Application Server itself. The reasoning capability is used by the Application Server's core services (e.g. the Component Loader) and the Admin Console. The latter allows to browse and query the ontology at runtime. Therefore, configurations may be queried, may foresight required actions, e.g. preloading of indirectly required components, or may be checked to avoid inconsistent system configurations - during development as well as during runtime. Thus, our ontology-based approach retains the original flexibility in configuring and running the Application Server, but it adds new capabilities for the developer and administrator of the system. [Oberle, Eberhart et al.]

Figure 3: KAON SERVER architecture.

Regarding the semantic management of Web Services, we assume a web application being built by software components (Servlets or EJBs) that in turn invoke a number of Web Services, i.e. they contain the "wiring" application logic. A Web Service Metadata Collector collects and parses WDSL, BPEL or WS-Policy documents of used Web Services. We might also leverage WS-MetaDataExchange (WS-MEX) - a proposal that enriches each Web Service with standardized methods for retrieving WDSL, XML-Schema and WS-Policy information. The collector integrates the data into the ontology very similarly to the integration of component information. Runtime information stemming from, e.g., load monitors, can be integrated as well. The developer may query the inference engine by using the Admin Console. At the moment we consider both WSDL and BPEL documents whose URLs have to be provided to the Metadata Collector by hand. Other documents and the exploitation of WS-MEX or runtime information are left as future work. [Oberle, Lamparter et al.]

5.2 Representation Language

The ontologies discussed in section 4 are typically heavy-weight, i.e. they feature a rich axiomatization. One has to sacrifice some of the axioms and use a less expressive ontology language in order to allow for runtime reasoning and querying. The reference version of DOLCE, Descriptions & Situations, the Core Ontologies of Software Components and Services as well as the domain ontology are formalized in modal logic S5. As no efficient reasoning algorithm is known for this logic, we had to use a less expressive language and restrain the axiomatization accordingly. Our prototype uses the KAON language which is a variant of Datalog.

5.3 Implementation

The aforementioned architecture is implemented in the KAON SERVER which is part of the KArlsruhe ONtology and Semantic Web Toolsuite (KAON). Our intention was not to develop another Application Server from scratch, but to leverage the wealth of tools provided by KAON and reuse them in an existing Application Server. Hence, we have chosen the open-source Application Server JBoss [Fleury & Reverbel] which provides a very flexible and extensible infrastructure based on the Java Management Extensions (JMX). With JMX it becomes possible to configure, manage and monitor Java applications at runtime, as well as partition applications into components that can be exchanged. Basically, JMX defines interfaces of managed beans (MBeans) which are JavaBeans that represent JMX manageable resources. MBeans are hosted by an MBeanServer which allows their runtime deployment and manipulation. All management operations performed on the MBeans are done through interfaces on the MBeanServer. We deploy our KAON inference engine and ontology store as an additional MBean and augment the existing component loader and dependency management to exploit the inferencing. Like shown in Figure 4, our ontology editor can be used to browse, query and reason with this MBean at runtime. [Oberle, Staab et al.]

5.4 Demonstration

Section 3.1 introduced an example of indirect permission due to context switches in an Application Server. In 4.2, we formally presented how our ontology might assist the developer to control such complicated situations. This section shows how it is accomplished in our prototype. We use the ontology editor of the KAON Toolsuite to browse and query the ontology at runtime. A query can be executed to reveal all indirect permissions of the "Authenticated" user. You might click on Figure 4 to show a audiovisual multimedia demonstration. The code may be downloaded at http://kaon.semanticweb.org/server.

Figure 4: Screenshot of browsing the ontology at runtime.
Click on image to view a multimedia demo.

5. Related Work