- 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>
Jeff, Daniel Thanks for your help here. Its really appreaciated... Regards Phil Tetlow Senior Consultant IBM Business Consulting Services Mobile. (+44) 7740 923328 Daniel Oberle <oberle@aifb.uni- karlsruhe.de> To Jeff Pan <pan@cs.man.ac.uk> 02/03/2005 04:37 cc Phil Tetlow/UK/IBM@IBMGB Subject 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? Best, Daniel <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 2004]</a></p> <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> <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 step 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. </p>
Received on Wednesday, 2 March 2005 11:34:53 UTC