W3C home > Mailing lists > Public > public-swbp-wg@w3.org > March 2005


From: Phil Tetlow <philip.tetlow@uk.ibm.com>
Date: Wed, 2 Mar 2005 06:34:18 -0500
To: Daniel Oberle <oberle@aifb.uni-karlsruhe.de>, Daniel Oberle <oberle@aifb.uni-karlsruhe.de>, <public-swbp-wg@w3.org>
Message-ID: <OFAC3862E8.16ED6D20-ON80256FB8.003F751C-85256FB8.003F4428@uk.ibm.com>

Jeff, Daniel

Thanks for your help here. Its really appreaciated...


Phil Tetlow
Senior Consultant
IBM Business Consulting Services
Mobile. (+44) 7740 923328

             Daniel Oberle                                                 
             karlsruhe.de>                                              To 
                                       Jeff Pan <pan@cs.man.ac.uk>         
             02/03/2005 04:37                                           cc 
                                       Phil Tetlow/UK/IBM@IBMGB            
                                       Re: SWSE                            

Hi Jeff,
below I pasted a first draft an a pic. Thought three
paras would suffice. Please feel free to change and
adopt. Can you paste it in the document?


<h3>An example: Developing and managing software components in an
ontology-based Application Server</h3>

<p>Application servers provide many functionalities commonly
needed in the development of a complex distributed application. So
far, the functionalities have mostly been developed and managed
with the help of administration tools and corresponding
configuration files, recently in XML. Though this constitutes a
very flexible way of developing and administrating a distributed
application, the disadvantage is that the conceptual model
underlying the different configurations is <i>only implicit</i>.
Hence, its bits and pieces are difficult to retrieve, survey,
check for validity and maintain. To remedy such problems, an
ontology-based approach can support the development and
administration of software components in an application server.
The ontology captures properties of, relationships between and
behaviors of the components that are required for development and
administration purposes. As the ontology is an <i>explicit</i>
conceptual model with formal logic-based semantics, its
descriptions of components 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 run time. Thus, the ontology-based
approach retains the original flexibility in configuring and
running the application server, but it adds new capabilities for
the developer and user of the system.</p>

<p>Figure 1 shows an ontology-based Application Server could be
designed. The left side outlines potential sources, which provide
input for the framework. This includes web and application server
configuration files, annotated source code, or metadata files.
This information is parsed and converted into semantic metadata,
i.e.\ metadata in terms of an according ontology. Thus, this data
is now available conforming to a harmonizing conceptual model,
weaving together so far separated aspects like security, component
dependencies, version or deployment information. The semantic
metadata and the ontology are fed into the inference engine which
is embedded in the application server itself. The reasoning
capability is used by an array of tools at development and at run
time. The tools either expose a graphical user interface (e.g.
security management) or provide core functionality (e.g. the
dynamic component loader). <A href="ref-OESV-2004">[OESV

<img src="appserver.gif"/> <center> System architecture of the
ontology-based Application Server. Semantic metadata and the
ontology are loaded into the inference engine. Value-added
services and tools leverage the reasoning capability embedded in
the application server.</center> </p>

Our approach is supplementary to MDA) where models
abstract from low-level and often platform-specific implementation
details. While MDA allows to separate <i>conceptual concerns</i>
from <i>implementation-specific concerns</i>, currently MDA has
not been applied for runtime relevant characteristics of
component management, such as which version of an application
interface requires which versions of libraries. MDA requires a compilation
preventing changes at runtime which are characteristic for
component management. Besides, an MDA itself cannot be queried or
reasoned about. Hence, there is no way to ask the system whether some
configuration is valid or whether further elements are needed.
This is explained by the lack of formal semantics of the
notoriously ambiguous UML.
Received on Wednesday, 2 March 2005 11:34:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:42 UTC