(B2B) collaborations. ... It enables collaborating partners to create an e-Contract template where they can unam- biguously ......
Dynamic Business Collaborations through Contract Services Surya Nepal, Shiping Chen CSIRO ICT Centre, Australia Cnr Vimiera & Pembroke Rds, Marsfield NSW 2122, Australia {FirstName.LastName}@csiro.au Abstract New application have recently emerged within the domains of e-Health, e-Science, e-Research and e-Government that require the formation of dynamic collaborations between independent, autonomous business organizations for the duration of a project designed with a specific purpose. To successfully create and manage such collaborations, there is a need of a standard way to specify: (a) what resources are required, (b) who will contribute resources, (c) the type of access required to these resources, (d) agreement and obligations of the partners within the business collaboration, with the terms and conditions specified in the agreement, and (e) how to instantiate, maintain and terminate such business collaborations easily and in a well understood manner. We address these issues through the creation, negotiation and execution of an agreed electronic contract. First, this paper provides a framework for an electronic contract (e-Contract) by introducing a Web Service Collaborative Context Definition Language (WS-CCDL), which we have developed in the context of dynamic business collaboration. Then, we illustrate its use with a universal (anywhere) connectivity service for a tele-Collaboration application in the context of eResearch domain. Both architectural design and implementation considerations are provided to highlight the feasibility and complicity of the technologies. Introduction Recently, there has been much interest in forming on-demand dynamic collaborations between multiple companies, who although competitors, wish to collaborate on occasion because of some mutual business interest (Yamazaki, 2004). For example, in the e-Research domain, a number of research institutes may formulate a joint project to solve a challenging scientific problem that is outside the capabilities of a single organization to solve. This project, as an example, requires the institutes to form a dynamic collaboration that lasts only for the duration of the project. Within this project and collaboration, each institution contributes its own unique resources to the collaboration that enable a platform for researchers towards finding the solution for the problem (Jrotka, et al., 2006).
The idea of dynamic collaborations in this way, however, is not new. For example, the area of virtual organizations (Mowshowitz, 1994; Foster et al., 2001; Globus, 2011; King, 1991) explores mechanisms that enable entities from different organizations to collectively create a virtual enterprise for some mutual benefit. This goal is typically achieved through open service discovery, negotiation and execution based on Service Level Agreements (SLAs). In particular, the Grid computing community has made some important research contributions to the Virtual Organization (VO) literature (Foster et al., 2001). The Grid computing model for virtual organizations is based on resources that are usually intended to be “persistent”, i.e., open to discovery via the Internet in an open pool, and are expected to be available to an open pool of users on an ongoing basis for as long as required (Globus, 2011). While specific resources of the infrastructure (e.g., computational elements, storage systems, instruments and tele-Collaboration sites, etc.) may be taken offline or added on a dynamic basis, the resources (drawn from the pool) as a whole should remain available for as much as possible. In contrast to the virtual organization model just described, there is a growing trend where virtual enterprises, built around their own transient business interests require their contributed resources to remain hidden from outside parties (Phillips et al., 2002; Handley et al., 2002). Resources are only revealed to a select group of participants. One example of this is the policy-based provisioning of resources, where resources are revealed only to trusted, collaborating partners by the agreed upon policies defined for the resources (Tsai et al., 2007). In situations such as this, open service discovery mechanisms cannot be used, as this resource information is deliberately hidden. Collaborations built around this concept are termed dynamic collaborations. One of the key features of a dynamic collaboration is an on-demand contribution of resources from participating autonomous organizations. To establish such dynamic collaborations, all participants involved in the collaboration require a standard way to specify and/or agree: (a) what resources are required (Requirements); (b) who will contribute resources (Contributions); (c) how to access these resources (Access Polices). The participants may also have to explicitly add the corresponding terms and conditions to the above technical specifications. Furthermore, contributed resources residing in different autonomous organizations bring a problem of interoperability between them, not the least of which includes differing access policies. SOA concepts and Web Services technologies have proven to be successful in dealing with issues related to interpretability across autonomous systems. A stack of Web Services standards, such as WSDL, UDDI and SOAP, are defined to provide platform-independent way of implementing services. Recently, resources such as storage and networking infrastructures, tools, software and data are implemented using Web Services technologies so that they too can be made available as services. For example, a concept of Software-as-a-Service (SaaS) is introduced
for software (Ma, 2007) and Infrastructure-as-a-Service (IaaS) (Nepal et al., 2007) for storage and networking infrastructure. Therefore, we envisage that it is possible to define and share resources as services in the context of dynamic collaborations. From the above discussion, we reach a conclusion that a contract that combines both technical specifications and legal declarations is a natural starting point to establish such dynamic collaborations. An electronically executable version of such a contract, whose notations and semantics are defined to be machine interpretable, is called an electronic contract (e-Contract) (Radha Krishna et al., 2005). The concept of an e-Contract, however, is not new. It has been used as a powerful concept (as well as a data model) for controlling and automating Business-to-Business (B2B) collaborations. The literature of e-Contract has been spread across various aspects and functionalities of e-Contract, including e-Contract representation (XML, ebXML, ECML, tpaML, RuleML) (Paschke, 2005), e-Contract negotiation (Nepal et al., 2007; Nepal et al, 2008) and e-Contract enforcement and monitoring (Xu and Jeusfeld, 2003). Keller and Ludwig (2002) defined a Web Service Level Agreement (WSLA) ((Ludwig et al., 2003) framework for defining and monitoring Service Level Agreements (SLAs) between service providers and service consumers in an electronic commerce scenario. This framework works well in scenarios that involve only two parties, each having distinct roles; the service provider offering a service and the service consumer requesting and consuming the service. However, in the context of dynamic collaborations, this does not work well due to the following reasons (Nepal et al., 2008): Dynamic collaborations have complex policies defining the interactions, access and use of resources. Multiple parties are involved in dynamic collaborations; Multiple resources (services) are contributed to the collaboration by multiple parties; Both roles of service provider and service consumer are often played by a single party; All parties must agree with each other’s contributions and oblige with their agreements. In order to fulfil these requirements, this paper presents a contract definition framework for dynamic collaborations called the Web Service Collaborative Context Definition Language (WSCCDL). It enables collaborating partners to create an e-Contract template where they can unambiguously define the requirements for the collaboration as well as agreements for all the resources contributed to the collaboration. Furthermore, the agreed e-Contract is machine interpretable and can be executed to establish and terminate the dynamic collaboration. In this paper, we describe the semantics of the framework using an example of a dynamic collaboration from the e-Research domain. The language itself is defined using XML Schema, and implement-
ed in a case study that builds an e-Contract service architecture of a tele-Collaboration-based eResearch dynamic collaboration service. The e-Contract service operates as a web service that facilitates its clients to discover (or being discovered by) potential collaborators, form a collaboration via an e-Contract and establish the collaboration platform by executing/instantiating the eContract. A tele-Collaboration application is used to demonstrate how researchers can contribute resources and obtain universal connectivity to each other through the use of the e-Contract service. The rest of the article is structured as follows. Section 2 provides the background and motivations behind contract driven dynamic collaborations. We then describe the language for defining template for electronic contract in Section 3. This is followed by the description of the runtime framework for the contract in Section 4. The architecture and the language are then demonstrated through a case study of a connectivity service in the tele-Collaboration application in Section 5. The final section draws the concluding remarks. Background & Motivations Dynamic business collaborations bring together complementary sets of competencies from autonomous (probably competing) enterprises to address new market opportunities in an evolving and increasing globalised economy (Chan et al., 2007; Jopling and Neil, 2005). In addition to enterprise applications, dynamic collaboration among distributed cross-organizational entities occurs in other domains such as Command and Control Systems in military applications (Handley et al, 2007), coalitions among civilian organizations in emergencies and disaster relief (Phillips et al, 2002), research coalitions in e-Research applications (Department of Education, 2006) and coalitions between health care facilities and practitioners in eHealth applications (Qioao et al., 2004). The value of dynamic collaboration technologies have been recognized by both industries and governments as is evident from the special issue of the Journal on Dynamic Collaboration (Yamazaki, 2004), government funding support for collaborative platforms within eResearch (Department of Education, 2006) and a substantial body of DARPA funded research in dynamic collaborations (Khurana et al., 2003; Khurana et al., 2004; Freudenthal et al., 2002; Patz et al., 2001; Seamons et al., 2003). In more recent work on dynamic collaboration (Chiu, D.K.W., et al. 2010), the authors proposed using Multi-Agents (MA) approach to building eCollaboration systems. Among these initiatives, the Dynamic Coalitions program within DARPA is aimed at technology creation to address the needs recognised within the Joint Vision 2020 document to manage dynamic coalition formation and facilitate secure sharing of information by authorized members of the joint or coalition operation (Joint Vision 2010, 2011; Joint Vision 2020, 2011). Therefore, the
focus of many activities within this program is on developing a secure collaborative system. This is one of the three essential criteria as identified by Yamazaki (2004). The other two can be categorized as interoperability and ease of operations. The interoperability includes the workflows and business processes among collaborating enterprises (Liu et al, 2007; Tsai et al., 2007a; Tsai et al., 2007b), as well as the contributed resources (Perez et al, 2006; Skarmeta and Perez, 2004). Fujita (2004) proposed to use Web Services standards to achieve connectivity and reliability between enterprises forming a dynamic collaboration. Since each enterprise has autonomous business processes, the integration of these looselycouple processes is itself an important research issue with regard to interoperability. Other research has proposed interoperating frameworks to assist the formation of dynamic collaborations by exploiting business processes properties in a particular application domain (Liu et al, 2007) and utlising well understood associated ontologies (Tsai et al., 2007a ). An example of easy operation is to provide a stress-free network connection among collaborating partners. Skarmeta and Perez (2004) report a dynamic policy-based network management (PBNM) system that can be used to configure and manage a secure network for a coalition. The policy negotiation protocol in the system facilitates the rapid deployment of a coalition network while the dynamic policy provisioning automates the configuration and management of network services including firewalls, virtual private network connections, routing, quality of service (QoS), and domain name services. In this paper, we address these issues through an e-Contract service, where interoperability is obtained using the concept of Web Services and Service Oriented Architecture and the stress-free management is obtained by making the contract executable. We demonstrate it by providing a stress-free universal connectivity service for a tele-Collaboration application in the context of eResearch domain. We next describe the motivations for the work presented in this paper, which come from our involvement in the research and development in advanced telepresence and tele-Collaboration systems. A number of tele-Collaboration projects have been conducted in CSIRO ICT Centre over the past six years as a part of the CeNTIE project. These include:
The Virtual Critical Care Unit (ViCCU®) is a set of high-end tele-Collaboration units (Li et al., 2006), which allows a specialist located at one hospital to supervise a resuscita-
tion team located at a peripheral hospital as shown in Figure 1. ViCCU was designed so that all information required by the specialist to make judgments on patient treatment is available in real time, as if the specialist were present at the peripheral hospital. The realtime information streaming is done using the dedicated high bandwidth network and sophisticated video/audio software design and tuning.
Figure 1. AViCCU in action
The Braccetto Project’s Advanced Tele-Collaboration Workstation (Schremmer et al., 2006) that aims at supporting distributed collaboration of teams of teams of people separated by substantial (continental) distances. The Workstation is modular, and may be setup into a variety of application specific configurations as shown in Figure 2. Each workstation integrates a range of software, technologies and specialised devices (multi touch input, high definition video screens, as well as low latency, high quality audio video system (codecs, amplifiers, speakers, microphones etc), with a shared information space Figure 2 distributed across multiple sites, and connected via high capacity network. The Advanced Tele-Collaboration Workstation is designed to be used in intense interactions involving confidential collaborations and planning exercises. For example, it may be used as mine site planning exercise that involves teams of engineers from different companies in different cities. Discussing and manipulating a shared, common set of drawings or other relevant information or for multi site medical specialist teams involved in performing case reviews. Another example of a secure, trusted dynamic collaboration system’s use would be in planning a military exercise that is co-ordinated between multiple command centres. Fundamental to the work in the Braccetto project is a thorough understanding of both the technical requirements of the application domain, and the way that the technology may be used to augment (and conversely, not interfere with) the way that people wish to work together.
Figure 2. Braccetto Project’s Advanced Tele-Collaboration Workstation Configurations
The Virtual Terminal (VT) is a cross-platform, high performance remote desktop sharing program (Jiang et al., 2007), once again developed within the CeNTIE project to facilitate natural tele-Collaboration. One of the case studies in the use of VT is in remote education, enabling a rich interaction between the class members and teacher: teacher to student, teacher to group of students, student to student or student to multiple students, etc. Lecturers are able to view the screen of any student’s computer, or if required to take control of the student’s computer to guide them through a problem. Finally, lecturer does not need to be within the same physical location as the class, and even the class can be distributed in different locations but connected within a virtual classroom. While the above tele-Collaboration systems focus on different collaborative applications, these applications share the following common requirements: Interoperability: The above tele-Collaboration systems are supposed to be deployed at multiple sites, which are usually located in different physical locations and owned by autonomous organizations (e.g., the Braccetto Project has CSIRO and NICTA in two different Sydney suburbs, with DSTO in Adelaide). Therefore, the foremost requirement for such systems is to enable resources across the business and infrastructure boundaries to work with each other. QoS-Aware Resource Allocation: The tele-Collaboration platforms usually require the delievery of high quality video/audio to each of the workstations, and this in turn heavily depends on the capacity of the underlying infrastructures, i.e., network bandwidth, server speed, transport protocols used, etc. Therefore, it is highly desirable that the underlying middleware is able to ‘intelligently’ allocate, schedule and configure the above resources to meet the certain QoS for a specific application. Security and Trust: Because these systems will be used in multi-party, mission-critical and confidential applications (such as military combat meeting), there is a strong requirement for the system to ensure the security and trust among the collaborators at both application and infrastructure levels.
Ease of Operations (Usability): A use of such complex tele-Collaboration systems usually involves configuration, installation of of special hardware devices and software at multiple sites as well as its on-going maintenance. This in turn, as has been found in any complex system, requires substantial technical effort and intensive coordination for it to be successfully used as intended. Some of the issues faced here are resource (hardware/software) deployment and configuration, scheduling (people, resources, systems, etc.) resource checking and reservation, and resource activation and maintenance. It is unlikely (or at least extremely difficult) for the collaborators themselves (even IT support personnel) to conduct all the above tasks in a consistent and efficient manner. As a result, there is a strong requirement for these platforms to enable the above operations to be conducted As Early As Possible (AEAP) and As Automatically As Possible (AAAP) at all levels, from applications to the underlying infrastructure. For example, a universal connectivity service that provides an easy network configuration across organisational boundaries. This paper addresses the above requirements by proposing and building an e-Contract service which uses the e-Contract to capture the requirements of the collaboration, the contributed resources and their agreements, as well as automatically instantiating and terminating the collaboration and required infrastructure. We next describe the contract template and then the developed contract service architecture for our tele-Collaboration application. WS-CCDL: An Electronic Contract Template Contract
REQUIREMENT
CONTRIBUTION
AGREEMENT
PARTICIPANT
Requirement
Contribution
Agreement
Participant
RESOURCE
ACTIVITY
POLICY
ATTRIBUTE
Resource
Activity
Policy
Attribute
Figure 3 Overview of main WS-CCDL concepts and relationships.
Figure 3 shows the main concepts and their relationships within WS-CCDL. The main entity, called Contract, captures the sub-entities requirements, participants, contributions and agreements. The resources, activities, policies and attributes are used to describe the sub-entities. The following definitions assume the existence of some basic types: ANYTYPE: the set of all types; POLICYTYPE: the set of all policy language types such as EPAL, XACML; RESOURCETYPE: the set of all resources expressed as WSDL; Definition 1: Attribute (keyword: Attr) An attribute refers to a name-value pair used to express certain characteristics of the entities involved in the collaborations. Both name and value are expressed as a value taken from ANYTYPE. The set of attributes associated with entities is called ATTRIBUTE. An attribute name within the ATTRIBUTE is unique. attribute ATTRIBUTE
ATTRUIBUTE Attr , name, value name ANYTYPE , value ANYTYPE
The collaboration is driven by policies. Different organizations participating in the collaboration are operating under their own set of policies. Furthermore, the collaboration is built and operated under the policies defined for different entities and activities. For example, a collaborator can define policies that determine who can participate in the video conferencing. Similarly, a participant contributing resources can specify a set of policies for their contributed resources. Definition 2: Policy (keyword: Pol) A policy refers to an access policy defined for an associated entity. The policy is expressed as POLICYTYPE, and may involve multiple entities. That is, the type of the policy depends on a particular policy language used to express the access policy. The set of policies associated with an entity is called POLICY. policy POLICY
POLICY Pol , p p POLICYTYPE
Different Digital Right Management and access policy expression languages (XACML, 2011; EPAL, 2011; SecPAL, 2011) can be used to describe policies. For example, if the XACML is used to express access policies, the policy type would be XACMLTYPE and the policy expression may involve entities of the collaboration as subjects and objects. A collaboration has a number of participants. In general, participants are categorized in this paper as follows: Initiator – a participant who initiates the collaboration. Invited – participants that are invited by the initiator to participate in a collaboration; Signatory – participants that are authorized by the collaborating organisation to negotiate on their behalf. Both initiator and invited participants are signatory participants.
Contributing - participants contributed by the negotiator to participant in the collaboration. We define such participants as resources with a defined service later in this section. In our framework, we define the signatory participants as follows. Definition 3: Participant (keyword: P) A participant refers to a particular named collaborator with a set of attributes. The identification is based on a unique identity, expressed as ANYTYPE. That is, the type of the identity depends on a particular application domain and is taken from types defined for that domain. The set of participants associated with a collaboration is called PARTICIPANT. An identity of a participant within the PARTICIPANT is unique. The participant also has a set of attributes. participan t PARTICIPAN T id ANYTYPE , PARTICIPAN T P, id , Pol , A Pol { p POLICY }, A {attr ATTRIBUTE}
A unique characteristic of a dynamic collaboration is that it is formed by combing the resources contributed by participants. In our framework, signatory participants contribute resources towards the collaboration. The resources include contributing participants, software, data, tools and information resources. The resources are formally represented as follows. Definition 4: Resource (keyword: Res) A resource refers to an entity that the participant contributes to a collaboration. The identification of resource is based on a unique identity, expressed as RESOURCETYPE. That is, any kind of resources can be incorporated within the collaboration if the type is defined. For example, the storage has a resource type STORAGETYPE. The set of resources associated with a collaboration is called RESOURCE. resource RESOURCE
RESOURCE Re s, r r RESOURCETYPE
Within a collaboration, participants may engage in a number of activities, and each activity may need different set of participants and resources. In our framework, we represent such activities as follows. Definition 5: Activity (keyword: Act) Within a collaboration, participants may be invited or involved in a number of tasks. An activity refers to such tasks. The identification of activity is based on a unique identity, expressed as ANYTYPE. An activity comprises of resources, policies, and participants. The set of activities within a collaboration is called ACTIVITY. activity ACTIVITY id ANYTYPE , P { p PARTICIPAN T }, ACTIVITY ( Act , id , P, Pol , R) Pol { p POLICY }, R {r RESOURCE}
An initiator – the participant who initiates the collaboration - expresses the need of the collaboration through requirement. The requirements specify not only the purpose of the collaboration, but also durations, activities and resources needed for establishing and continuing the collaboration. In order to capture these initial statements about the collaboration, we define the require-
ment as follows. Definition 6: Requirement (keyword: Re) The requirement specifies the activities, resources, and policies that need to be satisfied for the collaboration to occur. The set of requirements associated with a collaboration is called REQUIREMENT. requirement REQUIREMEN T
A {a ATTRIBUTE}, Ac {ac ACTIVITY }, REQUIREMEN T Re, A, Ac , Pol , R Pol { p POLICY }, R {r RESOURCE}
It is also important to note that these requirements are negotiable. That is, a participant may disagree with some of the requirements and may negotiate the changed requirements with other participants using negotiation protocols. Examples of such negotiation protocols will be discussed in the next section. One of the key elements specified in the requirements is resources. The requirement of resources is fulfilled through contributions from the participating parties. The contribution can be done at a specific activity level or at the collaboration level. Also, the contributions need to satisfy the corresponding policies specified in the requirement. Therefore, the contribution of the resources by participants depends on the resource needs specified in the requirements as well as the corresponding policies. We define such contribution as follows. Definition 7: Contribution (keyword: C) A contribution refers to contributions made by a participant towards a collaboration. The contributions by participants include activities, resources, and policies. The set of all contributions associated with a collaboration is called CONTRIBUTION. contributi on CONTRIBUTION
c PARTICIPAN T A { a ATTRIBUTE }, CONTRIBUTION C , c, A, Ac , Pol , R Ac {ac ACTIVITY }, Pol { p POLICY }, R {r RESOURCE}
As mentioned earlier, in the Web Services and SOA environment, such resources can be contributed as services, i.e., Resource-as-a-Service (RaaS). The contributed resources are negotiated among participants. One of the important requirements of the dynamic collaboration is that all participants must agree with each others’ contributions. In the Web Services environment, this means agreement with the contributed services. We define agreement in our framework as follows. Definition 8: Agreement (keyword: A) An agreement refers to an acceptance of a participant’s contribution by other participant. The agreement includes contributor, contribution, and acceptor. The set of all agreements within a collaboration is called AGREEMENT.
agreement AGREEMENT C {c CONTRIBUTION} AGREEMENT ( A, C , con, acc ) con PARTICIPAN T } acc PARTICIPAN T }
We have already defined all the concepts except contract shown in Figure 2. We next define the contract using the above defined concepts as follows. Definition 9: Contract (keyword: Con) A contract is a collaborative context that specifies not only the requirements for the collaboration but also captures the contributions made by the participants. The contract includes collaboration requirements, contributions by participants, agreements among participant and the list of participants. The set of contracts is called CONTRACT. contract CONTRACT
Re {Re REQUIREMEN T C {C CONTRIBUTION} CONTRACT (Con, Re, C , A, P, Atr ) A { A AGREEMENT } P {P PARTICIPAN T Atr {attr ATTRIBUTE}
The above defined framework provides a template for defining a language for describing contract for dynamic collaboration. We have defined one such language using XML schema and implemented in a collaborative scenario. The high-level elements of the language are shown in a snapshot of XML-schema below.
Runtime Framework for the Contract In the previous section, we defined a template for the contract along with its associated elements. It is important to note that the contract itself is not a static entity, and goes through the different phases in its lifecycle as shown in Figure 4. This section describes the four different phases of the contract namely negotiation phase, validation phase, instantiation phase and termination phase.
Negotiation Phase
The negotiation phase involves negotiation among participants about the terms and conditions of the collaboration including contributed resources and policies attached to them. Each party may contribute a set of resources along with associated access policies. A party in the collaboration may disagree with the terms and conditions of the collaboration or a specific set of contributed resources or access policies. In such scenarios, participants may need to re-negotiate the content in the contract. This is facilitated using contract negotiation algorithms.
Terminated Contract
Contract
NEGOTIATION
VALIDATION
Agreed Contract
INSTANTIATION
Instantiable Contract
TERMINATION
Active Contract
Figure 4 Different phases of the contract in a runtime environment.
A set of Web Services standards for negotiations have been proposed for this purpose: WSAgreementNegotiation (Andrieux et al., 2008), WS-Negotiation (Hung et al., 2004), and WSAgreement (Andrieux et al., 2005). WS-Negotiation is a domain independent language for generating agreements between a service provider and a service consumer. WS-Negotiation only considers two parties: a provider and a consumer. WS-Negotiation supports a simple one to one negotiation protocol. Though the objective of WS-Agreement is to have a language and a protocol that not only creates agreements, but also publicizes a service offer, and provides a monitoring service, it also specifies a very simple negotiation protocol that does not allow offer refinement. WS-AgreementNegotiation addresses this shortcoming by allowing negotiation/renegotiation of agreements between two parties. Web Services proposals for negotiation works well in electronic commerce scenario between two parties, but they are not applicable/suitable in multi-party, multi-services negotiation in the context of dynamic collaborations. We have defined protocols for such collaborations in (Nepal et al., 2007; Nepal et al., 2008). The unique characteristic of such protocol is that all parties must agree with each others’ contributions. The negotiation phase ends when the contract meets this characteristic and results in an agreed contract, which we define as follows. Definition 10: Agreed Contract (keyword: AgreedCon) The Contract is said to be agreed if all parties have seen the final contributions from other parties and have agreed with it.
agreedcont ract AGREEDCONTRACT Con CONTRACT Condition AGREEDCONTRACT AgrredCon, Con, Condition i, j Con.PARTICIPAN T , (C , i,....) Con.CONTRIBUTION ( A, C , i, j ) Con. AGREEMENT
Validation Phase The next phase in the contract runtime system is called the validation phase. During this phase the contract is validated against two criteria and the runtime system determines whether the collaboration is instantiable or not. The first criterion is to check whether the resources and activities required for the collaboration are met by the contributions made by the participants. Contributed resources can be categorized into the following two broad categories: Collaboration specific – includes resources contributed to the whole collaboration and not tied to a specific activity. Activity specific – includes resources contributed for specific activities. That means resources specified for the collaboration can be used for a particular activity if the resources contributed for an activity do not satisfy the requirements specified for that activity. We also need to ensure that the resource satisfaction for a contract meet the policy conditions. For example, if a printer is available for a week and the collaboration requires the printer for one month, then the contributed resource can not meet the required resource. We define this check as follows. Definition 11: Resource Satisfied The contract is said to be Resource satisfied if the contributed resources meet all the resource requirements of the contract under the given policy. Let Cnt.Rsrc = CONTRIBUTION.RESOURCE Rq.Rsrc= REQUIREMENT.RESOURCE Cnt.Act.Rsrc = CONTRIBUTION.ACTIVITY.RESOURCE Rq.Act.Rsrc = REQUIREMENT.ACTIVITY.RESOURCE Then ResourceSatisfied(C)= C.Cnt.Rsrc C.Rq.Rsrc C.Cnt.Rsrc C CONTRACT : C.Rq. Act .Rsrc C.Cnt. Act .Rsrc
Definition 11: Resource Satisfied The contract is said to be Resource Satisfied if the contributed resources meet all the resource requirements of the contract under the given policy. Adopting the following shorthand notation: Cnt.Rsrc = CONTRIBUTION.RESOURCE
Rq.Rsrc= REQUIREMENT.RESOURCE Cnt.Act.Rsrc = CONTRIBUTION.ACTIVITY.RESOURCE Rq.Act.Rsrc = REQUIREMENT.ACTIVITY.RESOURCE Then ResourceSatisfied(C) = C.Cnt.Rsrc C.Rq.Rsrc C.Cnt.Rsrc C CONTRACT : C.Rq. Act .Rsrc C.Cnt. Act .Rsrc
The second criterion is to check whether different set of policies specified within the contract are in conflict. As discussed in the previous section, policies are specified at the level of requirements, participants, resources, activities and contributions. Some of these policies can be expected to conflict with each other. For example, a policy may state that participants can access all information related to the collaboration at the requirement level, but the policy specified at the contribution by a participant may prevent certain participants accessing some information. The policies need to be checked and any conflicts that arise need to be resolved. The final set of policies must satisfy the requirements for the collaboration and activities within it. We define this process formally as follows. Definition 12: Policy Satisfied The contract is said to be policy satisfied if the policies expressed in the contract are not conflicting each other. Let Cnt.Pol = CONTRIBUTION.POLICY Cnt.APol = CONTRIBUTION.ACTIVITY.POLICY Rq.APol = REQUIREMENT.ACTIVITY.POLICY P.Pol = PARTICIPANT.POLICY C CONTRACT : PolicySati sfied (C ) C.Cnt.PolC.Rq.Pol C.Rq. APol C.Cnt. APol C.P.Pol NULL
After the successful checking of the two criteria above, we need to check whether the contract is instantiable or not. We define the contract is instantiable if it is agreed by all participant and satisfies both policy and resource requirements as follows. Definition 13: Instantiable The contract is said to be instantiable if it is agreed by all participants, and is both policy and resource satisfied. C CONTRACT : Ins tan tiable (C ) C AGREEDCONTRACT PolicySati sfied (C ) Re sourceSatisfied (C )
It is important to note that the above definition does not cover some of the technical aspects
such as all resources specified must have a valid address and they are online. These aspects are dynamic and included in the monitoring of contract, which is yet to be defined in our framework.
Instantiation Phase
This phase involves interpretation of contract. The interpretation of contract is performed by an instantiation engine and results in an instantiation of the collaboration. Once the collaboration is established, the contract is said to be active. We define an active contract as follows using an attribute value within the contract. Definition 14: Active Contract The contract is said to be active if it has been instantiated and has not been terminated. C CONTRACT : ACTIVE (C ) C AGREEDCONTRACT C.a.state " Active"
Termination Phase
The last phase of the runtime environment is called termination, where the collaboration is terminated as per contract or in an agreed manner. We define one such termination protocol using WS-BusinessActivity in (Nepal et al., 2008). Other distributed termination protocols can be used. We use a state attribute value to define the terminated contract as follows. Definition 15: Terminated Contract The contract is said to be terminated if all parties agreed to terminate the instantiated collaboration. C CONTRACT : TERMINATED (C ) C AGREEDCONTRACT C.a.state "Ter min ated "
A Case Study: Connectivity Service for Tele-Collaboration
Scenario Consider an application scenario in which three research organizations (participants A, B. C) wish to collaborate to solve a scientific problem. As part of the collaborations, researchers from each participating institute need to share resources with the collaboration, such as their own data and knowledge. These collaborators will need to deploy a secure network connection to protect the privacy and security requirements of the collaborators, and use a suitable tele-Collaboration technology (such as our Virtual Terminal (VT) system) to share resources.
3rd Party Services eContract Service
Databas e
Use
Various Services
Web Service
Enable
Use A Dynamic Collabortion Domain A Use
Use
Collaborator
A Dynamic Intranet
Domain B
Collaborator
Machine
Machine
Domain C
Collaborator
Machine
Figure 5. Overall architecture of e-Contract service for dynamic business collaborations
In order to demonstrate the establishment and deployment of a “stress-free” secure network connection using the e-Contract concepts described earlier, we designed and implemented an eContract service with the focus on (but not restricted to) providing a network connectivity service for tele-Collaboration applications. Our design assumes that this service will be provided by a third party, whose business is to provide a secure, managed network connectivity to the clients, in this case, the three participant organizations. The overall architecture for the e-Contract service is shown in Figure 5. We next describe each component in this architecture and how they interact with each other as follows.Initially, each collaborator resides within its own administrative domain and may be unknown to the other collaborators. To collaborate with others, they all subscribe to the services provided by the e-Contract service provider so that they can either set up or be invited to join into a dynamic collaboration via an e-Contract. Suppose a collaborator A wants to set a dynamic collaboration with other collaborators B and C.. Collaborator A initializes an e-Contract by discovering and adding the collaborators B and C whom he/she likes to collaborate with as participants. He may also list the resources (such as VT components) required for this collaboration and his resource contributions in the contract. After the e-Contract is submitted, the invited collaborators will be automatically informed that they are invited to collaborate with the other parties. They can decide to accept or decline the invitation via the e-Contract service. If they decide to join the collaboration, each can negotiate the specifics of the content in the e-Contract with all the other participants following the previously described negotiation procedure and protocol. Once all participants agree upon and sign the e-Contract, the e-Contract is executed and the secure network connection will be established between the participants. Then, the collaboration is ready to run using tele-Collaboration tool (e.g., VT). Messaging-Oriented Interface
Web Services are fundamentally message oriented and loosely coupled. However, most of the current Web Services implementations are still RPC-based and do not support asynchronous
messaging very well (Pautasso et al., 2008). This means that any updating on the service functionalities would result in changes at both service-side interfaces (e.g., WSDL) and client-side code (e.g again, this is generated from the WSDL). On the other hand, the schema of the eContract may also be updated from time to time to enrich its semantic and representation. This would also result in updating the e-Contract service interface if the schema of the e-Contract is visible in the interface. To address the above two issues, we designed a single messaging-oriented interface and a generic message type as follows: MessageType Send(MessageType msg);
where the attribute (‘ServiceName’) is used to specify which service/operation is required to process the message; AppData is a set of (XML) data used as application (functional) data for the specified service; MetaData is a set of (XML) data used as ‘extra’ (non-functional) data for the service, such as username, encrypted password, encrypt keysID, exception, performance testing etc. The details about AppData and MetaData are as follows:
where Data is defined as xs:string to host any XML, including an e-Contract.
where Property is a name and value pair for any properties required for a specific transaction. This web service interface design offers the following features: Stability: Since this interface and data model is very generic, it can remain relatively stable for both client and service side code-base. Extendibility: Because of its flexible data mode, it allows us to exchange various application data and add new metadata for a variety of purposes without the change in the overall data structure and generated underlying web service code. Portability: Having a single interface and a generic data model, it allows us to easily bind our web service to other messaging protocols and/or web services middleware. Services and Protocols
To facilitate e-Contract-based collaborations, the e-Contract service provides the following basic service operations: Registration service enables collaborators to subscribe the service by signing on; SearchCollabortors helps collaborators to find the participants for the collaboration; SearchContracts returns a list of e-Contracts when the operation is invoked; GetContract returns a specific e-Contract when the operation is invoked; SubmitContract is used by collaborators to submit an e-Contract to the e-Contract service for distribution and negotiation; Deployment operation is used to instantiate the agreed contract; The detailed specifications and protocols for each operation are provided in Table 1. We explain these protocols using a simple scenario described earlier, where a collaboration is formed among three participants (A, B, C), as shown in Figure 6. Services
Items
Descriptions/Definition
Description Request
Response
Description Request
Response Description
Request
Registration
SearchCollabortors
CheckContracts
A client can register itself by sending the following AppData. Subject=“Registration” AppData: SchemaName=“Participant” Data=“…” MetaData: GroupName=“Security” o Property: name=“MyPublicKey” value=“…” (for exchanging public key) Subject=”RegistrationReply” AppData = null MetaData: Attributes: GroupName=“Security” o Property: Name=“userID” Value=“XYZ” o Property: Name=“password” Vaule=“#$%^&*&*C o Property: name=“MyPublicKey” value=“…” (for exchanging public key) A client can search potential collaborators with keywords. Subject=“SearchCollaortors” AppData: SchemaName=“String” Data=“Keyword1&Keyword2…” MetaData: GroupName=“Security” o Property: name=“UserID value=”…” o Property: Name=”password” Vaule=”#$%^&*&*C “ Subject=”SearchCollaboratorsReply” AppData: SchemaName=”Participants” Data=”…” A client can check all contracts associated with itself, including invited, jointed, assigned Subject=“CheckContracts”
Response Description Request
GetContract
Response
SubmitContract
Description Request
Response
Description Deployment
Request
Response
AppData:SchemaName=“String”, Data= “Setup|Invited|Joined|All” MetaData: GroupName=“Security” o Property: name=“UserID value=”…” Property: Name=“password” Vaule=“#$%^&*&*C” Subject=“ CheckContractsReply” AppDatas: a list of SchemaName=“String”, Data=“ContractID|Description|State” A client can get a specific contract with the contract ID Subject=“GetContract” AppData: SchemaName=“Contract”, Data=“…” MetaData: GroupName=“Security” o Property: name=“UserID value=”…” Property: Name=“password” Vaule=“#$%^&*&*C” Subject=“GetContractReply” AppData: SchemaName=“Contract”, Data=“…” A client can submit a contract for different proposes Subject=”SubmitContract” AppData: SchemaName=“Contract”, Data=“…” MetaData: GroupName=“Security” o Property: name=“UserID value=”…” o Property: Name=“password” Vaule=“#$%^&*&*C” o Property: Name=”Type” Value=”new|update|decline|sign” Subject=”SubmitContractReploy” AppData: SchemaName=”String” Data=”ContratcID” MetaData=null A client deploys a contract by downloading a VMware image from the e-Contract service Subject=Download AppData: : SchemaName=”String” Data=”ContratcID” MetaData: GroupName=“Security” o Property: name=“UserID value=”…” Property: Name=“password” Vaule=“#$%^&*&*C” Subject=DownloadReploy AppData: SchemaName=”VMwareImage” Data=null (using SOAP attachment)
Table 1. Specifications of the e-Contract services and corresponding protocols
Participant A
Participant B
Participant C
eContract Service
3rd Party Services
Registration
Registration Do the same
Do the same
Search collaborators, whose reseach areas are: X, Y, Z Return: Participant B, C and maybe others
Initialisation
Submit a new eContract to invite Participant B & C Search all contracts assoicated with me Return: a list of contrats Return: eContract (ID=0001) Submit a revise contract
Negotiation Do the same Sign the contract Sign the contract Sign the contract
Validation
Validating eContract To buy the request servics deployment
Instantiation
Configure VMware
Return: a pre-configured VMware
Do the same
Do the same
Figure 6. Sequences of interactions between components to form a collaboration at different phases as shown in Figure 4 (except for termination)
Implementation
We implemented the above design using the following products/technologies: e-Contract Web Service: SUN Glassfish v2.0 BackendDatabase: MySQL v5.122 VPN Server: OpenVPN v2.1 Virtual Machine: VMPlayer v2.0.1 e-Contract Client: SUN JDK 1.6, including Swing and JAXB Figure 6 shows a runtime environment of our prototype system. First, participants A, B, C registered with the e-Contract Service. Then, a participant A initializes an e-Contract by inviting two participants B and C via the e-Contract Service client shown in Figure 7. The signed eContract for the connectivity service is shown in Figure 8. Once the contract is signed, participants can deploy the contract and initiate the secure network connectivity. Once the connectivity is established, participants can use the VT (Jiang et al., 2007) to collaborate with each other.
(a) inviting collaboration participants
(b) Signed e-Contract to be deployed Figure 7. The screenshots of the e-Contract prototype system
Suppressed initiator Suppressed participant Software engineer,c/c++,java,perl,linux,macosx 0001 Open VPN Driver 0002 VT Client Lin089 Open VPN Driver Lin089 VT Client Ner005 Open VPN Driver Ner005 VT Client
+llp4pVrVBr3h/RnIAdIXTDas+Y= DZn8HWsXBtc5rUM9Os5SHWpOQ3/gcqGfO1FPtxwk+g8FnU7n3xztLsLubMuSt5BLbP……. CN=Ner005,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown WCZBfPsCl+7r2//Z76DiEFCrLZgDn0GYNPFBBZr2aY4V2MTSAy3xi...... +llp4pVrVBr3h/RnIAdIXTDas+Y= FlGysAmLkxw/oAFk6I2Y0yig/c3wctle+9pr8xvVpMAZv35DfGQ4nXB………. CN=Ner005,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown MIICTTCCAbagAwIBAgIESCkMWjANBgkqhkiG9w0BAQUFADBrMRAwDgY……
Figure 8. A secure connection e-Contract signed by two participants/organizations
Conclusions This paper presented a Web Services based solution for facilitating multi-party dynamic collaborations among collaborators. Our solution is based on the concept of an e-Contract that was used for capturing and negotiating the basic resource requirements for a dynamic collaboration, as well as for instantiating these resources as a single service deliverable by the e-Contract service. First, the paper presented a framework for a Web Service Collaborative Context Definition Language (WS-CCDL) to define an e-Contract for a dynamic collaboration between partners. WS-CCDL is a XML schema used to specify the data components required in a collaboration eContract. An initial draft of the e-Contract serves as basis for the collaborators to negotiate resources (that can be expressed as Web Services) and policies for the collaboration. We have also devised a runtime framework for contracts. A language for the framework has been defined using XML Schema. Second, the framework is prototyped for an instance of a collaborative environment to provide secure connectivity service for a tele-Collaboration scenario in the context of e-Research applications. The prototype system provided us evidence that it is feasible to develop a contract driven dynamic collaboration using our proposed framework. We also observed that we need to decouple the e-Contract schema with the e-Contract web service interface in order to provide flexibility and adaptability with the dynamic nature of the collaboration. We designed a single web
service interface with a generic message based data model to accommodate a variety of service operations and the corresponding protocols. It is important here to emphasize that the framework in its current state only captures the necessary elements for negotiation, validation and instantiation. At present, our framework captures obligations at the coarse level such as resources are available for the agreed duration. We plan to extend it to capture obligations at greater details. Similarly, we plan to extend the runtime framework by introducing a phase for monitoring those obligations. Our planned future work also include (a) extension and customization of e-Contract in terms of semantics and resources types; (b) enhancing the e-Contract service by building essential functional components, such as a monitoring service and policy engine. We also plan to deploy and offer the e-Contract service to our other existing collaboration partners through the use of existing platforms such as ViCCU in eHealth and Braccetto in e-Research. Acknowledgements We wish to acknowledge the contributions of Lingbo Jiang, Nerolie Oakes and Chen Wang towards developing the prototype system. Thanks also go to John Zic and Alex Krumm-Heller for their inputs to the requirements of tele-Collaboration applications to motivate this work. References Andrieux, A. , Czajkowski, K. , Dan, A. , Keahey, K. , Ludwig, H. , Pruyne, J. , Rofrano, J., Tuecke, S. and Xu, M. (2011). Web Services Agreement Negotiation Specification (WS-AgreementNegotiation), version 1, access at http://forge.ogf.org/sf/go/doc6092?nav=1 Andrieux, A., Czajkowski, K., Dan, A., Keahey, K., and Heiko, L. (2005) WS-Agreement Specification. Accessed at URL http://www.gridforum.rg/Meetings/GGF11/Documents/ draft-ggf-graap-agreement.pdf 2005. Chan, J., Nepal, S., Moreland, D., Hwang, H., Chen, S. and Zic, J. (2007) User-Controlled Collaborations in the Context of Trust Extended Environments. Proceedings of IEEE International Workshops on EnablingTechnologies: Infrastructures for Collaborative Enterprises (WETICE), 2007. Chiu, D.K.W., Cheung, S.C., Leung, H.-f., Hung, P.C.K., Kafeza, E., Hu, H., et al. (2010). Engineering e-Collaboration Services with a Multi-Agent System Approach. International Journal of Systems and Service-oriented Engineering (IJSSOE), 1(1), 2010 Department of Education, Science and Training (2006) Australia. An Australian e-Research Strategy and Implementation Framework. Report, 4/2006. EPAL. (2011) http://www.zurich.ibm.com/security/enterprise-privacy/epal/ Foster, I., Kesselman,C. And Tuecke, S. (2001). The Anatomy of the Grid: Enabling Scalable Virtual Organizations. International Journal of High Performance Computing Applications, Vol. 15, No. 3, 2001, pp. 200-222. Freudenthal, E., Pesin, T., Keenan, E., Port, L. and Karamcheti, V.(2002). dRBAC: Distributed Role-Based Access Control for Dynamic Collaboration Environments, Proc. of the ICDCS, 2002, pp. 411-420. Fujitsa , S. (2004). Dynamic Collaboration of Businesses using Web Services. NEC Journal of Advanced Technology Vol 1, No. 1, pp. 36-42, 2004. Globus (2011). http://www.globus.org/grid_software/monitoring/ Handley, H. A., Wentz, H. L. and Levis, A. H. (2002). Continuity in Dynamic Coalition Operations. Proc. 7th Int'l Command and Control Research and Technology Symposium, Monterey, CA, June 2002. Handley, H.A.H., Wentz, L. and Levis, A. H. (2002) Continuity in Dynamic Coalition Operations. Proc. 7th Int'l Command and Control Research and Technology Symposium, Monterey, CA, June 2002. Hung, P.C.K., Li, H., and Jeng , J.J. (2004) WS-Negotiation: An overview of research issues. Proc. of the 37th Hawaii International Conference on System Sciences, 2004 Jiang , L., Krumm-Heller. A. and Mueller-Tomfelde, C. (2007). The Virtual Terminal: a cross-platform high performance
remote desktop sharing program, CSIRO ICT Centre Conference, 2007 Jirotka, M., Procter, R. Rodden, T. and Bowker, G. C. (2006) Special Issue: Collaboration in e-Research Computer Supported Cooperative Work (2006) 15:251–255
Joint Vision 2010 (2011) http://www.dtic.mil/jointvision/history/jv2010.pdf Joint Vision 2020 (2011): America‘s Military. JFQ, pp. 58-72, Summer 2000 http://www.dtic.mil/doctrine/jel/jfq_pubs/1225.pdf Jopling, E. and Neil, D. (2005) VNO Phenomenon Could Shake Up the World's Telecom Market. Gartner Research report G00131283. Nov. 2005. Keller, A. and Ludwig , H. (2002) Defining and Monitoring Service-Level Agreements for Dynamic e-Business. 16th System Administration Conference, pp.189-204, 2002. Khurana, H., Gavrila, S., Bobba, R., Koleva, R., Sonalker, A., Dinu, E., Gligor, V. and Baras, J.S (2003) Integrated Security Services for Dynamic Coalitions, Proc. of the third DARPA Information Survivability Conference and Exposition, Washington D.C., April 2003, pp. 38-40. Khurana, H., Gligor, V.D. (2004). A Model for Access Negotiations in Dynamic Collaborations. Proc. of the 13th IEEE WETICE, 2004, pp. 205-210. King ,R. (1991) Cooperation, coordination and control in computer-supported work. Communications of the ACM Vol. 34, No. 12, 83-88. Li, J., Wilson, L. S., Qiao, R. Y., Percival, T. , Krumm-Heller, A. , Stapleton, S. and Cregan, P. (2006) "Development of a broadband telehealth system for critical care: process and lessons learned," Telemed J E. Health., vol. 12, no. 5, pp. 552-560, Oct.2006. Liu, M., Yan, J.W. and Bai, L. (2007) The Inter-operating Mechanism of the Alliance-Collaboration-Oriented Dynamic Grid Workflow, IEEE international Conference on Intehration Technology, 2007, pp. 301-306. Ludwig, H., Keller, A., Dan, A., King, R. P., and Franck, R. (2003) Web Service Level Agreement (WSLA) Language Specification. Access at http://www.research.ibm.com/wsla/WSLASpecV1-20030128.pdf 2003 Ma, D. (2007) The Business Model of “Software-as-a-Service”. IEEE International Conference on Services Computing (SCC 2007), pp. 701-702. Mowshowitz, A. (1994). Virtual Organization: A vision of management in the information age. The Information Society, Vol. 10, No. 4, 1994, pp. 267-288. Nepal, S. , Zic,, J., and Chan, J. (2007a) A distributed Approach for Negotiating Resource Contributions in Dynamic Collaboration. The Eight International Conference on Parallel and Distributed Computing, Applications and Technologies (PDCAT 2007), pp. 82-86. 3-6 Dec 2007. Nepal, S., Zic, J. (2008a) A Conflict Neighbouring Negotiation Algorithm for Resource Services in Dynamic Collaborations IEEE International Conference on Service Computing (SCC), 2008, July 8-11, 2008, Hawaii, USA Nepal, S., Zic, J., Chen, S. (2008b). WSLA+: Web Service Level Agreement Language for Collaborations. IEEE International Conference on Service Computing (SCC), 2008, July 8-11, 2008, Hawaii, USA Paschke, A. and Bichler, M. (2005), SLA representation, management and enforcement, Proc of The 2005 IEEE International Conference on e-Technology, e-Commerce and e-Service (EEE’05), 29 March-1 April 2005 p158-163 Patz, G., Condell, M., Krishnan, R., and Sanchez, L. (2001) Multidimensional Security Policy Management for Dynamic Collaborations, DARPA Information Survivability Conference and Exposition 2001. Pautasso, C., Zimmermann, O. and Leymann, F. (2008). RESTful Web Services vs. “Big” Web Services: Making the Right Architectural Decision. WWW 2008, pp. 805-814. Perez, G. M., Skarmeta, A.F.G., Zeber, S., Spagnolo, J. and Symchych , T. (2006). Dynamic Policy-Based Network Management for a Secure Coalition Environment. IEEE Communications Magazine, Vol. 44, No. 11 pp. 58-64, 2006. Phillips,C. E., Ting, T.C. , and Demurjian, S.A. (2002). Information sharing and security in dynamic coalitions. Proceedings of the seventh ACM symposium on Access control models and technologies, 2002, pp. 87-96. Qiao, R.-Y. Wilson, L. S., Li, J., Stapleton, S. and Cregan, P. (2004) ViCCU-application of ultra-broadband Internet for complex, critical care telemedicine. Telehealth J. and e-Health, 10(Suppl. 1):S-58, 2004. Radha Krishna, P. , Karlapalem, K. and Dani, A. R. (2005) From Contracts to E-Contracts: Modeling and Enactment, Information Technology and Management, 6, pp 363-387, 2005 Nepal, S., Chan, J., Chen, S., Moreland D., and Zic, J. An Infrastructure Virtualisation SOA for VNO-based Business Models, IEEE International Conference on Services Computing (SCC 2007), July 2007, pp-41-51 Schremmer, C., Krumm-Heller, A., Vernik, R., and Epps, J. (2007) Design Discussion of the [braccetto] Research Platform: Supporting Distributed Intensely Collaborating Creative Teams of Teams. HCI (4) 2007: 722-734 Seamons, K.E., Chan, T., Child, E., Halcrow, M., Hess, A., Holt, J., Jacobson, J., Jarvis, R., Patty, A. , Smith, B., Sundelin, T. , and Yu. L. (2003) TrustBuilder: Negotiating Trust in Dynamic Collaborations. Proc. of the DARPA Information Survivability Conference and Exposition, 2003, pp. 49-51. SecPAL (2011) http://research.microsoft.com/projects/secpal/ Skarmeta, A.F.G. and Perez, G. M. (2004). Policy-based dynamic provision of IP services in a secure VPN coalition scenario. IEEE Communications Magazine, Vol. 42, No. 11, pp. 118-124, 2004. Tsai, W. T., Huang, Q., Xiao, B., Chen, Y. and Zhou, X. (2007). Collaboration Policy Generation in Dynamic Collaborative SOA. Proceedings of the Eighth International Symposium on Autonomous Decentralized Systems, 2007, pp. 33-42.
Tsai, W. T., Huang, Q., Xiao, B., Chenm, Y. and Zhou, X. (2007). Collaboration Policy Generation in Dynamic Collaborative SOA. Proceedings of the Eighth International Symposium on Autonomous Decentralized Systems, 2007, pp. 33-42. Tsai, W.T., Huang, Q., Xu, J., Chen, Y. and Paul, R. (2007a) Ontology-based Dynamic Process Collaboration in ServiceOriented Architecture IEEE International Conference on Service-Oriented Computing and Applications (SOCA '07), 2007 pp. 39-46. XACML. (2011) http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml Xu L. , and Jeusfeld, M.A. (2003) Pro-active Monitoring of Electronic Contracts, Proceedings of the Advanced Information Systems Engineering (CaiSE 2003), Springer-Verlag LNCS 2681 (2003), p:584-600 Yamazaki, Y. (2004) “Dynamic Collaboration”: the model of new business that quickly responds to changes in the market through “The integrated IT/Network Solutions” provided by NEC. NEC Journal of Advanced Technology Vol 1, No. 1, 2004, pp. 9-16.
