Design of a Semantic Service Bus for Networked Enterprises - CiteSeerX

3 downloads 14976 Views 616KB Size Report
or form of the organisations, aimed at sharing the partners' business services. ICT support for creating such short-term organisational alliances (networked ...
Design of a Semantic Service Bus for Networked Enterprises Peter BEDNÁR a, Karol FURDÍK b, Gabriel LUKÁČ a and Tomáš SABOL a a Technical University of Košice, Slovakia b InterSoft, a.s., Slovakia

Abstract. The paper presents the service bus component, as it was designed within the FP7 ICT EU project SPIKE to support the service-oriented communication and message routing in a system for maintenance of short-time and project-oriented business alliances. The interoperability of heterogeneous services and applications provided by the alliance partners is achieved by employing the semantic technologies, namely the WSMO platform and the SA-WSDL extension of web service interfaces. The paper focuses on the architecture and technical implementation of the semantic service bus and other core modules of the SPIKE system for business collaboration. Keywords. Semantic service bus, networked enterprises, business alliances, interoperability of services, semantic business process modeling

Introduction If European enterprises are to succeed in knowledge economy and increased competition implied by the worldwide globalisation, they will have to excel at flexible inter-organizational collaboration. Such an inter-organisational alliance can be understood as a virtual partnership of organisations - without restrictions on their size or form of the organisations, aimed at sharing the partners’ business services. ICT support for creating such short-term organisational alliances (networked enterprises) is the main aim of the SPIKE project funded by the EC within the FP7. In the networked enterprises (which are usually of temporary nature and characterized by quickly varying business environments) business processes need to be organized as intercompany compositions of business processes. In other words, a business process may be composed of key competencies of several companies creating the networked enterprise. The platform to be developed within the SPIKE project must be easy to use, manage, and integrate into an existing environment. The SPIKE solution will encompass a semantically enriched service-oriented infrastructure including an (in this case semantic) enterprise service bus for workflow control, handling and transformation of messages. The Enterprise Service Bus (ESB) is a messaging and communication infrastructure in IT solutions built on the service-oriented architecture (SOA) [1]. It 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 [2]. Technically, the ESB enables loose coupling of interacting systems and enables to distribute the business logic of a solution into incremental, digestible modules, maintaining their own local control and autonomy. A prerequisite for employing the ESB to integrate applications and services in an organization is a specification of a workflow structure modelling particular processes, tasks, actions, flow of information artefacts and messages between the communicating applications. Construction of these workflow-based models is known as a business process modelling (BPM). The BPMN and BPEL notations are nowadays the marketleading and widely accepted standards for designing workflow-based business models on both abstract and executable levels, respectively [3]. However, the ESB infrastructure and the BPM-related notations are both focusing on syntactic specification of interfaces, message exchange, and workflow structures of cooperating applications. Integration based on the meaning, expressed in a machinereadable way, is the current challenge in the ESB-related research [4]. The vision of semantic business process modelling, formulated in [5] and further elaborated, e.g. in the FP6 project SUPER (www.ip-super.org), aims to achieve a higher degree of automation in discovery and mediation of co-operating services. The usage of semantic technologies as Semantic Web Services in the process modelling, 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 BPM lifecycle [6]. The Semantic Service Bus (SSB), as an enhancement of the general ESB, uses semantic description of service capabilities, properties, exchanged information artefacts and requirements on services, enabling automated service discovery, selection, routing, composition and data mediation [2]. Semantically enhanced business process modelling and design of semantic ESB is in focus of several research initiatives, e.g. the Object Management Group (www.omg.org), FP6 R&D projects STASIS (www.stasis-project.net), OPUCE (www.opuce.tid.es), the SUPER project [2, 7] mentioned above. The concept of SSB was also adopted in the SPIKE project (Secure Process-oriented Integrative Service Infrastructure for Networked Enterprises, www.spike-project.eu). The main technological objective of the SPIKE project is to design and develop a platform for inter-enterprise interoperability enabling trustful and effective business collaboration. In comparison with the other approaches, the SPIKE solution puts emphasis on security and usability criteria of the semantically enriched service-oriented infrastructure, which includes the semantic service bus for business process control, semantic mediation, filtering, and transformation of messages exchanged during the process flow. At the level of the user interface, a web portal for maintaining and monitoring the collaborative processes enables to capture users’ working context and transfers it seamlessly to services according to a specified process workflow. The architecture and functionality of the semantic ESB will be described in this paper. In section 1, overall platform functionality, architecture, and distribution of main system modules is described. The service bus module is designed as a communication infrastructure integrating the semantically enriched process workflows and services. Specification of particular service bus components and their interactions, together with a technology framework proposed for the implementation, is presented in section 2. Finally, the paper concludes with brief outline of pilot applications, through which the implemented solution will be tested and evaluated.

1. Architecture and Functionality of the SPIKE platform Based on the project objectives, 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 (setting-up, running, closing down) are supported with respect to the three levels of collaboration:  Collaborative processes that enable to produce physical or intangible artefacts and are modelled 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.

Figure 1. Basic schema of the SPIKE approach towards the networked enterprises

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 artefact. The first step is to define a collaborative value chain, which determines steps and a target of the short-time alliance. The value chain is then expressed as a business process and is formally modelled 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 [5]. The resources and services of participating organizations might then be mediated and integrated according to known and formalized meaning. 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 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. The architecture of the SPIKE platform supporting this functionality [7] was designed in line with the SOA principles as highly modular and extensible. It consists of four main functional subsystems, namely:  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 graphical 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. Each subsystems 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 [8], 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.

Figure 2. Top-level functional subsystems of the platform; managers of the SSB and SSC subsystems

Structure and mutual interactions of all the platform subsystems, the managers designed for the core subsystem and the semantic service bus, are presented in Figure 2. The SSB subsystem, as a central communication channel that handles messaging and data exchange between the individual SPIKE modules, consists of two managers. The Interface Manager mediates an access to the external services and applications provided by the alliance members (cf. the Service layer in Figure 1). It provides basic capabilities for service usage, i.e. for connecting the external services, transmitting the service requests into the SPIKE system, and sending the responses back to the services. The communication protocols are normalized to the XML-based message exchanges. As an extension of the Interface Manager, the Communication Manager provides more comprehensive and powerful transformation, enrichment, and message routing capabilities. It uses the functionality of some of the SSC managers. The Security

Manager is employed for access control, authentication, and authorization, while the data mediation and semantic transformation of the service messages and notifications is performed by calling the Semantic Manager. The authentication mode of the security is related to the Identity Manager responsible for handling individual users’ identities (as credentials or user profiles) and making them available to all the partners in the alliance. This functionality is especially important for the identity federation level of collaboration, since it provides a control and means of accessing the internal infrastructure of alliance partners. The Notification Manager is used as a central hub for notifications generated and consumed within the platform and by its users. It provides alerting, triggering, messaging, and distribution of notifications among the alliance partners, system users and administrators. The Process Manager is responsible for executing the BPEL processes expressed as a workflow of activities and defined for an alliance. It coordinates all the parts involved in the alliance cooperation, i.e. the web services and activities performed by the human actors. The process is defined using the abstract activities, which have to be resolved to the physical services. The discovery and execution of particular services integrated in a workflow is supported by the Service Manager. Internally, the module contains a web service engine that enables accessing the external services via a web service interface. It also provides functions for analysis of the services registered in the platform, namely an estimation of selected Quality-of-Service characteristics as availability, performance, reliability, and capacity [9]. The service discovery is provided in cooperation with the Search Manager, which supports all the searching facets 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 enables manipulation with semantic information in the SPIKE platform. It supports ontology development and maintenance, provides semantic search, matching, mediation, mapping, and reasoning over the semantically enriched data. In addition, it provides means to design abstract BPMN models of business processes, semantic description of process elements and the transformation of the process models to the executable BPEL representation [10]. The employed semantic framework is based on the WSMO platform (www.wsmo.org) and the related WSMO Studio toolkit (www.wsmostudio.org), which provide all the required functionality – creation of abstract business processes by the BPMO modeller, WSML ontology development, ontology repository maintenance, semantic annotation of web services, tasks, and other process elements [11]. More details on the SPIKE approach towards semantic modelling and annotation can be found in [12]. Finally, the Content Manager was designed as a central data storage facility for the whole platform, which interacts with almost all the SSC modules. It is responsible for managing, storing and retrieving all the persistent data presented in and brokered through the SPIKE infrastructure, namely the ontologies, service registrations and descriptions, user sessions, and metadata of the identity management.

2. Technology Framework Employed for the Service Bus Subsystem The SSB acts as the main communication infrastructure between users and external services in a secure collaborative service-oriented environment. The required functionality led us to use a sophisticated, robust and mature framework for the SSB

implementation. Finally, it was decided to build the SSB subsystem upon and design further necessary components around the existing and well-proven JBI specification [13, 14]. This approach allows implementation of the message-based integration of services referenced by a collaborative business process, using the semantically annotated WSDL service interfaces as message routing controllers.

Figure 3. Overview of the JBI architecture adapted to the SPIKE platform

Figure 3 presents an overview of the general JBI-based ESB concept, as it was adapted to the SPIKE platform. The designed JBI-compliant SSB breaks down into the following components:  The Normalized Message Router (NMR) of the Communication Manager, which forms a central messaging backbone of the SSB.  The Binding Component (BC) of the Interface Manager acting as a proxy to a remote service, i.e. it makes remote services available to the SSB in a standardized way - in a form of normalized messages, independently of the service’s actual transport protocol and data format.  The Service Messages Engine (SME) of the Communication Manager provides the business logic during the processing of external services. By wrapping the semantic mediation functionality of the Semantic Manager, 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 SAWSDL annotations of the message elements [15]. The JBI runtime, integrated into the Communication Manager, provides a standardized environment offering the NMR instance in which the SE and BC can be deployed. A specific runtime environment is created for each of the SPIKE collaboration processes. The configuration artefacts 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; Semantic transformation of service requests, as one of the most interesting SSB features, will be described in more detail below. To handle the XSLT transformations, the Message Transformer was designed as a functional component of the Communication Manager. It implements the SME of the JBI framework. Interactions between the SSB JBI environment, the Message Transformer, and the semantic mediation provided by the Semantic Manager module are presented in Figure 4.

Figure 4. Interactions between the JBI environment, Message Transformer and Semantic Mediator

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 providing the requested interface described using the SA-WSDL [15]. 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. The output instances correspond to the output messages described in the SAWSDL 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.

3. Conclusions The SPIKE service bus, presented in this paper, provides basic communication infrastructure for the platform supporting the temporary and goal-oriented business alliances. Employing the semantic service annotation and the JBI-based standardized architecture, it enables the semantic interoperability of heterogeneous services provided by the alliance partners. The proposed service bus and the related platform modules are currently (June 2009) in the phase of implementation. First prototype of the SPIKE platform, which should be available in September 2009, will be tested within the first trial on three pilot applications in business organizations from Austria and Finland. More information on the SPIKE project can be found at http://www.spike-project.eu.

Acknowledgments The SPIKE project is co-funded by the EC within the contract No. 217098. The work presented in the paper was also supported by the Slovak Grant Agency of the Ministry of Education and Academy of Science of the Slovak Republic within the 1/4074/07 Project “Methods for annotation, search, creation, and accessing knowledge employing metadata for semantic description of knowledge”.

References [1] D.A. Chappell: Enterprise Service Bus. O'Reilly Media, Inc., 2004. [2] D. Karastoyanova et al: Semantic Service Bus: Architecture and Implementation of a Next Generation Middleware. ICDE Workshops (2007), 347-354. [3] S.A. White: Using BPMN to Model a BPEL Process. IBM Corporation, February 2005. [4] P. Giangarra, J. DeMeester: Enabling Network-Centric Operations with Semantic Web Technologies. W3C submission, April 2005. http://www.w3.org/2005/04/FSWS/Submissions/14/Paper.pdf. [5] M. Hepp et al: 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 (2005), 535-540. [6] D. Karastoyanova et al: A Reference Architecture for Semantic Business Process Management Systems. Multikonferenz Wirtschaftsinformatik 2008. [7] [WIKT09] K. Furdik, M. Mach, T. Sabol: Architecture of a system supporting business alliances. In: Proceedings of WIKT 2008, STU, Bratislava (2009), 53-57. [8] G. Booch, R.A. Maksimchuk, M.W. Engle, B.J. Young, J. Conallen, K.A. Houston: Object-Oriented Analysis and Design with Applications. Third Edition. Addison Wesley Professional, 2007. [9] L. KangChan et al: QoS for Web Services: Requirements and Possible Approaches, W3C Working Group Note, 25 November 2003. http://www.w3c.or.kr/kroffice/TR/2003/ws-qos/, Retrieved: June 2009. [10] D4.6: BPMO to sBPEL Two Way Translation. Project IST 026850 SUPER, Public Deliverable, 2008. [11] M. Dimitrov, A. Simov, M. Konstantinov, L. Cekov, V. Momtchev: WSMO Studio Users Guide. Ontotext Lab., 2007. http://www.wsmostudio.org/doc/wsmo-studio-ug.pdf. Retrieved: June 2009. [12] K. Furdík, M. Mach, T. Sabol: Towards semantic modelling of business processes for networked enterprises. DEXA EC-Web 09 conference, Linz, Austria, 31.8.-4.9.2009 (accepted for publishing) [13] JSR 208: Java Business Integration (JBI). Final Release 2005. http://jcp.org/en/jsr/detail?id=208, Retrieved March 16th, 2009 [14] JSR 312: Java Business Integration 2.0 (JBI 2.0), working draft 2007. http://jcp.org/en/jsr/detail?id=312. Retrieved: June 2009. [15] Semantic Annotations for WSDL and XML Schema. Recommendation, 28 August 2007. http://www.w3.org/TR/sawsdl/. Retrieved: June 2009.

Suggest Documents