Web services have become an emergent paradigm for the development of distributed software systems (Gottshalk et al 2002, Wohed et al 2003). Web services provide the means to modularize software in a way that functionality can be described, discovered and invoked in a platform independent manner over a network (e.g., intranets, extranets and the Internet). Notwithstanding the architectural advantages of such a paradigm, the representation of web services by current industrial practice is predominantly syntactic in nature lacking the fundamental semantic underpinnings required to fulfil the goals of the emerging Semantic Web (Berners-Lee et al. 2001).

Within a Semantic Web context, web services require precise semantic representations (Paolucci et al. 2002), normally achieved through the use of ontologies (McIllraith et al. 2001), in order to provide the necessary relationships with domain models and ultimately mappings to the real world objects that such models refer to. As a consequence, syntactic web services already described in languages like the Web Services Description Language (WSDL) (booth and Liu 2005) require semantic transformations and subsequent integration with domain ontologies (Staab et al. 2003).

The de facto standard languages for describing, publishing and invoking web services are currently WSDL, Universal Description, Discovery and Integration (UDDI), and Simple Object Access Protocol (SOAP). Although such languages provide the technical means for achieving cross-platform distributed software deployment (Roe 2003), they are not sufficient to achieve a level of semantic expression necessary for machines to automatically relate web services to other resources and in doing so discover the services required for composing and choreographing the intended behaviour (Sycara et al. 2004). In relation to the Semantic Web and its goals, syntactically defined web services represent legacy applications which need to be conceptually reengineered in order to extract the semantics (i.e., precise meaning) of the intended behaviour and the underlying domain concepts such behaviour utilises. This conceptual re-engineering can be referred to as semantic transformation. The ultimate result of semantic transformation is a set of ontological models which would allow an agent (typically a software agent) to navigate through a semantic network which contains references to all types of web resources including available services (Paar 2003).

As the state-of-the-art stands, the scenario described above is not yet a reality. Web services are primarily adopted in industry as a means to develop architecturally sound information systems. They do not support the necessary semantic precision and “machine-processability” for software agents to automatically navigate through the future Semantic Web and pinpoint those services which can suit specific requirements. As a consequence, web services developed in industry today are mostly syntactic in nature. Such syntactic representations work in a semantically poor environment based on WSDL, UDDI and SOAP, and would not be able to scale up to the requirements of the Semantic Web as described above. More recently serious and important attempts have been undertaken to define languages for semantically representing web services. Initiatives such as OWL-S (Martin et al. 2005) and WSDL-S (Akkiraju et al. 2005) are an important step forward. OWL-S, for example, defines a high level ontology for web services. OWL-S is based on OWL (Web Ontology Language) (Bechhofer et al. 2004) and as such provides the basis for the possible semantic integration between web services and other web resources. In the presence, however, of a vast amount of syntactic web services developed to date, service ontologies like OWL-S are necessary but not sufficient to resolve the problem of how to integrate these technical services within the emerging Semantic Web.

SMISOS ADDED VALUE

A framework for systematically transforming and re-engineering syntactic legacy system process elements into semantic web services is required. A critical component of any re-engineering process is the connectivity between business user ontology and process element provider ontology. Reliant on this connectivity is the infrastructures ability to transform a business oriented requirement language into discovered and coordinated process elements. Furthermore, such connectivity must support the privacy concerns of each partner (e.g. Company A’s private, local ontology may not be accessible to Company B. In order to identify process elements, defined in a domain language by Company B, the distributed processing infrastructure must be able to access Company A’s ontology and perform a remote search.).

SMISOS will use and support international standards such as UML, WSDL, BPEL, XML, EDI and will promote the adoption and elaboration of a business process ontology (to be placed in an ontology library).

SMISOS ’s use of semantic matching algorithms (adding precision to UDDI selection of process elements) will extend the current state of the art by providing support for a network of connected ontologies (e.g. Upper ontology connecting organisation’s local ontologies). The challenge here is to delegate search activities across the network to gain local search precision whilst providing necessary privacy. This will advance current research in this area focusing on optimizing the search through limiting the search scope or applying factors to edges.

The legacy application system will be wrapped into subsystems that enable interoperability with other subsystems in a predefined scenario. A subsystem role (and ontological description) will guarantee the delivery of appropriate system functionality between processing modules - using web service technologies. Subsystems use a document repository to store multi-format documents generated by existing solutions. It will be these documents that form the input into the ontology engineering framework and resulting ontology.

The global coordination activity is performed by a coordination engine and will be able to manage global process specifications. In this context, a SPDF document according to our conceptualization specifies process behaviour and manages document flow among subsystems. The basic functionalities of the engine are represented by two modules: the process interaction module and the message interaction module. The first manages process specifications described using SPDF and is able to manage data and documents to satisfy a specified goal. It is the core of the coordination engine. It uses process specification given by SPDF and manages the interaction between subsystems. At the same time it manages the roles involved in each subsystem and their relationships. A common message schema allows the interaction module to work effectively. Schemas and ontology are stored in a repository (ontology library) that contains all relevant information to identify messages that are used by interaction module to solve inconsistency problems. Moreover, it supports Process Interaction Module managing the schema of messages exchanged among subsystems.

In our setting a shared set of schema/ontology avoid the construction of a static mapping between heterogeneous models. Otherwise, we propose a semantically rich approach where a shared ontology enables interoperability between subsystems. With this solution, documents are annotated with semantic metadata using document ontology. This allows document retrieval starting from a partial specification contained in the SPDF process definition. The interoperation between the Co-ordination engine, document ontology and communication channel will make full use of an element discovery engine. It is worth noting two forms of use (see Figure 1): (1) When an SPDF definition requires one or more process elements, these will be found by the Element discovery engine (and include decomposition) using the document ontology and (2) when new knowledge is extracted from a legacy component (or other multi-format document), it will be distributed across the network by a propagation engine using the communication channel and stored in local document ontology libraries.

Other SPDF related ontology description used in SMISOS project

1. Ontology engineering framework definition

Definition of the document ontology for intelligent documents to describe both the structure of the documents, type of data, information and process needed for their filling. The proposed infrastructure will supports the entire document life-cycle. Definition of ontology infrastructure for persistency, versioning, privacy, updating and reasoning over the knowledge bases in order to realise the SPDF process description.

2. Ontology Propagation Development

Definition, implementation of infrastructure that distributes knowledge (Ontology) around the network. In order to support the privacy concerns of collaborating organisations, as well as network effects, the propagation will distribute links to external ontology where appropriate. The ontology will be used by the server modules development and will utilise the communication channel.