Interprom - A Collaborative Framework Driven by Business Needs - Service Oriented Inter-Organisational Support for Business Processes in Collaborative Environments

There is an increasing demand to support business cooperation between small to medium sized enterprises (SMEs) and major companies. The InterPROM system aims to address this need by providing a serviceoriented, J2EE based collaborative platform. The system is build on top of a custom enterprise services bus (ESB) which can be connected across different organisations. InterPROM characteristics include decentralised replication and locking services, organisation directories divided into private and public sections, an elaborate security system and an application manager for the life cycle management of application instances. A unique feature is its integrated approach to project and workflow management. The InterPROM framework is being developed by a consortium of nine partners and co-founded by the European Union. The commercial lead of the project is with PAVONE AG, a medium sized software vendor specialising in the field of collaborative software environments, knowledge management and CRM solutions. Academic participants are the Universities of Essex (UK), Paderborn (Germany), and Varna (Bulgaria). The European Aeronautic Defence and Space Comp. (EADS) France acts as a pilot user for the project. This paper focuses on architecture and system design aspects of the InterPROM framework. It includes references to underlying technologies such as service oriented architecture (SOA) and J2EE (Java 2 Enterprise Edition) web applications. 1 MOTIVATION AND CONTEXT Knowledge intensive services are often intangible, highly specific and difficult to standardise. Moreover they tend to be required quickly and need to be tailored to the specific requirements of each application. Because of these characteristics, knowledge intensive services are often outsourced to specialised suppliers. This can lead to complex demand and supply configurations such as the following: − Construction projects which require the coordination of architects, environmental advisors, building and maintenance companies, as well as auxiliary service suppliers − Mergers and acquisitions projects, for which buyers and sellers, investment banks, lawyers, chartered accountants, and advising companies have to work together. − Marketing campaigns that are facilitated by market researchers, as well as advertisement and PR agencies. − Research and development projects, business development projects, etc. In addition to the collaboration within projects, SMEs also cooperate with large companies by supplying goods. Driven by the need to customise products quickly in response to customer wishes, new forms of supply chains are emerging where procurers and suppliers form collaborative networks. While such cooperation between SMEs and large companies makes good business sense, it can pose difficult management problems. This is due to the heterogeneity of the partners and their IT infrastructure, the application specific interactions, and the requirement to share resources and to coordinate activities while at the same time taking the autonomy of partners into account. This paper describes a collaborative IT platform aimed at facilitating business processes in interorganisational networks. The system is developed within the InterPROM research project co-funded by the European Union. The project consortium consists of nine partners. The partners responsible for the major parts of the software development activities are the Universities of Essex (UK), Paderborn (Germany), and Varna (Bulgaria) as well as the PAVONE AG in Paderborn, Germany. The European Aeronautic Defence and Space Comp. (EADS) France is the pilot user in the project. 2 SERVICE ORIENTATION The Service Oriented Architecture (SOA) (Bieberstein et al, 2005) is a recent approach to the design of distributed systems. Its defining feature is the provision of well defined, independent IT services offered by service providers. Service consumers access and use these services. A major motivation behind the SOA approach is the prospect for service reuse. The vision is to enable “programming in the large” whereby services can be assembled dynamically (“service orchestration”, “service choreography”) with languages such as WSBPEL (Web Services Business Process Execution Language) (OASIS 2006). The independence of services also aids incremental development and the integration of legacy systems by the use of adaptors. In contrast to earlier approaches like CORBA, SOA relies on loosely coupled and standardized but open protocols independent from particular programming languages. In practice, the invocation of services takes mostly the form of XML based standardized web services. Direct point-to-point connections between service providers and service consumers makes it difficult to enforce binding rules concerning security, Quality of Service (QoS), or the logging and billing of services. Additionally, many applications set further requirements for the IT infrastructure such as support of transactions, asynchronous communication (messaging) and the dynamic detection of services. Such requirements lead to the introduction of an Enterprise Service Bus (ESB, or short service bus) which meets the above mentioned requirements by providing a standardized medium to which services can be bound in order to be located and executed. The core of an ESB is a messaging system which mediates between the service providers and service consumers. In addition, an ESB often also offers supporting services like the transformation of data formats and the controlling and auditing of the network traffic. The flexible integration of heterogeneous components is the main reason for choosing a SOA for the InterPROM system. Based on an analysis of typical InterPROM applications, the decision was made to develop an ESB that uses XML web services and J2EE. This service bus implementation largely follows the guidelines of the Java Business Integration (JBI) (JSR 208) standard (Ten-Hove, Walker 2005). The InterPROM ESB offers additional extensions that are indispensable for the intended application domain: − ESB instances which are in use in different companies (or different departments of one largescale company) can be connected to each other. Thus, applications of one company (or department) that only have access to their own ESB can transparently use services of another company. − The visibility of services beyond the border of the ESB of one company can be limited if necessary. Services can be offered locally (within the domain of only the originating company itself), globally, or within a selected number of other companies who take part in collaborative activity. − The ESB incorporates security mechanisms which perform authentication and authorisation of service requests as well as the encryption of messages. 3 AN ARCHITECTURE FOR THE SUPPORT OF PARTNER NETWORKS The InterPROM system aims to support the collaboration of partners across organisational boundaries. In the following, we will refer to the group of cooperating partners as a partner network. Business Context and Key Requirements At the start of the project, PAVONE AG carried out market research including a survey among its customers. Several key points emerged which have a bearing on the InterPROM architecture: – It has to be easy to set up partner networks and integrate new partners in an existing partner network. – The dependencies between partners should be kept as low as possible. Only information relevant for the joint business activities should be shared. It should not be necessary for partners to disclose sensitive information beyond the scope of the cooperation. – The integration of existing applications at the various partners must be facilitated. In this way, the existence and operation of redundant parallel systems can be avoided. – In particular, large companies often use enterprise level documents management systems (DMS) or enterprise resource planning (ERP). It would be unfeasible for SMEs to run such systems. Therefore connectors are required which enable the collaboration within a project. In this way, the IT requirements of each partner can be kept to a minimum. The priorities attached to these requirements varied between different kinds of companies. For SMEs, the protection of autonomy and control of data was very important. This was less of an issue for the larger companies who typically viewed themselves as hosting and controlling the data. On the other hand, it was especially larger companies who emphasised the need for an easy set-up and management of the system, as they regarded themselves as the initiators and to some extent maintainers of the partner networks. Companies of all sizes viewed the integration with existing applications and legacy systems as a compulsory prerequisite for the introduction of a new collaborative environment. There should be no redundant or parallel processing of tasks and data on existing and new systems. One of the top requirements for the InterPROM platform is therefore the seamless integration with existing