- Email: [email protected]
Supporting collaborative engineering using an intelligent web service middleware
Advanced Engineering Informatics 22 (2008) 431–437
Contents lists available at ScienceDirect
Advanced Engineering Informatics journal homepage: www.elsevier.com/locate/aei
Supporting collaborative engineering using an intelligent web service middleware Lutz Schubert *, Alexander Kipp, Bastian Koller HLRS – University of Stuttgart, Intelligent Service Infrastructures, Nobelstrasse 19, 70569 Stuttgart, Germany
a r t i c l e
i n f o
Article history: Received 18 April 2008 Accepted 12 May 2008
Keywords: Virtual Organisations TrustCoM project BREIN project Service oriented architecture Artificial intelligence Grid
a b s t r a c t Collaborative Engineering tasks are difficult to manage and involve a high amount of risk – as such, these tasks generally involve only well-known pre-established relationships. Such collaborations are generally quite static and do not allow for dynamic reactions to changes in the environment. Furthermore, not all optimal resource providers can be utilised for the respective tasks as they are potentially unknown. The TrustCoM project elaborated the means to create and manage Virtual Organisations in a trusted and secure manner integrating different providers on-demand. However, TrustCoM focused more on the VO than on the participant, whereas the BREIN project is now enhancing the intelligence of such VO systems to support even providers with little business expertise and provide them with capabilities to optimise their performance. This paper analyses the capabilities of current VO frameworks on the example of TrustCoM and identifies the gaps from the participant’s perspective. It then shows how BREIN addresses these gaps. Ó 2008 Elsevier Ltd. All rights reserved.
1. Introduction Modern day engineering tasks typically demand a complexity not supported by individual companies – accordingly, enterprises join in collaborations to outsource and distribute tasks according to the requirements that need to be fulfilled. Whilst the overall costs are reduced this way, such collaborations are normally difficult to manage considering their size and complexity [10]. In recent years, the concept of Virtual Organisations has been developed to describe collaborations using resources exposed to the internet. Following the grid concept, this allows for managed and dynamic collaboration between different resource types, or in other words to enable transactions between different companies in a coordinated manner [7–9]. The TrustCoM project has delivered a framework, as well as a reference implementation that enables organised and contract managed collaborations in a secure and trusted manner. Even though TrustCoM principally allows for dynamic on-demand creation of Virtual Organisations, as well as their autonomous management according to predefined collaboration description, the project does not support all issues to ensure full uptake by the eBusiness community. This paper examines TrustCoM in view of one of its particular application scenarios, namely the ‘‘CE scenario”, in which different companies participate in a Virtual Organisation to adapt the design of an airplane according to a specific customer’s personal requirements. Basing on this scenario, we will examine in how far Trust* Corresponding author. Tel.: +49 0 711 685 87262; fax: +49 0 711 685 77262. E-mail address: [email protected] (L. Schubert). 1474-0346/$ - see front matter Ó 2008 Elsevier Ltd. All rights reserved. doi:10.1016/j.aei.2008.05.002
CoM actually supports the individual participants in their task of supporting the VO requirements and thereupon elaborate the gaps that the recently started IP project BREIN is addressing. 2. An assured environment for collaborative engineering: The TrustCoM approach The main goal of the TrustCoM project consisted in providing a framework that would allow integration of any type of resource provider exposing their capabilities over the web, in order to form collaborations that meet specific business needs and goals. The framework makes extensive use of web service standards so as to allow common uptake from both larger and smaller companies, respectively individuals. The framework ensures that all transactions within the Virtual Organisation are secured and that confidentiality issues are fully respected so that partners may remain anonymous, if so desired. Furthermore, as shall be detailed below, it allows participants to maintain their own infrastructure and their own means to realise the ‘‘products” they provide to a collaborative engineering task. As one of the first projects, TrustCoM also extensively researched the influence and relationship of legal and trust issues on framework specific structures and their implementation. By that, TrustCoM allows for contractual support as well as selection of partners on basis of their performance in other collaborative tasks. Contractual performance is enforced through means of service level agreements that monitor behaviour and evaluate it with respect to the contractual agreements. Accordingly lacking performance can be identified in time and dealt with accordingly
432
L. Schubert et al. / Advanced Engineering Informatics 22 (2008) 431–437
Virtual Organisation
Participant
Participant
Task Task
Preparation
Task Role1
Interaction
Task
Role2
Task Task
Formation
Operation
Dissolution
Fig. 1. Abstract entities in TrustCoM’s Virtual Organisations.
Evolution
– depending on the overall requirements, this can consist in applying fines or even complete replacement of the partner, if this lack of performance is considered critical for the full execution of the collaborative tasks. The legal aspects of the collaboration and thus of the validity of the SLA are defined through a ‘‘General VO Agreement” (GVOA) that basically represents the contractual basis of electronic collaborations [4].1 The project consortium consisted of 16 partners from industry and academy with British Aerospace (BAE), IBM and SAP being actively involved in collaborative engineering tasks as part of their overall business. The scenario discussed below was basing on actual engineering problems by BAE. Their main purpose consisted in bringing the concepts of Virtual Organisations to improve dayto-day business tasks in complex collaboration setups. 2.1. ‘‘Abstract entities” TrustCoM’s main achievement in bringing Virtual Organisations closer to modern day business needs consisted in particular in introducing the concepts of ‘‘abstract entities” to the Grid and Web Services community. As opposed to the classical approach, where each actual resource maintained by the individual enterprises is exposed as a service of its own, be it humans, printers, computers or actual applications and utilities, the ‘‘abstract entities” approach foresees that each participant in a Virtual Organisation is actual a conglomeration of individual resources that are executed and linked in a coordinated manner (cf. Fig. 1): in principle this means nothing else but that service providers execute their normal workflows (as part of their day-to-day business, such as e.g. the manufacturing chains) and provide the results of these processes as their actual capabilities. Regarded from the outside, this is identical to interaction with a single resource that can fulfil a very complex task – this way, participants are considered real business entities, with their own typical workflows to generate the ‘‘products” they sell and with an infrastructure they do not want to expose to, let alone be controlled by external bodies. From the TrustCoM perspective, enterprises participate in a Virtual Organisation according to the roles they bring in rather than according to their resources. This respects the first main issues in (electronic) business: the confidentiality of the providers’ business intelligence, including infrastructure setup, workflow details, etc., and leaving complete control over resources, infrastructure, etc. in their hands. This also reduced the complexity of the overall management tasks that typically had to be executed by the contracting party that sets up the collaboration. 2.2. Managing the virtual organisation Classical Grid VO approaches described the whole collaboration as a series of tasks executed by the individual resources as exposed 1 For more details on the framework structure as realised by the TrustCoM project, please refer to [1].
Fig. 2. Typical phases in the VO Lifecylce.
by the participants, i.e. a sequence of simple invocations, where each invocation is provided directly by individual machines, rather than reflecting a complex business process. With actual enterprises participating in the Virtual Organisation, i.e. with them representing abstract entities that do not allow manipulation of their individual resources, such an approach is obviously not feasible anymore. Instead, TrustCoM describes the collaboration as interactions between roles in a choreography across organization boundaries as defined e.g. by WS–CDL [17]. Since collaborations may lose individual participants during execution, be it due to actual loss of connection, due to violation of the contractual terms or related issues, such choreography and the according list of role providers needs to be carefully maintained by the Virtual Organisation. To this end, TrustCoM provides the VO Management structures that manage participants, as well as their roles in the collaboration and enacts the relevant tasks to maintain the VO structure. In principle, the TrustCoM management structure has the task of steering all participants involved in the collaborative setting through the lifetime of the VO in order to fulfil the collaborative purpose. The lifetime and dynamics of a Virtual Organisation can thereby be denoted by the lifecycle phases as depicted in Fig. 2 (cf. [2,15]): the VO is formed (Formation) by contacting individual providers and taking the necessary configuration steps to set up the collaboration (Preparation); the actual tasks according to the collaboration description are executed (Operation); during operation, some changes in the overall goals, respectively the availability of individual participants may lead to restructuring of the VO (Evolution); and finally, once the VO is not needed any longer, it is dissolved (Dissolution). Of particular interest is the fact that TrustCoM also considers steps prior to actually forming a Virtual Organisation, such as configuring the local business process, describing the results (the ‘‘product”, see above) and advertising it on the market (Preparation). 3. Applying virtual organisations: The collaborative engineering scenario It has already been noted that TrustCoM specifically aimed at simplifying the overall processes in a complex distributed engineering task, as represented by British Aerospace. This particular application scenario consisted in an engineering consortium (here ‘‘CE VO”) collaborating with a team of airplane analysts (‘‘Analysis VO”) to support the tasks of an airline manufacturer that e.g. wants to extend the capabilities of an airplane to host internet capabilities on-flight to fulfil customer demands (cf. Fig. 3). We can thereby clearly depict a customer (Airline VO) which also acts as the main data provider, i.e. providing the airplane design. Providers realising abstract services consist in the design team that update the airplane design according to the requirements specified and therefore
433
L. Schubert et al. / Advanced Engineering Informatics 22 (2008) 431–437
Airline VO AnalysisVO Updates
Product ConfigStorage Provider
Aircraft Maintenance
Contracts maintenance to
Analysis Team Analysisis Analys Provider
Uses
Maintains Accesses product database, sends reports to
Owns
Analysis alysis S/W HoAnalysis S/W Provider
Airline Aircraft
Uses
HPC Provider
Delivers sub-system design to Stores results to
CE3 VO Uses analysis services from Resource Planning Sub-system provider Sub-system Design Team
Storage Provider Production Facilities Production Consultants Consultants Product design database
Populates design database
Buys storage from
Fig. 3. Actors in TrustCoM’s CE Scenario.
use the support of the analysis team which validates the design against structural and technical requirements. The overall process may be enhanced through using an additional storage provider to maintain the huge amount of data created during design and analysis. It has to be noted here, that the so-called VOs in this scenario are actually the abstract entities as described in the preceding section, i.e. collaborations that exist prior to the actual VO as supported by the TrustCoM framework. These ‘‘sub-VOs” represent business entities in their own right, as they sell aggregated products and deal with their own customers, independent of the overlying airline VO of the presented case.2 The TrustCoM framework enables such collaboration by providing a secure and contract managed middleware that enables the individual participants to expose ‘‘virtual” resources that reflect the capabilities of the respective local, organisation-specific and private business processes. The framework allows participants to host an interface that secures message exchange, controls access according to the overall collaboration description and ensures that the according transaction requirements are met and automatically updated. The individual participant is thereby provided with a means to interact with other roles in the collaboration, as if they would be static instances, non-regarding potential changes in the VO structure. The TrustCoM project promotes (but does not restrict itself to) a business model consisting of a single main contractor that binds all participants legally and aggregates them so that they form a single unit (cf. above). Accordingly, each party is liable against this main contractor only and not, as in classical approaches, against each other, depending on the collaborative relationships.
2 Hierarchies of collaborations such as the one presented here reflect the actual business world of main contractors and subcontractors: typically, commercial service providers already realise their capabilities through a set of (static) collaborations and subcontracts of which the customer is not even aware. The TrustCoM model supports such hierarchical relationship models by encapsulating virtual collaborations as if they would be single business entities that again can participate in other Virtual Organisations (cf. [1]).
TrustCoM thus greatly reduces the management overhead typically associated with such scenarios.3 4. Ready for eBusiness 2010? The TrustCoM project provides all the relevant features to relieve business providers from the burden of complex and in particular costly adaptations of the infrastructure so as to meet individual customer’s demands whilst maintaining security and access right restrictions. It also ensures that dynamicity is ensured without impact on the individual participants and that the risk of participation is reduced through means of contractual binding, sensible responsibility distribution and SLA support. However, TrustCoM cannot relieve the participants from the burden to understand the system and to prepare their infrastructures so as to meet the according requirements, respectively to deploy and configure the TrustCoM middleware. As such, business providers need to understand the service level agreement language, in the sense of being able to interpret the customer’s requirements, as well as being able to relate them to a configuration of the infrastructure that respects his/her business policies and, obviously, the capabilities and availabilities of the resources involved. They furthermore need to be capable of reading and understanding the policy descriptions they subscribe to as part of their contracts: even though the GVOA comes in human readable form, negotiation of its details requires translation back into machine terms. With encapsulation of the infrastructure comes the price of more complex relationships between exposed methods and actual resource setup, respectively business process description. Since such descriptions are still relatively inflexible, according adaptations are generally time and budget consuming. Similarly on the customer level, the initiator of the VO will have to have a good grasp on enactment of complex collaborative tasks, in order to define the initial collaboration descriptions and, what is more, to
3
A more thorough discussion of this scenario can also be found in [3].
434
L. Schubert et al. / Advanced Engineering Informatics 22 (2008) 431–437
define the individual requirements per role. Non-regarding that this task has been simplified with the introduction of aggregating roles instead concrete resources,4 the task still remains very difficult and requires according expertise, which an average customer will not possess. Since furthermore the TrustCoM system does currently not realise any intelligent, or even semantic matching, description of service capabilities will have to be in a way (theoretically) conformant between different providers, so that the exposed functionalities match the ones described in the collaboration description. As such, TrustCoM must be regarded as a great step towards providing business providers with a framework that supports their business needs from a technical perspective, yet it could not cater for specific needs that would allow ‘‘business agnostic” providers and/or customers, i.e. people that do not bring in the expertise of handling such a complex system, to make full use of the collaboration middleware. With smaller to medium enterprises being a particular focus of the Virtual Organisation support, the TrustCoM middleware runs the risk of being yet too complicated for fast uptake, non-regarding the simplifications achieved by this project. TrustCoM can hence only be an intermediary step towards reaching the actual end-user, be it SME role provider or customer.
Customer & Business Interactions Define Individual Business Goals Control
Fulfill Semantic Description
Agents Grid
Configure/Execute
Processes & Supply Chains
5. Filling in the gaps: The BREIN approach Whilst TrustCoM significantly reduced the complexity of managing and maintaining distributed collaborative tasks, it still requires a high degree of technical understanding of the individual parties wanting to participate in such collaborations, respectively wanting to expose TrustCoM-conformant services. The BREIN project is loosely coupled to TrustCoM and extends the achievements of the latter with a particular focus on the human behind the system. It pursues three main goals: Supporting the business providers in all tasks related to exposing and integrating his/her capabilities into a Virtual Organisation. Supporting the customer in getting the capabilities and services he/she needs. Optimising the behaviour of both the whole VO and the individual participant in a way that allows for everybody’s demands best without disrespecting according corporate policies. As such, BREIN is one of the first ICT projects that is focused on addressing the whole requirements of enterprises to participate in Virtual Organisations (cf. Fig. 4), i.e. by enhancing the pure technical level according to human needs. As opposed to TrustCoM, the project does not look into the legal aspects involved in VO enactment and does not intend to extend the issues related to measuring individual participant’s trustworthiness. With this respect it builds upon existing results (such as by TrustCoM), which is in fact one of the main goals of the project – to foster existing results and to avoid a start from scratch. The BREIN project brings together a consortium of 16 partners from industry and academy with a strong focus on solving distributed tasks in a collaborative manner. In particular ANSYS, BOC and Elsag Datamat show strong interest in realising distributed collaborative engineering tasks in a more efficient manner. The revisited CE scenario (Chapter 5.2 below) is basing on the analysis of the ‘‘Virtual Engineering” scenario [11] as maintained in the BREIN project by ANSYS.
4 ‘‘Roles” reflect a higher degree of abstraction than concrete resources do: as such, it is up to the individual provider to specify the details of resource usage, whilst the VO initiator ‘‘just” needs to specify what capability is required at what point in time.
Fig. 4. An overview over the technologies in the BREIN project.
5.1. The BREIN framework The BREIN framework builds strongly upon Web Service technologies and incorporates existing VO middleware solutions, as well as communication standards and specifications that promise (or already found) wide acceptance by the research and eBusiness community. Thus, it will realise a service oriented architecture that integrates the most relevant aspects related to supporting and realising Virtual Organisations applicable to real business world scenarios. With a significant relationship between Grid and Agent technologies [5] the BREIN project focuses on extending common grid technologies with the autonomy and negotiation capabilities of Multi-Agent approaches and thus implicitly extending Multi-Agent technologies with the stability, reliability and extensibility of the Grid. With respect to modern day eBusiness requirements, the BREIN consortium identified in particular the following technical areas as most important for future VO middleware needs (cf. Fig. 5): Infrastructure capabilities represent the most classical Grid functionalities, namely to allow for standardised messaging in different
Fig. 5. Framework structure of the BREIN project.
435
L. Schubert et al. / Advanced Engineering Informatics 22 (2008) 431–437
environments, as well as the encapsulation and publication of service capabilities (cf. Section 2.1 ‘‘Abstract Entities”). The full VO middleware is based upon such infrastructure capabilities to provide a common messaging platform. Semantic web technologies ensure that information about participants and their products are commonly understood, even though their details (such as capabilities) are defined by humans and thus subject to great variations between each other – this also allows more flexibility in defining and understanding terms. Semantic web technologies are therefore part of the common middleware basis. The term Policies is commonly interpreted in different ways – in the context of VO capabilities, it covers general behavioural policies for the VO on the one hand, as well as the individual participants’ business policies on the other – this involves aspects related to marketing strategies, event-condition-action rules to define specific event-driven behaviour, but also access rights regarding specific clients. Accordingly, Security relates to the policy capabilities, which require authentication capabilities to enforce access rights, respectively restrictions. Furthermore, Security must address message encryption to ensure integrity and privacy. Obviously, security capabilities are crucial to most collaborations. Business processing covers aspects related to executing individual private workflows [6], as well as the coordination of the overall workflow execution, i.e. the main collaborative tasks. Service level agreements (SLA) describe terms and conditions related to contractual clauses with a particular focus on their monitoring and enforcement. SLAs map between common contractual, more human readable terms and verifiable status information. Typically, SLAs are combined with event-condition-action policies in order to enforce actions under certain SLA excited circumstances. VO Management basically represents the supervising capabilities of the Virtual Organisation, which involve ensuring that all contact points are up-to-date, that the contractual basis, i.e. enactment of VO wide policies, is ensured, etc. The management capabilities may be distributed or centralised, depending on the respective VO’s requirements. Multi-Agent technologies serve mostly as a conceptual input as the respective technologies have not (yet) found wide uptake in the eBusiness community. For the BREIN project they serve as means to making the individual components more capable of taking decisions, such as protocol usage, autonomously (cf. above). Agent capabilities will in particular enhance the service provider’s capabilities to configure his/her infrastructure setup so as to meet the customer specific requirements optimally, even under highly dynamic circumstances.
bilities and requirements: since complex engineering processes are difficult to design and require expertise in particular to optimise the execution, such an approach allows providers to implement, make use and even realise new services more effectively. Given the business processes and the requirements/capability descriptions, the BREIN framework furthermore supports the design process in a way that allows customers to define complex collaborations more easily. Contract details are more human readable, also supporting the mapping between these contractual terms and the actual infrastructure configuration, respectively its capabilities. This greatly simplifies not only the definition of such contracts, but also their enactment and optimisation in order to meet the respective business policies. The collaboration is capable to adapt to changes in the environment in a more autonomous manner: With the intelligence to monitor and integrate environmental information, participants in the VO are enabled to react more quickly and effectively. This may involve both changes on the local infrastructure side – such as limited resources and even compromising contracts between different customers – as well as external effects – such as additional customer requirements. Given the capabilities, the BREIN framework will allow participants to generate and integrate their services more efficiently with less effort. From the CE perspective, this allows in particular to realize more complex engineering tasks without the additional effort of having to fully ‘‘understand” the system first, as is currently generally expected. 6. Comparison between VO middlewares It has been noted that TrustCoM and BREIN, non-regarding their similarities in the overall approach, show some fundamental differences in capabilities and specific focus points. Obviously, TrustCoM and BREIN are not the only projects addressing virtual collaborations – be it for engineering tasks or for distributed process execution. This section gives a short overview over the development of Grid/VO support in order to highlight the pros and cons of the discussed middleware and as such does not cover the development in detail (see also [12]). Fig. 6 depicts the logical development of VO support frameworks on basis of a few examples selected from the research domain – we cannot cover the full scope here, so other projects such as Gria, NextGrid, UniCore, EGEE, etc. shall only be mentioned here: Virtual Organisation middleware support started with simple distributed execution of business processes in an orchestrated, managed fashion, such as realised by the GRASP project [13]. It
5.2. CE scenario revisited With the enhancements as described above, scenarios such as the collaborative engineering one described above will profit greatly from both provider as well as customer perspective: Customer and provider may describe their requirements, respectively their capabilities in a more abstract way: thus, the requirement for additional expertise on the underlying common language model is strongly reduced and participants can expose and make use of functionalities in their own way better. This allows in particular integration of providers according to their capabilities, rather than having to respect interoperability issues, as is the case with classical Grid VO approaches. Business processes and collaboration may be described in a more intuitive manner even with limited business expertise, and collaboration details are derived automatically from capa-
BREIN TrustCoM GrAsp
Fig. 6. VO support development.
CoSpaces
L. Schubert et al. / Advanced Engineering Informatics 22 (2008) 431–437
EG
EE U N IC O G R E lo bu s G T R IA oolk it N 4 ex tG C rid oS pa Tr ce us s tC BR o M EI N
436
Legal Aspects Contract Management Service Level Agreements Maintenance B2B models Business Relationship Trust Monitoring Maintenance VO Management Virtualisation & Privacy / Hidden Infrastructures Encapsulation Complex Aggregation Semantic Enhancements Intelligent Agents for Resource Representation Support Resource Management Business Process Support Orchestrated Status Monitoring Execution VO Adaptation
X X
(X)
X
X X
X X
X X
X
X
X X
X (X)
X
X X X X X X X
(X) X (X) (X) X (X) (X) (X) X
X X X
X X (X) X X X X X X X X X
X: supported (X): planned or only partially supported Fig. 7. Grid support feature comparison.
allowed service providers to expose their resources in a common fashion that can be used across the web according to a predefined workflow – notably, this was before the advent of Web Services. TrustCoM was basing on these results with the by then strong support from the Web Service domain. Whilst it allows for flexible provider replacement on basis of overall policies, it does not provide the flexibility of adapting the overall process on the fly – in other words, the choreography describing the collaborative execution cannot easily be changed to reflect evolution of the overall VO structure and its participants. On the other hand, as opposed to projects such as BREIN, it examines the legal aspects involved in such collaborations in great detail and tries to address them as much as possible (see e.g. [4]). Therefore, TrustCoM is of higher interest for cross organisational collaborations where all process steps can be clearly defined and the effort of setting up the individual participants can be afforded. Even though TrustCoM can cater for highly dynamic Virtual Organisations, its main strengths rest obviously on contractually bound collaborations, i.e. that have to fulfil legal obligations and therefore tend to be slow with respect to any adaptations. The BREIN project on the other hand is particularly focusing on realising the dynamic aspects of Virtual Collaborations that allow the service provider more autonomy with less effort from a pure technical perspective. As opposed to TrustCoM, it does not cater for the legal aspects involved, but instead focuses on increasing simplicity and interoperability. Accordingly, BREIN is of particular interest for individual service providers that have to manage multiple resources and want to maintain stable provisioning. Even though it provides all the necessary VO support, it is of interest in this respect only, if either additional contracts are in place, or in particular in research environments, where legal liability is of secondary importance. It is worth mentioning, that Grids and Virtual Organisation principles can be used for completely different purposes, such as pursued by the CoSpaces project [14] which addresses aspects related to providing a communication framework between human beings on a metadata basis, rather than executing distributed business-related processes. Fig. 7 provides an overview over some of the existing Grid middlewares & VO projects and their main features as discussed in this paper (cf. [16]). It can be seen that TrustCoM and BREIN clearly ad-
dress a wider and more integrative scope than most of the other VO related research projects.
7. Conclusion This paper has shown that the Collaborative Engineering scenarios can gain much from the current progress being made in Virtual Organisation research: not only does it allow to reduce risk and adaptation cost, it also allows more flexibility and easier integration into collaborations. Great progress has been made over recent years to achieve the goal of a business-driven support for (electronic) virtual collaborations by such projects like TrustCoM which furthermore laid the basis for integrating legal and trust aspects, thus reflecting many of the actual needs of real world business entities. Reference implementation and demonstrations have shown that the vision of dynamic Virtual Organisations on an internet/network basis are possible indeed and will form the future of eBusiness. However, the approaches so far still show great inflexibility with respect to human specific needs, in particular where such complex issues such as business objectives are concerned. And even though deployment and administration of such middleware becomes more and more easy, the actual usage is still restricted to technically educated engineers with the according knowledge. One step in overcoming these obstacles is taken by the BREIN project which integrates Agent, Semantics and Web Service technologies with VO middleware to provide the necessary flexibility that brings eBusiness closer to the modern market. Acknowledgement The work reported in this paper has been partially funded by the EC through a FW6 IST programme grant to the TrustCoM integrated project under Contract Number 01945. The project partners, who have all contributed to the work reported in the paper, are: Atos Origin, BAE Systems, BT, IBM, Microsoft, SAP, CCLRC, ETH, HLRS, SICS, SINTEF, and the universities of Kent, London (Imperial and King’s colleges), Milan and Oslo. This work has been supported by the BREIN project (http:// www.gridsforbusiness.eu) and has been partly funded by the Euro-
L. Schubert et al. / Advanced Engineering Informatics 22 (2008) 431–437
pean Commission’s IST activity of the 6th Framework Programme under Contract Number 034556. This paper expresses the opinions of the authors and not necessarily those of the European Commission. The European Commission is not liable for any use that may be made of the information contained in this paper.
[11] [12] [13]
References
[14]
[1] M. Wilson, L. Schubert, TrustCoM Framework V4, 2007.. [2] W. Saabeel, T. Verduijn, L. Hagdorn, K. Kumar, A model for virtual organisation: a structure and process perspective, Electronic Journal of Organizational Virtualness 4 (1) (2002) 1–16. [3] D. Golby, M. Wilson, L. Schubert, C. Geuer-Pollmann, 2006. An assured environment for collaborative engineering using web services, in: P. Ghodous, R. Dieng-Kuntz, G. Loureiro (Eds.), Leading the Web in Concurrent Engineering. Next Generation Concurrent Engineering, Proceedings of the 13th ISPE International Conference on Concurrent Engineering (ISPE CE 2006), September 18–22, 2006, Antibes, France, IOS Press, pp. 111–119. [4] T. Mahler, A.E. Arenas, L. Schubert, Contractual frameworks for enterprise networks and virtual organisations in e-learning, in: P. Cunningham, M. Cunningham (Eds.), Exploiting the Knowledge Economy: Issues, Applications, Case Studies, vol. 3, IOS Press, 2006, pp. 271–278. [5] I. Foster, N. Jennings, C. Kesselman, 2004,’Brain meets brawn: Why grid and agents need each other’, . [6] J. Haller, L. Schubert, S. Wesner, Private business infrastructures in a VO environment, in: P. Cunningham, M. Cunningham (Eds.), Exploiting the Knowledge Economy: Issues, Applications, Case Studies, vol. 3, IOS Press, 2006, pp. 1064–1071. [7] J. Valles, T. Dimitrakos, S. Wesner, B. Serhan, P. Ritrovato, The grid for ecollaboration and virtual organisations, Building the Knowledge Economy: eChallenges 2003 (2003). [8] L. Schubert, S. Wesner, T. Dimitrakos, Secure and Dynamic Virtual Organizations for Business, in: Paul Cunningham, Miriam Cunningham (Eds.), Innovation and the Knowledge Economy - Issues, Applications, Case Studies, vol. 2, IOS Press, 2005, pp. 1201–1208. [9] I. Foster, C. Kesselman, S. Tuecke, The anatomy of the grid: enabling scalable virtual organizations, International Journal of Supercomputer Applications 15 (2001). [10] M. Kano, R. Duvvuru Sriram, A. Gupta, 1994. ’International Multi-Company Collaborative Engineering: A Study of Japanese Engineering and Construction
[15]
[16]
[17]
437
Firms’.. I. Jones, 2007. ’Validation Scenario Definition’. . R. Baxter, 2002. ’A Complete History of the Grid (abridged)’. . GRASP – Grid-based Application Service Provision (EC IST FP5 project). . N. Kavantzas, D. Burdett, G. Ritzinger, T. Fletcher, Y. Lafon, C. Barreto, 2005. Web Service Choreography Description Language 1.0 (WS-CDL),
Lutz Schubert has been working on dynamic infrastructures for Virtual Organisations for more than 3 years now. He has a strong research and study background in artificial intelligence and neural networks, and is currently looking at enhancing the Web Service paradigm with intelligent capabilities. He has recently become head of the ‘‘Intelligent Service Infrastructure” group at HLRS which is realising intelligent services for the future internet. Alexander Kipp has a strong research and study background in the area of distributed systems and workflow system architectures using web services as integration technologies. He has also been involved in the extension of BPEL towards a global choreography standard. He is currently working at HLRS in the area of virtualisation and encapsulation of resources to allow for intelligent, dynamic integration. Bastian Koller focuses on realising service level agreements in dynamic Virtual Organisations in a way that meets both the human business requirements. He has been working on grid-based Virtual Organisation support at HLRS for the last 3 years and has recently been promoted head of the ‘‘Service Management and Business Processes” group. Furthermore he is an active participant at OGF, especially at the GRAAP working group, which is working on the WS-AgreementNegotiation specification.
Contents lists available at ScienceDirect
Advanced Engineering Informatics journal homepage: www.elsevier.com/locate/aei
Supporting collaborative engineering using an intelligent web service middleware Lutz Schubert *, Alexander Kipp, Bastian Koller HLRS – University of Stuttgart, Intelligent Service Infrastructures, Nobelstrasse 19, 70569 Stuttgart, Germany
a r t i c l e
i n f o
Article history: Received 18 April 2008 Accepted 12 May 2008
Keywords: Virtual Organisations TrustCoM project BREIN project Service oriented architecture Artificial intelligence Grid
a b s t r a c t Collaborative Engineering tasks are difficult to manage and involve a high amount of risk – as such, these tasks generally involve only well-known pre-established relationships. Such collaborations are generally quite static and do not allow for dynamic reactions to changes in the environment. Furthermore, not all optimal resource providers can be utilised for the respective tasks as they are potentially unknown. The TrustCoM project elaborated the means to create and manage Virtual Organisations in a trusted and secure manner integrating different providers on-demand. However, TrustCoM focused more on the VO than on the participant, whereas the BREIN project is now enhancing the intelligence of such VO systems to support even providers with little business expertise and provide them with capabilities to optimise their performance. This paper analyses the capabilities of current VO frameworks on the example of TrustCoM and identifies the gaps from the participant’s perspective. It then shows how BREIN addresses these gaps. Ó 2008 Elsevier Ltd. All rights reserved.
1. Introduction Modern day engineering tasks typically demand a complexity not supported by individual companies – accordingly, enterprises join in collaborations to outsource and distribute tasks according to the requirements that need to be fulfilled. Whilst the overall costs are reduced this way, such collaborations are normally difficult to manage considering their size and complexity [10]. In recent years, the concept of Virtual Organisations has been developed to describe collaborations using resources exposed to the internet. Following the grid concept, this allows for managed and dynamic collaboration between different resource types, or in other words to enable transactions between different companies in a coordinated manner [7–9]. The TrustCoM project has delivered a framework, as well as a reference implementation that enables organised and contract managed collaborations in a secure and trusted manner. Even though TrustCoM principally allows for dynamic on-demand creation of Virtual Organisations, as well as their autonomous management according to predefined collaboration description, the project does not support all issues to ensure full uptake by the eBusiness community. This paper examines TrustCoM in view of one of its particular application scenarios, namely the ‘‘CE scenario”, in which different companies participate in a Virtual Organisation to adapt the design of an airplane according to a specific customer’s personal requirements. Basing on this scenario, we will examine in how far Trust* Corresponding author. Tel.: +49 0 711 685 87262; fax: +49 0 711 685 77262. E-mail address: [email protected] (L. Schubert). 1474-0346/$ - see front matter Ó 2008 Elsevier Ltd. All rights reserved. doi:10.1016/j.aei.2008.05.002
CoM actually supports the individual participants in their task of supporting the VO requirements and thereupon elaborate the gaps that the recently started IP project BREIN is addressing. 2. An assured environment for collaborative engineering: The TrustCoM approach The main goal of the TrustCoM project consisted in providing a framework that would allow integration of any type of resource provider exposing their capabilities over the web, in order to form collaborations that meet specific business needs and goals. The framework makes extensive use of web service standards so as to allow common uptake from both larger and smaller companies, respectively individuals. The framework ensures that all transactions within the Virtual Organisation are secured and that confidentiality issues are fully respected so that partners may remain anonymous, if so desired. Furthermore, as shall be detailed below, it allows participants to maintain their own infrastructure and their own means to realise the ‘‘products” they provide to a collaborative engineering task. As one of the first projects, TrustCoM also extensively researched the influence and relationship of legal and trust issues on framework specific structures and their implementation. By that, TrustCoM allows for contractual support as well as selection of partners on basis of their performance in other collaborative tasks. Contractual performance is enforced through means of service level agreements that monitor behaviour and evaluate it with respect to the contractual agreements. Accordingly lacking performance can be identified in time and dealt with accordingly
432
L. Schubert et al. / Advanced Engineering Informatics 22 (2008) 431–437
Virtual Organisation
Participant
Participant
Task Task
Preparation
Task Role1
Interaction
Task
Role2
Task Task
Formation
Operation
Dissolution
Fig. 1. Abstract entities in TrustCoM’s Virtual Organisations.
Evolution
– depending on the overall requirements, this can consist in applying fines or even complete replacement of the partner, if this lack of performance is considered critical for the full execution of the collaborative tasks. The legal aspects of the collaboration and thus of the validity of the SLA are defined through a ‘‘General VO Agreement” (GVOA) that basically represents the contractual basis of electronic collaborations [4].1 The project consortium consisted of 16 partners from industry and academy with British Aerospace (BAE), IBM and SAP being actively involved in collaborative engineering tasks as part of their overall business. The scenario discussed below was basing on actual engineering problems by BAE. Their main purpose consisted in bringing the concepts of Virtual Organisations to improve dayto-day business tasks in complex collaboration setups. 2.1. ‘‘Abstract entities” TrustCoM’s main achievement in bringing Virtual Organisations closer to modern day business needs consisted in particular in introducing the concepts of ‘‘abstract entities” to the Grid and Web Services community. As opposed to the classical approach, where each actual resource maintained by the individual enterprises is exposed as a service of its own, be it humans, printers, computers or actual applications and utilities, the ‘‘abstract entities” approach foresees that each participant in a Virtual Organisation is actual a conglomeration of individual resources that are executed and linked in a coordinated manner (cf. Fig. 1): in principle this means nothing else but that service providers execute their normal workflows (as part of their day-to-day business, such as e.g. the manufacturing chains) and provide the results of these processes as their actual capabilities. Regarded from the outside, this is identical to interaction with a single resource that can fulfil a very complex task – this way, participants are considered real business entities, with their own typical workflows to generate the ‘‘products” they sell and with an infrastructure they do not want to expose to, let alone be controlled by external bodies. From the TrustCoM perspective, enterprises participate in a Virtual Organisation according to the roles they bring in rather than according to their resources. This respects the first main issues in (electronic) business: the confidentiality of the providers’ business intelligence, including infrastructure setup, workflow details, etc., and leaving complete control over resources, infrastructure, etc. in their hands. This also reduced the complexity of the overall management tasks that typically had to be executed by the contracting party that sets up the collaboration. 2.2. Managing the virtual organisation Classical Grid VO approaches described the whole collaboration as a series of tasks executed by the individual resources as exposed 1 For more details on the framework structure as realised by the TrustCoM project, please refer to [1].
Fig. 2. Typical phases in the VO Lifecylce.
by the participants, i.e. a sequence of simple invocations, where each invocation is provided directly by individual machines, rather than reflecting a complex business process. With actual enterprises participating in the Virtual Organisation, i.e. with them representing abstract entities that do not allow manipulation of their individual resources, such an approach is obviously not feasible anymore. Instead, TrustCoM describes the collaboration as interactions between roles in a choreography across organization boundaries as defined e.g. by WS–CDL [17]. Since collaborations may lose individual participants during execution, be it due to actual loss of connection, due to violation of the contractual terms or related issues, such choreography and the according list of role providers needs to be carefully maintained by the Virtual Organisation. To this end, TrustCoM provides the VO Management structures that manage participants, as well as their roles in the collaboration and enacts the relevant tasks to maintain the VO structure. In principle, the TrustCoM management structure has the task of steering all participants involved in the collaborative setting through the lifetime of the VO in order to fulfil the collaborative purpose. The lifetime and dynamics of a Virtual Organisation can thereby be denoted by the lifecycle phases as depicted in Fig. 2 (cf. [2,15]): the VO is formed (Formation) by contacting individual providers and taking the necessary configuration steps to set up the collaboration (Preparation); the actual tasks according to the collaboration description are executed (Operation); during operation, some changes in the overall goals, respectively the availability of individual participants may lead to restructuring of the VO (Evolution); and finally, once the VO is not needed any longer, it is dissolved (Dissolution). Of particular interest is the fact that TrustCoM also considers steps prior to actually forming a Virtual Organisation, such as configuring the local business process, describing the results (the ‘‘product”, see above) and advertising it on the market (Preparation). 3. Applying virtual organisations: The collaborative engineering scenario It has already been noted that TrustCoM specifically aimed at simplifying the overall processes in a complex distributed engineering task, as represented by British Aerospace. This particular application scenario consisted in an engineering consortium (here ‘‘CE VO”) collaborating with a team of airplane analysts (‘‘Analysis VO”) to support the tasks of an airline manufacturer that e.g. wants to extend the capabilities of an airplane to host internet capabilities on-flight to fulfil customer demands (cf. Fig. 3). We can thereby clearly depict a customer (Airline VO) which also acts as the main data provider, i.e. providing the airplane design. Providers realising abstract services consist in the design team that update the airplane design according to the requirements specified and therefore
433
L. Schubert et al. / Advanced Engineering Informatics 22 (2008) 431–437
Airline VO AnalysisVO Updates
Product ConfigStorage Provider
Aircraft Maintenance
Contracts maintenance to
Analysis Team Analysisis Analys Provider
Uses
Maintains Accesses product database, sends reports to
Owns
Analysis alysis S/W HoAnalysis S/W Provider
Airline Aircraft
Uses
HPC Provider
Delivers sub-system design to Stores results to
CE3 VO Uses analysis services from Resource Planning Sub-system provider Sub-system Design Team
Storage Provider Production Facilities Production Consultants Consultants Product design database
Populates design database
Buys storage from
Fig. 3. Actors in TrustCoM’s CE Scenario.
use the support of the analysis team which validates the design against structural and technical requirements. The overall process may be enhanced through using an additional storage provider to maintain the huge amount of data created during design and analysis. It has to be noted here, that the so-called VOs in this scenario are actually the abstract entities as described in the preceding section, i.e. collaborations that exist prior to the actual VO as supported by the TrustCoM framework. These ‘‘sub-VOs” represent business entities in their own right, as they sell aggregated products and deal with their own customers, independent of the overlying airline VO of the presented case.2 The TrustCoM framework enables such collaboration by providing a secure and contract managed middleware that enables the individual participants to expose ‘‘virtual” resources that reflect the capabilities of the respective local, organisation-specific and private business processes. The framework allows participants to host an interface that secures message exchange, controls access according to the overall collaboration description and ensures that the according transaction requirements are met and automatically updated. The individual participant is thereby provided with a means to interact with other roles in the collaboration, as if they would be static instances, non-regarding potential changes in the VO structure. The TrustCoM project promotes (but does not restrict itself to) a business model consisting of a single main contractor that binds all participants legally and aggregates them so that they form a single unit (cf. above). Accordingly, each party is liable against this main contractor only and not, as in classical approaches, against each other, depending on the collaborative relationships.
2 Hierarchies of collaborations such as the one presented here reflect the actual business world of main contractors and subcontractors: typically, commercial service providers already realise their capabilities through a set of (static) collaborations and subcontracts of which the customer is not even aware. The TrustCoM model supports such hierarchical relationship models by encapsulating virtual collaborations as if they would be single business entities that again can participate in other Virtual Organisations (cf. [1]).
TrustCoM thus greatly reduces the management overhead typically associated with such scenarios.3 4. Ready for eBusiness 2010? The TrustCoM project provides all the relevant features to relieve business providers from the burden of complex and in particular costly adaptations of the infrastructure so as to meet individual customer’s demands whilst maintaining security and access right restrictions. It also ensures that dynamicity is ensured without impact on the individual participants and that the risk of participation is reduced through means of contractual binding, sensible responsibility distribution and SLA support. However, TrustCoM cannot relieve the participants from the burden to understand the system and to prepare their infrastructures so as to meet the according requirements, respectively to deploy and configure the TrustCoM middleware. As such, business providers need to understand the service level agreement language, in the sense of being able to interpret the customer’s requirements, as well as being able to relate them to a configuration of the infrastructure that respects his/her business policies and, obviously, the capabilities and availabilities of the resources involved. They furthermore need to be capable of reading and understanding the policy descriptions they subscribe to as part of their contracts: even though the GVOA comes in human readable form, negotiation of its details requires translation back into machine terms. With encapsulation of the infrastructure comes the price of more complex relationships between exposed methods and actual resource setup, respectively business process description. Since such descriptions are still relatively inflexible, according adaptations are generally time and budget consuming. Similarly on the customer level, the initiator of the VO will have to have a good grasp on enactment of complex collaborative tasks, in order to define the initial collaboration descriptions and, what is more, to
3
A more thorough discussion of this scenario can also be found in [3].
434
L. Schubert et al. / Advanced Engineering Informatics 22 (2008) 431–437
define the individual requirements per role. Non-regarding that this task has been simplified with the introduction of aggregating roles instead concrete resources,4 the task still remains very difficult and requires according expertise, which an average customer will not possess. Since furthermore the TrustCoM system does currently not realise any intelligent, or even semantic matching, description of service capabilities will have to be in a way (theoretically) conformant between different providers, so that the exposed functionalities match the ones described in the collaboration description. As such, TrustCoM must be regarded as a great step towards providing business providers with a framework that supports their business needs from a technical perspective, yet it could not cater for specific needs that would allow ‘‘business agnostic” providers and/or customers, i.e. people that do not bring in the expertise of handling such a complex system, to make full use of the collaboration middleware. With smaller to medium enterprises being a particular focus of the Virtual Organisation support, the TrustCoM middleware runs the risk of being yet too complicated for fast uptake, non-regarding the simplifications achieved by this project. TrustCoM can hence only be an intermediary step towards reaching the actual end-user, be it SME role provider or customer.
Customer & Business Interactions Define Individual Business Goals Control
Fulfill Semantic Description
Agents Grid
Configure/Execute
Processes & Supply Chains
5. Filling in the gaps: The BREIN approach Whilst TrustCoM significantly reduced the complexity of managing and maintaining distributed collaborative tasks, it still requires a high degree of technical understanding of the individual parties wanting to participate in such collaborations, respectively wanting to expose TrustCoM-conformant services. The BREIN project is loosely coupled to TrustCoM and extends the achievements of the latter with a particular focus on the human behind the system. It pursues three main goals: Supporting the business providers in all tasks related to exposing and integrating his/her capabilities into a Virtual Organisation. Supporting the customer in getting the capabilities and services he/she needs. Optimising the behaviour of both the whole VO and the individual participant in a way that allows for everybody’s demands best without disrespecting according corporate policies. As such, BREIN is one of the first ICT projects that is focused on addressing the whole requirements of enterprises to participate in Virtual Organisations (cf. Fig. 4), i.e. by enhancing the pure technical level according to human needs. As opposed to TrustCoM, the project does not look into the legal aspects involved in VO enactment and does not intend to extend the issues related to measuring individual participant’s trustworthiness. With this respect it builds upon existing results (such as by TrustCoM), which is in fact one of the main goals of the project – to foster existing results and to avoid a start from scratch. The BREIN project brings together a consortium of 16 partners from industry and academy with a strong focus on solving distributed tasks in a collaborative manner. In particular ANSYS, BOC and Elsag Datamat show strong interest in realising distributed collaborative engineering tasks in a more efficient manner. The revisited CE scenario (Chapter 5.2 below) is basing on the analysis of the ‘‘Virtual Engineering” scenario [11] as maintained in the BREIN project by ANSYS.
4 ‘‘Roles” reflect a higher degree of abstraction than concrete resources do: as such, it is up to the individual provider to specify the details of resource usage, whilst the VO initiator ‘‘just” needs to specify what capability is required at what point in time.
Fig. 4. An overview over the technologies in the BREIN project.
5.1. The BREIN framework The BREIN framework builds strongly upon Web Service technologies and incorporates existing VO middleware solutions, as well as communication standards and specifications that promise (or already found) wide acceptance by the research and eBusiness community. Thus, it will realise a service oriented architecture that integrates the most relevant aspects related to supporting and realising Virtual Organisations applicable to real business world scenarios. With a significant relationship between Grid and Agent technologies [5] the BREIN project focuses on extending common grid technologies with the autonomy and negotiation capabilities of Multi-Agent approaches and thus implicitly extending Multi-Agent technologies with the stability, reliability and extensibility of the Grid. With respect to modern day eBusiness requirements, the BREIN consortium identified in particular the following technical areas as most important for future VO middleware needs (cf. Fig. 5): Infrastructure capabilities represent the most classical Grid functionalities, namely to allow for standardised messaging in different
Fig. 5. Framework structure of the BREIN project.
435
L. Schubert et al. / Advanced Engineering Informatics 22 (2008) 431–437
environments, as well as the encapsulation and publication of service capabilities (cf. Section 2.1 ‘‘Abstract Entities”). The full VO middleware is based upon such infrastructure capabilities to provide a common messaging platform. Semantic web technologies ensure that information about participants and their products are commonly understood, even though their details (such as capabilities) are defined by humans and thus subject to great variations between each other – this also allows more flexibility in defining and understanding terms. Semantic web technologies are therefore part of the common middleware basis. The term Policies is commonly interpreted in different ways – in the context of VO capabilities, it covers general behavioural policies for the VO on the one hand, as well as the individual participants’ business policies on the other – this involves aspects related to marketing strategies, event-condition-action rules to define specific event-driven behaviour, but also access rights regarding specific clients. Accordingly, Security relates to the policy capabilities, which require authentication capabilities to enforce access rights, respectively restrictions. Furthermore, Security must address message encryption to ensure integrity and privacy. Obviously, security capabilities are crucial to most collaborations. Business processing covers aspects related to executing individual private workflows [6], as well as the coordination of the overall workflow execution, i.e. the main collaborative tasks. Service level agreements (SLA) describe terms and conditions related to contractual clauses with a particular focus on their monitoring and enforcement. SLAs map between common contractual, more human readable terms and verifiable status information. Typically, SLAs are combined with event-condition-action policies in order to enforce actions under certain SLA excited circumstances. VO Management basically represents the supervising capabilities of the Virtual Organisation, which involve ensuring that all contact points are up-to-date, that the contractual basis, i.e. enactment of VO wide policies, is ensured, etc. The management capabilities may be distributed or centralised, depending on the respective VO’s requirements. Multi-Agent technologies serve mostly as a conceptual input as the respective technologies have not (yet) found wide uptake in the eBusiness community. For the BREIN project they serve as means to making the individual components more capable of taking decisions, such as protocol usage, autonomously (cf. above). Agent capabilities will in particular enhance the service provider’s capabilities to configure his/her infrastructure setup so as to meet the customer specific requirements optimally, even under highly dynamic circumstances.
bilities and requirements: since complex engineering processes are difficult to design and require expertise in particular to optimise the execution, such an approach allows providers to implement, make use and even realise new services more effectively. Given the business processes and the requirements/capability descriptions, the BREIN framework furthermore supports the design process in a way that allows customers to define complex collaborations more easily. Contract details are more human readable, also supporting the mapping between these contractual terms and the actual infrastructure configuration, respectively its capabilities. This greatly simplifies not only the definition of such contracts, but also their enactment and optimisation in order to meet the respective business policies. The collaboration is capable to adapt to changes in the environment in a more autonomous manner: With the intelligence to monitor and integrate environmental information, participants in the VO are enabled to react more quickly and effectively. This may involve both changes on the local infrastructure side – such as limited resources and even compromising contracts between different customers – as well as external effects – such as additional customer requirements. Given the capabilities, the BREIN framework will allow participants to generate and integrate their services more efficiently with less effort. From the CE perspective, this allows in particular to realize more complex engineering tasks without the additional effort of having to fully ‘‘understand” the system first, as is currently generally expected. 6. Comparison between VO middlewares It has been noted that TrustCoM and BREIN, non-regarding their similarities in the overall approach, show some fundamental differences in capabilities and specific focus points. Obviously, TrustCoM and BREIN are not the only projects addressing virtual collaborations – be it for engineering tasks or for distributed process execution. This section gives a short overview over the development of Grid/VO support in order to highlight the pros and cons of the discussed middleware and as such does not cover the development in detail (see also [12]). Fig. 6 depicts the logical development of VO support frameworks on basis of a few examples selected from the research domain – we cannot cover the full scope here, so other projects such as Gria, NextGrid, UniCore, EGEE, etc. shall only be mentioned here: Virtual Organisation middleware support started with simple distributed execution of business processes in an orchestrated, managed fashion, such as realised by the GRASP project [13]. It
5.2. CE scenario revisited With the enhancements as described above, scenarios such as the collaborative engineering one described above will profit greatly from both provider as well as customer perspective: Customer and provider may describe their requirements, respectively their capabilities in a more abstract way: thus, the requirement for additional expertise on the underlying common language model is strongly reduced and participants can expose and make use of functionalities in their own way better. This allows in particular integration of providers according to their capabilities, rather than having to respect interoperability issues, as is the case with classical Grid VO approaches. Business processes and collaboration may be described in a more intuitive manner even with limited business expertise, and collaboration details are derived automatically from capa-
BREIN TrustCoM GrAsp
Fig. 6. VO support development.
CoSpaces
L. Schubert et al. / Advanced Engineering Informatics 22 (2008) 431–437
EG
EE U N IC O G R E lo bu s G T R IA oolk it N 4 ex tG C rid oS pa Tr ce us s tC BR o M EI N
436
Legal Aspects Contract Management Service Level Agreements Maintenance B2B models Business Relationship Trust Monitoring Maintenance VO Management Virtualisation & Privacy / Hidden Infrastructures Encapsulation Complex Aggregation Semantic Enhancements Intelligent Agents for Resource Representation Support Resource Management Business Process Support Orchestrated Status Monitoring Execution VO Adaptation
X X
(X)
X
X X
X X
X X
X
X
X X
X (X)
X
X X X X X X X
(X) X (X) (X) X (X) (X) (X) X
X X X
X X (X) X X X X X X X X X
X: supported (X): planned or only partially supported Fig. 7. Grid support feature comparison.
allowed service providers to expose their resources in a common fashion that can be used across the web according to a predefined workflow – notably, this was before the advent of Web Services. TrustCoM was basing on these results with the by then strong support from the Web Service domain. Whilst it allows for flexible provider replacement on basis of overall policies, it does not provide the flexibility of adapting the overall process on the fly – in other words, the choreography describing the collaborative execution cannot easily be changed to reflect evolution of the overall VO structure and its participants. On the other hand, as opposed to projects such as BREIN, it examines the legal aspects involved in such collaborations in great detail and tries to address them as much as possible (see e.g. [4]). Therefore, TrustCoM is of higher interest for cross organisational collaborations where all process steps can be clearly defined and the effort of setting up the individual participants can be afforded. Even though TrustCoM can cater for highly dynamic Virtual Organisations, its main strengths rest obviously on contractually bound collaborations, i.e. that have to fulfil legal obligations and therefore tend to be slow with respect to any adaptations. The BREIN project on the other hand is particularly focusing on realising the dynamic aspects of Virtual Collaborations that allow the service provider more autonomy with less effort from a pure technical perspective. As opposed to TrustCoM, it does not cater for the legal aspects involved, but instead focuses on increasing simplicity and interoperability. Accordingly, BREIN is of particular interest for individual service providers that have to manage multiple resources and want to maintain stable provisioning. Even though it provides all the necessary VO support, it is of interest in this respect only, if either additional contracts are in place, or in particular in research environments, where legal liability is of secondary importance. It is worth mentioning, that Grids and Virtual Organisation principles can be used for completely different purposes, such as pursued by the CoSpaces project [14] which addresses aspects related to providing a communication framework between human beings on a metadata basis, rather than executing distributed business-related processes. Fig. 7 provides an overview over some of the existing Grid middlewares & VO projects and their main features as discussed in this paper (cf. [16]). It can be seen that TrustCoM and BREIN clearly ad-
dress a wider and more integrative scope than most of the other VO related research projects.
7. Conclusion This paper has shown that the Collaborative Engineering scenarios can gain much from the current progress being made in Virtual Organisation research: not only does it allow to reduce risk and adaptation cost, it also allows more flexibility and easier integration into collaborations. Great progress has been made over recent years to achieve the goal of a business-driven support for (electronic) virtual collaborations by such projects like TrustCoM which furthermore laid the basis for integrating legal and trust aspects, thus reflecting many of the actual needs of real world business entities. Reference implementation and demonstrations have shown that the vision of dynamic Virtual Organisations on an internet/network basis are possible indeed and will form the future of eBusiness. However, the approaches so far still show great inflexibility with respect to human specific needs, in particular where such complex issues such as business objectives are concerned. And even though deployment and administration of such middleware becomes more and more easy, the actual usage is still restricted to technically educated engineers with the according knowledge. One step in overcoming these obstacles is taken by the BREIN project which integrates Agent, Semantics and Web Service technologies with VO middleware to provide the necessary flexibility that brings eBusiness closer to the modern market. Acknowledgement The work reported in this paper has been partially funded by the EC through a FW6 IST programme grant to the TrustCoM integrated project under Contract Number 01945. The project partners, who have all contributed to the work reported in the paper, are: Atos Origin, BAE Systems, BT, IBM, Microsoft, SAP, CCLRC, ETH, HLRS, SICS, SINTEF, and the universities of Kent, London (Imperial and King’s colleges), Milan and Oslo. This work has been supported by the BREIN project (http:// www.gridsforbusiness.eu) and has been partly funded by the Euro-
L. Schubert et al. / Advanced Engineering Informatics 22 (2008) 431–437
pean Commission’s IST activity of the 6th Framework Programme under Contract Number 034556. This paper expresses the opinions of the authors and not necessarily those of the European Commission. The European Commission is not liable for any use that may be made of the information contained in this paper.
[11] [12] [13]
References
[14]
[1] M. Wilson, L. Schubert, TrustCoM Framework V4, 2007.
[15]
[16]
[17]
437
Firms’.
Lutz Schubert has been working on dynamic infrastructures for Virtual Organisations for more than 3 years now. He has a strong research and study background in artificial intelligence and neural networks, and is currently looking at enhancing the Web Service paradigm with intelligent capabilities. He has recently become head of the ‘‘Intelligent Service Infrastructure” group at HLRS which is realising intelligent services for the future internet. Alexander Kipp has a strong research and study background in the area of distributed systems and workflow system architectures using web services as integration technologies. He has also been involved in the extension of BPEL towards a global choreography standard. He is currently working at HLRS in the area of virtualisation and encapsulation of resources to allow for intelligent, dynamic integration. Bastian Koller focuses on realising service level agreements in dynamic Virtual Organisations in a way that meets both the human business requirements. He has been working on grid-based Virtual Organisation support at HLRS for the last 3 years and has recently been promoted head of the ‘‘Service Management and Business Processes” group. Furthermore he is an active participant at OGF, especially at the GRAAP working group, which is working on the WS-AgreementNegotiation specification.