collaborative environment. - AC4: SPIKE Furniture Store, an additional case that was defined as a representative demonstration of the whole SPIKE platform.
A Platform for Semantically Enhanced Business Collaboration of Networked Enterprises Karol Furdik InterSoft, a.s. Florianska 19, SK-040 01, Kosice, Slovakia
Tomas Sabol, Jan Hreno Faculty of Economics, Department of Banking and Investment, Technical University of Kosice, B. Nemcovej 32, SK-040 01, Kosice, Slovakia
Peter Bednar, Gabriel Lukac, Marian Mach Faculty of Electrical Engineering and Informatics, Department of Cybernetics and Artificial Intelligence, Technical University of Kosice, Letna 9, SK-042 00, Kosice, Slovakia
1
Introduction
Flexible and adaptable business collaboration can be considered as an imperative for most of enterprises in the emerging digital and knowledge-oriented economy environment. It is, however, determined by the ability to create and manage an inter-organizational alliance of enterprises and organizations co-operating on a well-defined project. Such a collaboration, which is usually of temporary nature and is characterized by rapidly varying business environments, requires proper technological background enabling interoperable provision and consumption of services between all members of the business alliance. Moreover, business processes in this type of networked enterprises need to be defined, organized and maintained as an inter-company composition of particular processes and services provided by the alliance participants. ICT support for creating such a short-term and project-oriented organizational alliances of networked enterprises is the main aim of the R&D project SPIKE (Secure Process-oriented Integrative Service Infrastructure for Networked Enterprises, http://www.spike-project.eu), co-founded by the European Commission within the 7th Framework Program. The following sections present an approach towards semantic modeling of services and business processes, as it was adopted in the SPIKE project. The focus is specifically given on the approach based on semantic modeling of services, i.e. not all the aspects of the SPIKE platform are covered. For example, the issues of portal-based user interface, distributed authentication mechanism and security management were published separately and are described in (Broser et al, 2010). The here-presented description includes the design and development of underlying semantic structures, ontologies and abstract business models, enabling interoperable service composition in business alliances. The solution employs semantic technologies of WSMO framework (Lausen et al, 2005) and SA-WSDL web service extensions (Farrell &
2
Chapter X – A Platform for Semantically Enhanced Business Collaboration of Networked Enterprises
Lausen, 2007) that support data mediation and enable seamless integration of heterogeneous information resources exchanged between the alliance members. After a brief outline of project objectives and related research achievements, the architecture of the SPIKE system is presented in section 2. Semantic structures, resource ontologies and abstract business process notations, which were developed and included in the SPIKE platform, are described in section 3. Implementation of the solution, namely the core component of semantically enhanced service bus, is presented in section 4. Finally, the testing of the system prototype on an application case of sample collaborative process is outlined in section 5. 1.1
Motivation and Objectives
The concept of interoperability in its technical, organizational, and semantic aspects was identified and emphasized in the European i2010 Action Plan (EU-COM, 2005) as a crucial, cross-cutting task in eBusiness field (Watch report, 2005) as well as in other related areas (EU-COM, 2006). The semantic interoperability, which is a baseline of the SPIKE solution, refers to seamless service invocation, communication, and information exchange in an ICT environment of e-Business solutions based on principles of service-oriented architecture (SOA). According to this approach, the services, which are described (i.e. annotated) by concepts of a standardized and shared knowledge base, can be provided, accessed, retrieved, orchestrated and used in a flexible manner. Inputs, outputs, and characteristics of possibly heterogeneous services can be semantically matched and integrated, which enables a composition of the services into customizable workflow structures. An advanced technology supporting the semantic interoperability in IT solutions built on SOA principles is the Enterprise Service Bus (ESB) (Chappell, 2004). This messaging and communication infrastructure serves as a middleware that can facilitate interoperability of heterogeneous services and applications in an enterprise. By defining standardized service interfaces and message routing, the ESB mediates incompatibilities of communicating applications, orchestrates their interactions, and makes the integrated services available for broad access and re-use (Karastoyanova et al, 2007). Technically, the ESB enables loose coupling of interacting systems and allows to distribute the business logic of a solution into incremental, digestible modules, maintaining their own local control and autonomy. The SPIKE project builds on these principles and encompasses a service-oriented infrastructure including a semantically enhanced ESB for workflow control, handling and transformation of messages. At organizational level, the project objectives are to simplify collaboration between members of a business alliance and to enable outsourcing of parts of the value chain to business partners (and vice versa, offering such parts in a form of services) in short-term business alliances (Furdik et al, 2009). The scientific and technology objectives of SPIKE include research, development, implementation and validation of the components for semantically enhanced business process management environment, which will handle customized reference processes, ad-hoc defined workflows and distributed processes built from generic process fragments. The solution contains a semantic service bus for registering, discovering and contracting services, as well as service message routing and processing capabilities. All these features are addressed and will be presented in more details in the following sections. In addition, the SPIKE project includes technology objectives focusing on security and modular portal-based user interface. The security infrastructure designed for supporting networked enterprises is built on a distributed exchange of authentication and authorization attributes. It provides a functionality of single sign-on across or within organizational boundaries, identity management for accessing applications or information resources of collaboration partners, secure workflow and service access control (Fernandez et al, 2009), (Broser et al, 2010).
Karol Furdik, Tomas Sabol, Jan Hreno, Peter Bednar, Gabriel Lukac and Marian Mach
3
The SPIKE system, produced as the main outcome of the project, is expected to be tested on pilot applications in Finland and Austria. The following application cases (ACs) were defined for the testing of system prototype: -
AC1: Information Hotel that demonstrates the intra-enterprise product development and provides a support for documentation services by means of secure knowledge and content management
-
AC2: Legacy Applications, focused on the creation and management of business alliances, including maintenance of service providers, location and configuration of services, integration into a workflow, as well as the tracking, contracting, and ordering of services.
-
AC3: Identity Federation, which demonstrates the management of user identities in a networked enterprise, namely the maintenance of access rights, credentials, roles, and resources within a collaborative environment.
-
AC4: SPIKE Furniture Store, an additional case that was defined as a representative demonstration of the whole SPIKE platform. It combines the core functionality of the previous three “basic” cases into a virtual example of international furniture store. The focus is given to the creation of collaborative value chain that covers the development of a newly designed product. This process includes the design, evaluation, manufacturing and delivery of the product together with the related documentation. The AC integrates the active usage of legacy applications among alliance partners, federation of identities in a collaborative environment, and the process of documentation management.
The architecture and functionality of the SPIKE platform was designed as a generic solution, which is capable to support business alliances of any domain. However, the defined ACs were taken as a framework determining the scope and focus of the sample data for the system prototype. Namely, the semantic structures were created specifically for all these ACs, as it is described in section 3.2. General design of the semantically enhanced ESB is presented in section 4, while the section 5 describes the adaptation and usage of this very central component of the SPIKE platform to the specific AC. 1.2 Related Research and Background Technologies A prerequisite for employing the ESB in an organization is a specification of a workflow structure that models particular processes, tasks, actions, flow of information artifacts and messages between the communicating applications. Construction of these workflow-based models is known as the business process modeling and is nowadays handled mostly by the BPMN (http://www.bpmn.org) and BPEL (Andrews et al, 2003) standardized notations. However, the ESB infrastructure itself and the notations for process modeling are both focusing on syntactic specification of interfaces, message exchange, and workflow structures. Integration based on the meaning, expressed in a machine-readable way, is the current challenge in the ESB-related research (Giangarra & DeMeester, 2005). The vision of semantic business process modeling, formulated in (Hepp et al, 2005) and further elaborated, e.g., in the EU FP6 project SUPER (http://www.ip-super.org), aims to achieve a higher degree of automation in discovery and mediation of co-operating services. The use of semantic technologies as Semantic Web services in the process modeling, service configuration, execution, monitoring, and analysis is envisioned as a method that can overcome the heterogeneity and incompatibility problems towards the semantically interoperable services. It may also help to reduce the human intervention throughout the
4
Chapter X – A Platform for Semantically Enhanced Business Collaboration of Networked Enterprises
lifecycle of business process modeling (Karastoyanova et al, 2008). The semantic service bus, as an enhancement of the general ESB, uses semantic description of service capabilities, properties, and exchanged information artifacts, enabling automated service discovery, routing, composition and data mediation (Karastoyanova et al, 2007). Semantically enhanced business process modeling and design of semantic ESB is in focus of research initiatives such as, for example, the Object Management Group (http://www.omg.org), European FP6 R&D projects STASIS (http://www.stasis-project.net), OPUCE (http://www.opuce.tid.es), the abovementioned project SUPER (Belecheanu et al, 2007), etc. The concept of semantic service bus was also adopted in the SPIKE project and will be presented in the next sections. The novelty of the SPIKE approach, in comparison to the above-mentioned projects, lays in the design and implementation of lightweighted ESB framework, which is strongly supported by underlying semantic structures. The semantic knowledge base was created according to the generic and reusable methodology that transforms user requirements, provided as textual descriptions of application cases, into a ready-to-use implementation of ontologies and business process models (cf. section 3.2). Consequently, the ESB runtime environment was designed to employ the semantic knowledge base for service mediation and orchestration in workflow sequences, directly focusing on information exchange in short-term business alliances. From the technological perspective, the semantic structures in the SPIKE system are built on WSMO framework (http://www.wsmo.org). It provides means for implementing both ontologies (WSML format, cf. section 3.2.1) and abstract business processes (BPMO representation, see in section 3.2.2). The WSMO Studio (http://www.wsmostudio.org) was used as a general toolkit for design and implementation of all the semantic representations, including the semantic SA-WSDL extensions of services. The semantically enhanced ESB, presented in section 4, is built on the Java Business Integration (JBI) specification (i.e. JSR 208, http://jcp.org/aboutJava/communityprocess/final/jsr208/). The executable BPEL processes, generated from abstract semantically enhanced business process models, are handled by the Intalio BPMS Community Edition solution (http://community.intalio.com), which is described in section 5.
2
Architecture of the SPIKE Platform
Based on the project objectives, which were briefly outlined in section 1.1, the envisioned functionality of the SPIKE system is to provide a technical support for collaboration of business partners with the aim to create a temporary business alliance. Three phases of the alliance life cycle (i.e. setting-up, running, and closing down) are supported with respect to the three levels of collaboration: -
Collaborative processes that enable to produce physical or intangible artifacts and are modeled by means of complex workflow patterns;
-
Sharing services, where the alliance partners can offer their services in the scope of a given business process. The offered services can be retrieved, negotiated, contracted, and finally used by the alliance members according to the conditions specified by the service contract;
-
Identity federation, enabling and mediating the access of an alliance partner to the internal resources or services of other partners.
The approach adopted in the SPIKE project supporting all the mentioned collaboration levels is schematically depicted in Figure 1. Business organizations, presented in the top bar, may decide to form an alliance focused on a production of an artifact. The first step is to define a collaborative value chain, which
Karol Furdik, Tomas Sabol, Jan Hreno, Peter Bednar, Gabriel Lukac and Marian Mach
5
determines particular steps and the main target of the short-time alliance. The value chain is then expressed in the Conceptual Layer as a business process and is formally modeled by the BPMN notation. To enable interoperability of possibly heterogeneous capabilities, knowledge, and capacities of each of the alliance partners, a common and shareable knowledge model is used for enriching the defined business process with semantic information (Hepp et al, 2005). The resources and services of participating organizations might then be mediated and integrated according to known and formalized meaning. On the Service Layer, particular tasks in the process model are then grounded to the executable services provided by the alliance partners. It allows sharing and using the services in the context of a defined process model by authorized organizations. Assuming that some of the services may access or manipulate the internal infrastructure of an alliance partner, identities and credentials necessary for invoking and consuming such a service are distributed to the authorized users in a secure way. The alliance can then operate according to a dynamic process model, which, if needed, may be modified and adapted in the run time.
Figure 1: Basic schema of the SPIKE approach towards the networked enterprises.
The architecture of the SPIKE platform supporting this functionality (Mach et al, 2009) was designed in line with the SOA principles as highly modular and extensible. The methodology of (Rozanski & Woods, 2005) was adopted to identify the viewpoints, perspectives, and stakeholders of the envisioned system. The SPIKE project user partners (IT companies) provided a description of required functionality (Wiesbeck et al, 2008), which was subsequently used as a background for specification of system views and perspectives as well as a platform for the validation of the system design.
6
Chapter X – A Platform for Semantically Enhanced Business Collaboration of Networked Enterprises
2.1 Functional View The high level functional system architecture, schematically depicted in Figure 2, consists of four main functional subsystems: -
The SPIKE System Core (SSC), a back-end providing functions for accessing and processing all the system data, namely the data storage, security, and maintenance of semantically enhanced business processes, workflows, and services;
-
The SPIKE Portal Instance (SPI), a web-based user interface that acts as a front-end to the SSC;
-
The SPIKE Administration, Monitoring and Reporting (SAMR), a subsystem that provides tools for overall system maintenance and day-to-day operation;
-
The SPIKE Service Bus (SSB), an infrastructure that enables internal communication between SSC, SPI and SAMR, as well as the communication with external entities.
Figure 2: Basic schema of the SPIKE approach towards the networked enterprises.
Each subsystem is divided into a set of loosely coupled components, so-called managers providing autonomous and elementary functionality. The design of managers was accomplished according to the methodology of (Booch et al, 2007), trying to balance coupling vs. cohesion and sufficiency vs. completeness metrics. The functional cohesion, i.e. packing functionally related parts into one component, was preferred in the design. Managers integrated into the SSC provide the core functionality of the overall system as follows: -
The Content Manager, a very central component of the SSC, is responsible for storage, retrieval and update of all the data presented in and brokered through the SPIKE infrastructure, namely the ontologies, service registrations and descriptions, user sessions, and metadata of identity management.
-
The security throughout all the processes handled via platform is ensured by the Security Manager, which provides functions of authentication, authorization, auditing, and ciphering.
Karol Furdik, Tomas Sabol, Jan Hreno, Peter Bednar, Gabriel Lukac and Marian Mach
7
-
The authentication mode of the security is strongly related to the Identity Manager, which is responsible for handling individual users‟ identities, credentials or user profiles, and making them available to all the partners in an alliance.
-
The Notification Manager, as a central hub for notifications generated and consumed within the platform, provides alerting, triggering, messaging, and distribution of notifications among the alliance partners, system users and administrators.
-
The Process Manager is responsible for handling and executing processes expressed as workflow sequences of activities defined for an alliance, while the standardized BPEL format (Jordan & Evdemon, 2007) is required for executable processes. Namely, the manager provides supporting functionality such as customization of abstract services and human tasks (i.e. activities performed by human actors) incorporated in the process, deployment, initialization, and running of invoked executable workflows.
The remaining three components of the SSC act on the service level: -
The Service Manager, by means of built-in web service engine, provides discovery and execution capabilities for the services integrated into a workflow.
-
The service discovery is provided in cooperation with the Search Manager, which supports all facets of searching in the SPIKE platform. Besides the discovery of service instances, it includes the metadata-based and full-text search, as well as the semantic matching and filtering.
-
The Semantic Manager handles all the functionality involved in dealing with semantic information, namely the semantic search, matching, mediation, mapping, and reasoning over the semantically described data. Semantic metadata descriptions for business processes, services, and artifacts serving as input and/or output parameters of the services are maintained and provided by the Semantic Manager by means of metadata mapping.
The core system functionality is transmitted to other modules by means of the SSB subsystem. This central communication channel handles messaging and data exchange between the system core, user interface, and administration parts of the SPIKE infrastructure. As depicted in Figure 2, the SSB subsystem consists of two managers, namely: -
The Interface Manager is the only component employed by the other managers to interact with external services. It provides basic capabilities for service usage, i.e. for connecting services and transmitting service requests and responses.
-
As an extension of the Interface Manager, the Communication Manager provides more comprehensive and powerful transformation, enrichment and message routing capabilities. It consumes the functionality of some other managers. The Security Manager is employed for access control, authentication, and authorization for particular services in a given process, while the data mediation and semantic transformation of service messages and notifications is performed by calling the Semantic Manager.
2.2 Information View and Data Elements The information view of the architecture describes the way in which the system stores, manipulates, manages, and distributes information (Rozanski & Woods, 2005). Identification of the information
8
Chapter X – A Platform for Semantically Enhanced Business Collaboration of Networked Enterprises
resources in their mutual relationships, information flows and data distribution was accomplished by analyzing the user requirements provided as descriptions of respective pilot applications (Wiesbeck et al, 2008). It resulted in a design of the main data elements, which is presented in Figure 3. The Process, Workflow, and Task elements are basic building blocks for modeling an alliance of collaborative business processes. The Task element, representing particular workflow actions, is further specified by parameters as inputs, transformations, and outputs. These parameters, consumed and produced by a task in a workflow, are represented by a set of sub-types of the generic and abstract Resource data element. This element defines a common set of properties inherited by all its child data elements, in particular by the resource types such as Document, Service, Report, Message, etc. Properties of these information resources are provided as semantic metadata, defined in an ontology schema. This solution enables to combine the standardized business process modeling with semantic descriptions created according to the Semantic Web principles (Hepp et al, 2005).
Figure 3: Data elements and their structural correlation.
In addition, the information view contains a set of semantic data. It stores and provides both the metadata schema as well as the instantiated data that specify and semantically describe the elements of other information resources. The data elements of Ontology and Metadata are stored as a set of ontologies expressed in a specific ontology format. Finally, the data elements for user management, security, authentication, and global system settings were identified and introduced in the information view schema. The information resources of security and authentication store and manage the data about users, their identities, profiles, preferences, roles, permissions, and access rights as far as needed by the security architecture. The system data, modeled by Settings and Data for Client applications elements, contains all the information needed for configuration of the SPIKE‟s client-side tools, global settings, system and environment properties. The data elements in this information resource are structured and will be stored as metadata in the system ontology or, optionally, in property files of the SPIKE system instance.
Karol Furdik, Tomas Sabol, Jan Hreno, Peter Bednar, Gabriel Lukac and Marian Mach
3
9
Semantic Annotation and Modeling
The SPIKE platform employs semantic technologies to enable interoperability between services and information resources originating from heterogeneous environments of the collaboration participants partners within a business alliance. The ontology, as a common semantic knowledge base and a conceptual model of the given domain, provides a shareable vocabulary of terms that can be used for metadata specification of identified data elements, namely the business processes, services, and information resources exchanged during the collaboration workflow (cf. Figure 3). The semantic enhancement of business process elements and resources gives an opportunity to manipulate with the data according to their meaning. It also enables data mediation, reasoning, and retrieval of the semantically annotated elements and thus contributes to achieving the desired feature of service interoperability. 3.1 A Principle of Semantic Annotation Semantic annotation can be defined as a process of associating raw digital data with some of the ontology concepts, where these associations (i.e. semantic descriptions, annotations) are persistently stored and are formally expressed in a machine-readable way. This process includes identification of data portions being annotated (e.g. words or paragraphs in a text, tasks or activities in a process, etc.), selection of ontology concepts suitable to represent the meaning of the data, and creation of annotations - relationships between the data portions and the selected concepts.
Figure 4: Semantic annotation of a PDF document, an example of information resource.
10
Chapter X – A Platform for Semantically Enhanced Business Collaboration of Networked Enterprises
The process of semantic annotation is schematically depicted in Figure 4. The resource data are represented by a sample PDF document with the identified data portions – text fragments such as titles, names, addresses, numeric values, paragraphs, keywords, etc. The data portions can be specified in the digital source code of the annotated resource artifact. For each of the identified data portions, corresponding concept from an existing ontology can be selected manually or semi-automatically, using a proper annotation tool. The selection of respective concepts can produce instantiated metadata, which are inherited from these concepts, enhanced by the values given by the content of corresponding data portions, and then stored persistently in the ontology. The associations between the instantiated metadata and the data portions are usually stored separately as the semantic annotations of the resource artifact. Business processes, services, and information resources, i.e. artifacts of various types that are produced or consumed by the activities of the process workflow, are the objects that are to be semantically described within the SPIKE platform. The means of the semantic annotation differ slightly for each of these objects, as it is described in the following paragraphs. Business processes, that is, dynamic series of actions performed in a business organization, can be described by an abstract or an executable process model (Andrews et al, 2003). Today‟s market-leading industry standards are BPMN (Roj & Owen, 2003) for visual design of abstract business processes and BPEL (Jordan & Evdemon, 2007) for modeling executable processes. Despite the fact that neither BPMN nor BPEL are “true” semantic structures, they provide a set of pre-defined elements for describing the workflow structure and can serve as a common interpretation base for business processes. That is why these formalisms can be considered as a kind of formal annotation, which is a first step towards the fully featured semantic annotation. The BPMN is a standard for graphical notation, while the BPEL is an XML-based format; the mapping between BPMN and BPEL is not so straightforward (Ouyang et al, 2006). Nevertheless, it is supported by various algorithms that work well on a sub-set of BPMN constructs. The modeling of business processes in the SPIKE platform can thus start with an abstract BPMN, which can then be transformed (e.g. using the BPEL4WS formalization (Andrews et al, 2003) and/or the semantic enhancements of business process elements) into the corresponding executable BPEL form. A business process can be further semantically described by means of available (and customized) ontologies for modeling entire processes, services provided and consumed by these processes, or artifacts manipulated by the process services. The advanced BPMO, sBPMN, and sBPEL ontologies (Hepp & Roman, 2007), provided as outcomes of the EU FP6 project SUPER (Belecheanu et al, 2007), were proposed as basic semantic structures for representing the elements of business processes in SPIKE. This approach allows an integration of the ontology-based representation of business processes with the representation of services and other information resources exchanged in a process workflow, which will be semantically described by means of domain ontologies. A semantically annotated business process is then represented as an instantiated workflow of activities, containing references to the services that consume and/or produce various artifacts as their inputs or outputs. The business process itself can be registered within the SPIKE system as an internal service and can be reused (nested) as a partial activity in another business process (cf. Figure 3). Services are executable actions organized into a workflow and referenced by the business process activities. Several service types can be distinguished according to the accessibility, usability, and possibility of immediate execution, i.e. the web services, electronic services (e.g. web forms, emails etc.; available on-line, but without a web service interface), and conventional asynchronous services (not available on-line). The web services were taken as a reference type for the semantic annotation, assuming that the services of other types will be transformed into this type before the annotation. A semantic
Karol Furdik, Tomas Sabol, Jan Hreno, Peter Bednar, Gabriel Lukac and Marian Mach
11
wrapping, e.g. by providing some textual information that describes an asynchronous service for users or specifies inputs and outputs of an electronic service, is envisioned as a reasonable way of such a transformation. The WSMO-Lite ontology (Vitvar et al, 2008) was identified as a suitable mechanism to annotate the Web services by means of a simple WSDL extension. The set of five WSMO-Lite top concepts is used as a simple vocabulary for basic semantic description of services in a workflow. Additional semantic specifications, applicable on all the service types, are handled by reference and transformation annotations that enhance the WSDL interface components for abstract definition as well as for implementation of services. Consequently, the WSMO-Lite ontology employed in the SPIKE platform enables to integrate an executable WSDL grounding with powerful semantic enhancements of WSMO to support the tasks as service discovery, mediation, composition, and invocation. The artifacts, or information resources, are separate information units that can be required (as inputs or preconditions) or produced (as outputs or effects) by a service. The physical objects as textual documents, multimedia files, reports, messages, etc., are the resource types that will be supported by the SPIKE platform. The data elements that represent these types of artifacts are inherited from the generic Resource data element, as it is depicted in Figure 3. The semantic annotation of such artifacts includes specification of concrete values for a set of common properties, given by the metadata defined in the ontology. A widely accepted standard, as e.g. Dublin Core (http://www.dublincore.org), can be employed for the metadata definition. In addition, the artifacts containing textual information may be annotated by identifying the content units and then describing them semantically (cf. Figure 4), possibly using the support of semi-automatic text mining and information extraction methods. 3.2 Design of Resource Ontologies The semantic annotation requires presence of a common knowledge base, i.e. an ontology that is capable to provide useful metadata specification for all the annotated information types. The structure of resource ontologies designed for the SPIKE platform is based on the identified data elements and information resources (see section 2.2) and includes a separate ontology for business processes, services, and artifacts. Four additional ontologies were specified for modeling the domain- and system-specific information, namely the core, domain, system, and user ontologies. All the ontologies were implemented in the WSML representation and were stored in the central semantic repository maintained by the SSC sub-system of the SPIKE platform. Three resources were identified for development of the overall SPIKE resource ontology, namely: 1.
A conceptual model, which is determined by the selected ontology implementation platform; in case of SPIKE the conceptual model is based on BPMO, sBPMN, sBPEL, and WSMO-Lite ontology platforms;
2.
Existing ontology resources, reused and adapted from available ontology libraries and standards such as, for example, Dublin Core and various domain-specific ontologies;
3.
Requirements formulated by targeted system users, systematically collected, processed, and formalized into the resulting ontology representation.
The first two ontology resources ensure a compliance with external standards and should make the SPIKE platform interoperable with other similar solutions. In addition, the ontology representation of business processes enables to mediate the semantically customized process elements by a common
12
Chapter X – A Platform for Semantically Enhanced Business Collaboration of Networked Enterprises
vocabulary and to employ the reasoning and semantic service discovery across ontologies in a uniform way. As far as the third resource is concerned, the requirement-driven approach (Klischewski & Ukena, 2007) can be employed to capture the information content and quality required by the users for the semantic modeling of a given application case. This approach, originally developed for the e-Government domain, defines a step-by-step procedure for systematic design and formalization of an ontology according to user requirements. We have customized it for the development of ontologies for the business process modeling, assuming the following participants - actors in this process: -
User partners, “owners” of the modeled application case that are able to formulate the user requirements and descriptions of a given domain;
-
Knowledge engineers, responsible for analysis of the application case described by user partners, for identification of key semantic elements as concepts, attributes, relations, constraints, etc., and for creation of a knowledge base capable to model the application case;
-
System developers, responsible for formalization of the resulting ontology structure and content into a proper representation, as well as for the implementation and integration of the ontology into the whole software platform.
The procedure of ontology design takes the information architecture and information quality as the key concepts that should be understood, captured, and modeled according to the user requirements. The information architecture covers an explicit formulation of users‟ information needs, including a selection of proper terminology, labeling of terms, and proper categorization of the extracted information. An adequate information quality of the resulting semantic structures can be supported by effective cooperation of actors during the design, as well as by reusing the existing ontology resources and standards. Knowledge engineers should play a role of mediators and coordinators in the process of ontology development; they should negotiate actively with the user (application) partners to obtain all necessary domain descriptions, which, after proper formalization, can serve for system developers as a suitable and comprehensive input for implementing the resulting semantic content. Particular steps of the ontology design, including the actors involved and outputs generated, are presented in Table 1. Step 1. Identify the information needs Actors: user partners Output: Textual description of the application case. It includes a specification of the activity scenarios and use-cases. Step 2. Identify required information quality Actors: user partners, knowledge engineers Output: Specification of relevant business processes and episodes, co-operating participants (process actors), activities (services), and artifacts. Step 3. Create a glossary of topics and terms Actors: user partners, knowledge engineers Output: Glossary of relevant topics and terms in a table format. The table includes the term name in English, term translations to other languages used in the application case, a description, and notes. Concepts from available external ontologies can be reused to ensure a wider acceptance of the identified terms. Step 4. Create a controlled vocabulary
Karol Furdik, Tomas Sabol, Jan Hreno, Peter Bednar, Gabriel Lukac and Marian Mach
13
Actors: knowledge engineers, user partners Output: Controlled vocabulary - hierarchy of terms, created from the glossary by grouping the terms into the hierarchical subgroups. Step 5. Group and relate terms Actors: knowledge engineers, user partners Output: Ontology-like structure that includes the relations and dependencies between the concepts. The hierarchy in the controlled vocabulary determines the is_a relations; other relation types are derived from the attributes and descriptions that accompany the terms in the vocabulary and glossary. Step 6. Design the resource ontology Actors: system developers, knowledge engineers Output: A formally expressed ontology. In SPIKE, the ontology will be represented in the WSML notation. The meaning of terms and relations of the ontology-like structure is fixed and formalized in the WSML. The resulting expressions are reviewed to validate that their formal meaning reflects the corresponding informal description in the glossary. Step 7. Implementation of the semantics Actors: system developers, knowledge engineers Output: Formal representation of ontology, enhanced by the workflow structures. The "business rules" as input and output specifications, conditional if-then-else expressions, loops, and workflow sequences are added as enhancements of the ontology elements. These enhancements are especially applied to describe a dynamic behavior of services, namely by their choreography, orchestration, and capability interfaces. Table 1: Steps of the ontology design and development procedure, defined according to the requirement-driven approach customized for the domain of business process modeling.
After these seven steps, originally proposed in (Klischewski & Ukena, 2007) for the requirementdriven approach towards ontology modeling, an additional step can be included for practical reasons, that is, to verify and tune the resulting ontology design on real data. Main aim of this verification is to ensure that the designed ontology formalism, created mostly on the user-defined scenarios, will be capable to model all the entities that are necessary for semantic modeling and annotation of the application case. To verify the resulting ontology, the user partners should provide a sample pattern of real data in a format suitable and understandable for all the actors, e.g. as a spreadsheet or a table. Knowledge engineers then may apply the data to the implemented ontology to obtain the mapping between the ontology elements and the data, usually by creating the instances for particular data portions. System developers can then check the mapping and make the corrections. Knowledge engineers then distribute the resulting ontology with mapped data back to the user partners; they are asked to verify the correctness of the representation and to propose the necessary changes. The process iterates until all the actors accept the resulting ontology structure. According to our experience from testing the SPIKE pilot application cases within the Trial 1 (cf. section 5), up to three iterations are sufficient for producing a ready-to-use ontology implementation for a single application domain. In our case, where about six actors participated in each of the application cases, one iteration lasted approximately one month. However, the required effort depends significantly on the quality of descriptions and sample data provided by the user partners, on the efficiency of communication between actors, domain complexity, desired level of accuracy, etc.
14
Chapter X – A Platform for Semantically Enhanced Business Collaboration of Networked Enterprises
Finally, to review the overall quality, usability, and potential of wider acceptance of the resulting ontologies, some of a wide variety of ontology evaluation techniques (Brank et al, 2005) can be applied and used for further improvement after the end of each design cycle. The customization and continual adaptation of ontologies towards modified external conditions can be accomplished according to the method proposed for ontology life cycle management in (Furdik et al, 2009). 3.2.1 Ontology Structure and Content The process of actual ontology development and implementation of WSML ontologies for the SPIKE platform was accomplished in line with the above-described methodology. The requirements of stakeholders involved in a business alliance, i.e. service providers and requestors, were systematically collected, evaluated and formalized into the resulting ontology implementation. All the SPIKE application cases were textually described and analyzed from the perspective of required information needs and information quality. Based on this analysis, key terms were identified in structured textual descriptions and corresponding glossaries were constructed. The terms were grouped into a hierarchical structure, which was formalized by controlled vocabularies. Semantic relations between the terms (e.g. is_a, part_of, has, affects, etc.) were specified and represented in a form of ontology-like structures. To ensure wider compatibility and applicability of the SPIKE resource ontologies, available external ontologies and standards were extensively reused. The implementation of ontologies was determined by the WSMO / WSMO-Lite conceptual framework (Vitvar et al, 2008), proposed as a background semantic platform for modeling both SPIKE ontologies and abstract business process models. The ontologies were implemented in WSML format, using the WSMO Studio toolkit. Particular ontology implementations were specified in three logical groups such as Process-related, System-related, and Domain ontologies. The content of the resource ontologies is as follows: -
Process-related ontologies, which provide conceptual models for semantic description of business processes and their elements such as Process, Task, Service, etc., consist of: -
Business process ontology, a conceptual model of abstract business processes (Dimitrov et al, 2007) and their mapping into the BPEL elements of the corresponding executable process. It is based on BPMO ontology (Belecheanu et al, 2007) providing representations of graphical processes elements, together with sBPMN and sBPEL ontologies containing WSML models of semantic extensions to BPMN and BPEL 2.0, respectively (Jedrzejczak et al, 2008) (Carenini et al, 2008).
-
Service ontology, a structure of concepts enabling semantic description of the services included into a SPIKE collaboration process and referenced by the Task data elements. It consists of WSMO-Lite lightweight ontology for semantic description of Web services (Vitvar et al, 2008) and of ontology that interconnects the service-related concepts with collaboration processes by means of human tasks and available types of online services.
-
Resource ontology, a set of conceptual types that semantically describe physical information resources - artifacts referenced as inputs and outputs within the activities (i.e. services) of a business process. It includes X12 EDI ontology (Foxwog, 2005) of standardized attributes for document interchange, the Dublin Core metadata element set, the SIOC Core ontology modeling online communities (http://rdfs.org/sioc/ns), and an ontology of generic resource types such as Document, Report, Message, Template, etc.
Karol Furdik, Tomas Sabol, Jan Hreno, Peter Bednar, Gabriel Lukac and Marian Mach
-
-
15
System-related ontologies that semantically describe the platform environment: -
Core ontology, a specification of general objects and elements that define a conceptual framework for collaboration environment. It combines the Business Roles and Business Functions ontologies (Filipowska et al, 2008), non-functional properties of WSMO services (Toma & Foxwog, 2006), SKOS classification schemes (Miles & Bechhofer, 2009), and general concepts such as CollaborationObject, Alliance, Contract, Organization, Person, Actor, etc.
-
System ontology, a set of concepts for semantic description of the system data, configuration settings and environment properties of the whole SPIKE platform, its installations and particular client-side tools.
-
User ontology, a representation of all the data related to the SPIKE users. It is based on vCard RDF ontology (Halpin et al, 2006) of basic contact data for people and organizations, as well as the WSMO non-functional properties related to the security and access rights issues (Toma & Foxwog, 2006). The concepts describing the roles identified for external entities that are expected to communicate with the SPIKE system are also modeled within this ontology.
Domain ontologies, which extend the general semantic structure of process-related and systemrelated ontologies towards the SPIKE pilot applications. The domain ontologies provide a domain-specific conceptualization for four application cases: AC1 Information Hotel, AC2 Legacy Applications, AC3 Identity Federation and AC4 SPIKE Furniture Store.
Figure 5: Domain ontology of Information Hotel AC, displayed in the WSMO Visualizer.
16
Chapter X – A Platform for Semantically Enhanced Business Collaboration of Networked Enterprises
An example of the resulting WSML ontology that models the Information Hotel AC is depicted in Figure 5. Majority of presented concepts serves as metadata specification of various properties in the process of documentation management. It namely includes such class concepts as DocProcessFunction, TechnicalDocumentation, DocumentProperty, IDMMetadata, IDMDocument, and their sub-classes. The concepts such as Contract and CollaborativeDocumentProduction model the items in collaborative process of documentation development. Process actors and alliance members are represented by instances of the Company concept. Altogether ten process-related ontologies, nine system-related ontologies and four domain ontologies were implemented. These resource ontologies were published under a single root namespace of http://www.spike-project.eu/ontologies/ and are freely available for further use. 3.2.2 Abstract Models of Business Processes The design of abstract business process models was accomplished in parallel with the development of resource ontologies. User partners, as providers of the specified pilot applications, described the respective application cases in a textual format accompanied by flowchart diagrams of process flow. The provided descriptions were analyzed and subsequently formalized into the standard BPMN notation. It was then implemented into the ontology-based visual BPMO representation of business process models by means of the BPMO Modeler tool of WSMO Studio. The structure of implemented business process models is varying across the application cases. The AC1 Information Hotel has a straightforward value chain defined and this is the reason why this AC is represented by a single and complex process model that integrates all its use cases. The AC4 SPIKE Furniture Store is of similar matter; however, the value chain here is even more complex so that the resulting business process model structure consists of four separate models for each of the AC's use cases. The AC2 and AC3 are more fragmented, they cover particular aspects of the federation of identities and the inclusion of legacy applications into a collaborative process. That is why the respective process models were created separately for individual use cases in these ACs.
Figure 6: Abstract process model for Service ordering use case, AC2 Legacy Applications.
Karol Furdik, Tomas Sabol, Jan Hreno, Peter Bednar, Gabriel Lukac and Marian Mach
17
An example of BPMO model of the Service ordering use case is presented in Figure 6. This use case, which is a core of the AC2 Legacy Applications, is modeled as an interaction between three actors Service requestor, Service provider, and the SPIKE platform. The Service requestor searches for a proper service (by the Service Search sub-process, which is modeled in a separate use case) and prepares an order for the retrieved service that matches with his/her business needs. Afterwards, the order is processed by the SPIKE platform. The Service provider is notified; the contract of usage is generated and forwarded to the requestor. After accepting the contract the service is ready for usage. Optionally, the requestor may negotiate the contract details with the Service provider. The WSMO/BPMO framework employed for creation of abstract business process models determines the format and partially also the location of their implementations. The implemented models are stored in files of WSML format, accompanied with the files containing layout settings (i.e. positions of graphical elements displayed in the BPMO Modeler tool). Internally, the business process models can be seen as separate ontologies, which are composed of instances of the BPMO ontology concepts (Belecheanu et al, 2007). The namespace for these ontologies is implicitly, by the BPMO Modeler tool, set on the http://www.ipsuper.org/ontologies/BPMO/bpmo-1-4-20080109#. Physically, implementations of all abstract business process models of SPIKE ACs are accessible under a single root location of http://www.spike-project.eu/BPmodels/.
4
Implementation of the Semantic Service Bus
Developed semantic structures of ontologies and abstract process models are initial steps towards the orchestrated workflow of interoperable services. To anchor the process model in real services and artifacts, its activity elements such as goal tasks, web service tasks, and manual tasks need to be further specified by grounding the tasks into a concrete WSDL representation of services. The online services obtain the WSDL descriptions inherently, while for offline services (i.e. activities requiring a human interaction, referenced as manual tasks) the description of service properties can be modeled by means of standardized XForms format (http://www.w3.org/MarkUp/Forms/). The inputs and outputs of the services that represent the tasks need to be specified by referencing them to semantic representations of particular artifacts exchanged in the workflow. The Semantic Annotations for WSDL and XML Schema (SA-WSDL) specification (Farrell & Lausen, 2007) was adopted for the semantic description of the web services. SA-WSDL defines XML attributes, which link various WSDL elements to the ontology concepts. It enables specification of the service type or provides a semantic description of the service inputs and outputs. Additionally, SA-WSDL attributes can specify the transformations between the XML messages and the instances used for the semantic data mediation. An automated Semantic Mediator, implemented as an internal module of SPIKE Semantic Manager component, can “lift” the data in one XML format to instances in the shared ontology and then “lower” it to another XML format using the lifting annotation from the first format's schema and the lowering one from the second schema. SA-WSDL is a simple layer over the WSDL so the SA-WSDL attributes can be directly embedded into the WSDL file published by the service provider. WSMO Studio toolkit provides the user interface of SAWSDL Perspective, which allows loading an existing WSDL file and annotating it with the SA-WSDL attributes. The annotated WSDL file is published online and is, together with the corresponding service, automatically registered within the SPIKE system.
18
Chapter X – A Platform for Semantically Enhanced Business Collaboration of Networked Enterprises
The abstract business process with semantically annotated and grounded tasks can be transformed into the corresponding executable form of BPEL notation using the BPMO-to-sBPEL translation mechanism (Cabral et al, 2008) or, alternatively, by means of the Intalio Designer environment (http://www.intalio.com). The executable process workflow can then be instantiated and activated in the environment of ESB, which is, in the SPIKE platform, built on the JBI specification.
Figure 7: JBI architecture adapted to the SPIKE platform.
Figure 7 presents an overview of a general JBI-based ESB, as it was adapted to the SPIKE platform for implementing it in the SSB managers. The designed JBI-compliant service bus breaks down into the following components: -
Normalized Message Router (NMR), a central messaging backbone of the service bus.
-
Binding Component (BC) of Interface Manager, which acts as a proxy to a remote service, i.e. it makes remote services available to the service bus in a standardized way - in a form of normalized messages, independently of the service‟s actual transport protocol and data format.
-
Service Messages Engine (SME) that provides the business logic during the processing of external services. By wrapping the semantic mediation functionality of the Semantic Manager component, the SME transforms normalized XML messages to the ontology instances (i.e. semantic lifting of input data) and transforms the output instances back to the normalized messages (i.e. semantic lowering of the mediated data). These transformations are implemented using the standard XSLT technology. Definitions of the transformation, i.e. the XSL style sheets, are specified by means of the SA-WSDL annotations of the message elements.
The JBI runtime, integrated into the Communication Manager of SPIKE platform, provides a standardized environment offering the NMR instance in which the SME and BC can be deployed. A
Karol Furdik, Tomas Sabol, Jan Hreno, Peter Bednar, Gabriel Lukac and Marian Mach
19
specific runtime environment is created for each of the SPIKE collaboration processes. The configuration artifacts of the service units in such a process will then contain: -
BPEL definitions designed for the process and deployed to the BPEL engine;
-
XForms files providing a user interface for human tasks (i.e. the services that are not automatic but require an interaction with human users);
-
WSDL descriptions of external services orchestrated in the collaboration process, semantically annotated using the SA-WSDL annotations;
-
resource ontologies referenced from the semantic annotations of WSDL files;
-
XSLT transformations used for semantic lifting and lowering of the data to/from the ontology instances in order to mediate the heterogeneous data structure.
Figure 8: Interactions during the semantic transformation of service messages.
Semantic transformation of service requests, as one of the most interesting features of semantically enhanced service bus, will be described in more detail. To handle the XSLT transformations, the Message Transformer was designed as a functional component of the Communication Manager, namely in its Service Messages Engine module. The Message Transformer implements the SME of the JBI framework. Interactions between the JBI environment, the Message Transformer, and the ontology-based mediation provided by the Semantic Manager component are presented in Figure 8. A service requester creates a new message exchange request, sends it to the NRM, which then delivers the request to the Message Transformer. In this exchange, the Message Transformer acts as a service provider and sends the requested interface, described by means of SA-WSDL annotation, to the inner SPIKE infrastructure, namely to the Semantic Manager of SSC. The SA-WSDL of the requested interface contains definitions of the input messages annotated with the sawsdl:liftingSchemaMapping attributes pointing to XSL style sheet for data lifting transformation. The output of the lifting transformation is delivered as a set of instances that semantically represent the input data. The input instances are then sent to the Semantic Manager, which evaluates semantic mappings between the mediated types and infer a set of output instances.
20
Chapter X – A Platform for Semantically Enhanced Business Collaboration of Networked Enterprises
The output instances correspond to the output messages described in the SA-WSDL of the provided interface. Instances are transformed to normalized messages using the XSL style sheet referenced by the sawsdl:loweringSchemaMapping attributes. The Message Transformer then creates a new message exchange(s) with the output messages and sends it to the service provider(s) through the NRM - in this case, the Message Transformer acts as a service requester. The return values of the requests (or fault messages) are handled similarly as the input messages; however, the way of transformation is opposite, i.e. the sawsdl:liftingSchemaMapping of the provided interface is used for data lifting and the sawsdl:loweringSchemaMapping of the requested interface is used to create the exchange results.
5
Platform Testing
Semantic structures and technologies, presented in previous sections, were employed in the implementation of the SPIKE platform prototype. Functional components of the system were created with respect to the overall solution of business collaboration platform, semantically anchored in the structure of developed resource ontologies. The designed abstract process models were semantically annotated, connected with concrete service instances, and transformed into an executable form. The semantic service bus was implemented as a component enabling communication and information exchange between semantically enhanced services operating in the specified workflow. The development of the SPIKE platform prototype was accomplished during the 2nd half of year 2009. The platform prototype was tested in the first trial of pilot applications from January till March 2010. The testing was focused on particular system components, aiming to evaluate the functionality of developed modules. Namely, following features were addressed by the testing procedures: - suitability of ontologies and business process models, both abstract and executable; - interoperability of services (human tasks, electronic or web services) orchestrated in a workflow and communicated via ESB; - identity federation, distribution of access credentials among external applications.
Figure 9: Task specification in Intalio framework.
Abstract BPMO processes, which were created for each of pilot applications, were transformed into the corresponding executable BPEL representation by the Intalio Designer and Intalio Server tools. Both the selected tools belong to the Intalio BPMS Community Edition solution, which encapsulates a toolkit
Karol Furdik, Tomas Sabol, Jan Hreno, Peter Bednar, Gabriel Lukac and Marian Mach
21
for visual modeling of business processes in abstract and executable notation. The Intalio solution provides an execution environment for running these processes and supports the BPEL4people extensions for modeling the services performed by human actors in an off-line mode. The latter feature was especially important, since most of services were modeled as human tasks in the first trial. For example, Figure 9 depicts the Intalio interface for specifying an initial human task requestDocumentation for starting the process of documentation creation in the Information Hotel AC. During the run time, the DocumentationClient process actor, referenced in corresponding workflow pool, will be asked to fill in an introductory form that specifies an initial request for business collaboration. The input form for this human task needs to be specified in the Intalio Designer, using the XForms format. Since the task is already semantically annotated in the abstract business process model, the form entries are generated according to the ontology concepts presented in the semantic description of the task. The requestDocumentation task is annotated by the CollaborationProcess concept from the Business process ontology and by the CollaborativeDocumentProduction concept from the domain ontology. Union of attributes of these concepts provides a list of input entry fields that are populated in the XForms representation of the task, presented in Figure 10.
Figure 10: The input form for a human task.
Online services such as electronic web forms and web services are modeled in a similar manner. In this case, the semantic annotation is already included in WSDL files as the SA-WSDL extension, which is created during the construction of abstract process models and grounded in executable BPEL models. Contrary to the human tasks, there is no need to specify the XForms inputs for online services. Instead, the SA-WSDL representation is employed for seamless exchange of input / output attributes, service parameters and messages. This way, the semantics supports the service interoperability and data mediation for all service types. Besides the basic orchestration of services provided and consumed by business alliance partners, which is assured by the executable workflow in the Intalio Server environment, the trial testing included the portlet-based integration of external legacy applications and the related identity federation. The Siemens DAMEX ©, a toolkit for maintenance of business contracts, was employed as a sample external application within the scope of the Legacy Applications AC. It was included into the SPIKE workflow and was accessed via ESB as an online service. The security environment, developed within the SPIKE system
22
Chapter X – A Platform for Semantically Enhanced Business Collaboration of Networked Enterprises
upon the Shibboleth framework (http://shibboleth.internet2.edu), was employed for single sign-on and federation of identities between the external online services (Fernandez et al, 2009).
5
Conclusions
Evaluation of the first trial of SPIKE pilot applications indicates that the implemented prototype is capable for providing the functionality required by user partners of the project. Namely, the underlying semantic structures, ontologies and abstract process models cover well the scope of pilot applications and can serve as workflow specifications for the respective business alliances. Tests performed on the level of components provide a proof of concept that the designed solution, which is based on semantically enhanced ESB, executable workflow engine, security infrastructure, and portal-based visualization, is suitable for supporting the service interoperability in a business collaboration environment. Overall, the success rate of service discovery and execution, which uses semantic mediation of input and output parameters, highly depends on the quality of underlying semantic structures - ontologies, process models, and SA-WSDL service annotations. After three iterations of the ontology design, we have achieved the success rate 95+%. However, this result was obtained by testing the services and ontologies on the component level only; more precise validation will be performed in the near future on the integrated SPIKE platform. Evaluation of the SPIKE project concept, in addition to testing and validating functionality and technical capabilities, includes also evaluation of the exploitation potential of the project results from a financial perspective. After the first round of the trials, a preliminary estimation of the Return of Investment (ROI) was calculated by one of the user partners for the Information Hotel case. According to this calculation, an estimated ROI is about 15-20% for both the partners of the business alliance (the fact that both the partners of the alliance benefit from the use of the SPIKE platform we found also interesting and important). From the technology perspective, the results of testing the SPIKE components are overall positive, but naturally indicate also a necessity of some further modifications, which will be reflected in further development. The content of domain ontologies will be slightly adjusted towards the actual data, services, and processes of updated pilot applications. The monitoring, reporting, and notification facilities will be added into the business collaboration environment. And finally, the implemented components will be integrated into a unified SPIKE platform. This integration, planned for second half of 2010, should result in a solution that will be applied on pilot applications within the second trial. More information on the SPIKE project and its outcomes can be found at http://www.spike-project.eu.
Acknowledgements The SPIKE project is co-funded by the European Commission within the contract No. 217098. The work presented here was also supported by the Slovak Grant Agency of the Ministry of Education and Academy of Science of the Slovak Republic within the 1/0042/10 Project “Methods for identification, annotation, search, access and composition of services using semantic metadata in support of selected process types”.
Karol Furdik, Tomas Sabol, Jan Hreno, Peter Bednar, Gabriel Lukac and Marian Mach
23
References Andrews, T., Curbera, F., Dholakia, H., Goland, Y., Klein, J., Leymann, F., Liu K., Roller, D., Smith, D., Thatte, S., Trickovic, I., Weerawarana, S. (2003). Business Process Execution Language for Web Services. Ver. 1.1. IBM developers‟ library. Belecheanu, R., Cabral, L., Domingue, J., Gaaloul, W., Hepp, M., Filipowska, A., Kaczmarek, M., Kaczmarek, T., Nitzsche, J., Norton, B., Pedrinaci, C., Roman, D., Stollberg, M., Stein, S. (2007). Deliverable 1.1: Business Process Ontology Framework. Project IST 026850 SUPER, Public Deliverable. Booch, G., Maksimchuk, R.A., Engle, M.W., Young, B.J., Conallen, J., Houston, K.A. (2007). Object-Oriented Analysis and Design with Applications. Third Edition. Addison Wesley Professional. Brank, J., Grobelnik, M., Mladenic, D. (2005). A survey of ontology evaluation techniques. In Proc. of the Conference on Data Mining and Data Warehouses, SiKDD, Ljubljana, Slovenia (pp. 166-169). Broser, C., Fritsch, C., Gmelch, O. (2010). Towards Information Security Management in Collaborative Networks. In Proc. of the International Workshop on Visualization and Information Security Management (VISM) in cooperation with the DEXA conference, Bilbao, Spain, August 30 - September 3, 2010 (to appear). Cabral, L., Norton, B., Nitzsche, J., van Lessen, T. (2008). Deliverable 4.6: BPMO to sBPEL Two Way Translation. Project IST 026850 SUPER, Public Deliverable. Carenini, A., Nitzsche, J., van Lessen, T. (2008). Deliverable 4.7: sBPEL to BPEL4SWS Lifting and Lowering. Project IST 026850 SUPER, Public Deliverable. Chappell, D. A. (2004). Enterprise Service Bus. Sebastopol, CA: O‟Reilly Media, Inc. Dimitrov, M., Simov, A., Konstantinov, M., Cekov, L., Momtchev, V. (2007). WSMO Studio Users Guide. v. 1.27. Ontotext Lab. EU-COM, (2005) i2010 - A European Information Society for growth and employment (on line). COM 2005, 229 final of 1 June 2005. (cit. March 23, 2010). Available at http://ec.europa.eu/information_society/eeurope/i2010/. EU-COM. (2006) Interoperability for Pan-European eGovernment Services (on line). COM 2006, 45 final. Brussels : European Communities, 13.2.2006. (cit. March 25, 2010). Available at http://ec.europa.eu/idabc/servlets/Doc?id=24117. Farrell, J., Lausen, H. (2007). Semantic Annotations for WSDL and XML Schema (on line). W3C recommendation, 28 August 2007. (cit. May 16, 2010). Available at http://www.w3.org/TR/ sawsdl/. Fernandez, C., Fernandez, G., Ramirez, M.A., Troya, J.M. (2009). D7.3 Implementation of Security Components for Service Bus Sub-System. Project FP7-ICT-217098 SPIKE. Public Deliverable. Filipowska, A., Hepp, M., Kaczmarek, M., Kowalkiewicz, M., Markovic, I., Starzecka, M., Stolarski, P., Todorova, P., Walczak, A., Zhou, X. (2008). Deliverable 1.2: BP Oriented Organizational Ontology. Project IST 026850 SUPER, Public Deliverable. Foxwog, D. (ed.) (2005). D27 v0.1 EDI Ontology (on line). WSMX Working Draft, 21 June 2005. DERI. (cit. May 16, 2010). Available at http://www.wsmo.org/TR/d27/v0.1/20050621/. Furdik, K., Mach, M., Sabol, T. (2009). Towards semantic modelling of business processes for networked enterprises. In EC-Web 2009, Linz, Austria, September 2009. Proceedings. Lecture Notes in Computer Science, Volume 5692/2009, Springer Berlin / Heidelberg (pp. 96-107). Giangarra, P., DeMeester, J. (2005). Enabling Network-Centric Operations with Semantic Web Technologies (on line). W3C submission, April 2005. (cit. May 16, 2010). Available at http://www.w3.org/2005/04/FSWS/Submissions/14/Paper.pdf. Halpin, H., Suda, B., Walsh, N. (2006). An Ontology for vCards (on line). 14 November 2006.(cit. March 16, 2010). Available at http://www.w3.org/2006/vcar/. Hepp, M., Leymann, F., Domingue, J., Wahler, A., Fensel, D. (2005). Semantic Business Process Management: A Vision Towards Using Semantic Web Services for Business Process Management. In Proc. of the IEEE ICEBE 2005, October 18-20, Beijing, China (pp. 535-540). Hepp, M., Roman, D. (2007). An Ontology Framework for Semantic Business Process Management. In Proc. of Wirtschaftsinformatik 2007, Karlsruhe, Germany (pp. 423-440).
24
Chapter X – A Platform for Semantically Enhanced Business Collaboration of Networked Enterprises
Jedrzejczak, A., Filipowska, A., Starzecka, M., Stolarski, P., Walczak, A., Wecel, K., Domingue, J. (2008). Deliverable 4.5: sBPMN and sEPC to BPMO Translation. Project IST 026850 SUPER, Public Deliverable. Jordan, D., Evdemon, J. (eds.) (2007). Web Services Business Process Execution Language Version 2.0. OASIS Standard, 11 April 2007, (cit. May 16, 2010). Available at http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html. Karastoyanova, D., van Lessen, T., Nitzsche, J., Wetzstein, B., Wutke, D., Leymann, F. (2007). Semantic Service Bus: Architecture and Implementation of a Next Generation Middleware. In Proc. of the 2nd International Workshop on Services Engineering 2007 (SEIW), ICDE Workshops, IEEE (pp. 347-354). Karastoyanova, D., van Lessen, T., Leymann, F., Ma, Z., Nitzsche, J., Wetzstein, B., Bhiri, S., Hauswirth, M., Zaremba, M. (2008). A Reference Architecture for Semantic Business Process Management Systems. In Multikonferenz Wirtschaftsinformatik 2008. Berlin : GITO-Verlag (pp. 1727-1738). Klischewski, R., Ukena, S. (2007). Designing Semantic e-Government Services Driven by user Requirements. In Electronic Government, EGOV 07 conference. Proc. of ongoing research, project contributions and workshops. Linz, Austria : Trauner Verlag (pp. 133-140). Lausen, H., Polleres, A., Roman, D. (eds.) (2005). Web Service Modeling Ontology. W3C Member Submission, 3 June 2005. (cit. May 16, 2010). Available at http://www.w3.org/Submission/WSMO/. Mach, M., Bednar, P., Furdik, K. (2009). Support for Forming Temporal Business Alliances as Networked Enterprises. In Proc. of CECIIS 2009. Varazdin, Croatia : University of Zagreb, Faculty of Organisation and Informatics (pp. 179-186). Miles, A., Bechhofer, S. (2009). SKOS Simple Knowledge Organization System Reference (on line). W3C Recommendation 18, August 2009. (cit. March 16, 2010). Available at http://www.w3.org/TR/skos-reference/. Ouyang, C., Dumas., M., ter Hofstede, A.H.M., van der Aalst, W.M.P. (2006). From BPMN Process Models to BPEL Web Services. In Proc. of International Conference on Web Services (ICWS „06), Chicago, IL, IEEE Computer Society (pp. 285-292). Roj, J., Owen, M. (2003). BPMN and Business Process Management. Popkin Software Rozanski, N., Woods, E. (2005) Software Systems Architecture. Working with Stakeholders Using Viewpoints and Perspectives. Addison Wesley Toma, I., Foxwog., D. (2006). D28.4 v0.1 Non-functional properties in Web services (on line). WSMO Final Draft, 25 October 2006. (cit. March 16, 2010). Available at http://www.wsmo.org/TR/d28/d28.4/v0.1/ Vitvar, T., Kopecky, J., Fensel, D. (2008). WSMO-Lite: Lightweight Semantic Descriptions for Services on the Web. WSMO Deliverable D11, Ver.0.2. DERI. Watch report. (2005) e-Business Interoperability & Standards: A Cross-Sector Perspective and Outlook (on line). European Commission, Enterprise & Industry Directorate General. Special e-Business W@tch report. Brussels : Sept. 2005. Available at http://www.ebusinesswatch.org/studies/special_topics/2005/documents/TR_2005_Interoperability_III.pdf Wiesbeck S., Alanko, S., Fritsch, C., Gmelch, O., Kantojarvi, U., Ogris, W., Palola, I., Possegger, A., Stopper, A., Vogler, H. (2008). D2.2 User requirements analysis & development/test recommendations. Project FP7-ICT-217098 SPIKE. Public Deliverable.
