Verification Framework for Dynamic Collaborative Services in Service-Oriented Architecture

W. T. Tsai, Qian Huang, Bingnan Xiao, and Yinong ChenArizona State University, Tempe, AZ 85287-8809, USA

{wtsai, qhuang, bnxiao, yinong}@asu.edu

Abstract

This paper introduces a dynamic verification framework for collaborative services in Service-Oriented Architecture (SOA). Collaboration plays a critical role in SOA, an effective verification framework for collaboration will greatly reduce the effort for rapid and adaptive service composition and evaluation of applications based on collaborative services. The verification framework provides a service-oriented infrastructure for completeness and consistency analyses, model-checking, simulation, and policy enforcement of process specification based on collaborative services in SOA. The paper presents the concepts, architecture, profiling techniques and illustrative examples that demonstrate the concepts and the techniques.

1. Introduction

Service-Oriented Architecture (SOA) is a new paradigm for software development [7][10]. Service collaboration is essential in SOA because a complex service is always composed of several constituent services. Recently, ebXML has introduced a set of dynamic collaboration protocols (DCP) such as CPP (Collaboration Protocol Profile) and CPA (Collaboration Protocol Agreement), the key concept of DCP is that services will determine their collaboration at runtime. This new dynamism also introduces new challenges in verification and validation (V&V) of SOA applications.

This paper introduces a dynamic collaboration verification framework for dynamic process collaboration in SOA. The framework provides support for static and dynamic analyses including consistency analysis, use scenario compatibility analysis, model checking, simulation, dynamic testing, and policy enforcement to evaluate large scale distributed service-oriented systems.

The rest of this paper is organized as follows. Section 2 outlines the dynamic collaboration framework. Section 3 presents the collaboration verification framework in detail. Section 4 illustrates

the verification process in the dynamic collaboration framework using an example. Section 5 concludes the paper and discusses future work.

2. Dynamic Service Collaboration

2.1. Evolution of Process Collaboration Process collaboration requires more than data

collaborations. It requires not only interoperability, but also collaboration among participating parties to achieve the designated mission.

Procedural Paradigm: Collaboration is often achieved statically via procedure calls, and most procedure calls must be explicitly specified in the code.

Object-Oriented paradigm: data and its processing are bound together. Collaboration can be achieved through message passing. Furthermore, polymorphism and dynamic binding allow actual methods called to be determined at runtime. However, the methods selected are still limited to the methods pre-implemented in the inheritance hierarchy.

SOA paradigm: data may not be bound with its processing any more, services are discovered and composed dynamically. However, services collaborate with each other according a pre-specified workflow even though the workflow can be updated. Thus, the collaboration parties may be determined at runtime, but collaboration protocols are often fixed.

DCP in SOA: This is still in the SOA paradigm, but with DCP both collaboration parties and collaboration protocols are determined at runtime. This approach is implemented by OASIS CPP/CPA [7] and PSML-C. This approach is more agile than the conventional SOA. A typical DCP process can be divided into four stages: Preparation/Profiling stage: In this stage,

each service that wishes to participate in DCP must prepare a CPP which contains the list of protocols that the service can understand. The CPP can be updated as the service learns from actual collaboration.

Establishment stage: In this stage, participating services will exchange their CPPs, and

agree on a common protocol CPA that all participating services share.

Execution stage: In this phase, participating services will collaborate based on the CPA established earlier. Data may be collected so that CPP can be updated for future collaboration.

Termination stage: In this phase, participating services terminate the collaboration, and update their own CPPs based on the data collected. The collaboration session may be evaluated so that future collaboration can be improved.ebXML has defined its CPP and CPA standards,

however the kinds of collaboration that can be implemented using ebXML’s CPP and CPA are limited. We have proposed an extended set of CPP and CPA to allow more flexible collaboration. The extension is shown below and in Table 1: ECPP (Extended Collaboration Protocol Profile) ECPA (Extended Collaboration Protocol

Agreement) USS (Use Scenario Specification) IPS (Internal Process Specification) CIS (Collaboration Interface Specification)

Table 1: Service collaboration specificationsSpec Information

ECPP Describes service collaboration capabilities.ECPA Describes the collaboration interactions

among the collaborative services.USS Describes how to carry out a specific

collaboration with respect to a given ECPP.IPS Specifies service internal control logic.CIS Defines service collaboration interfaces.

Figure 1: Dynamic collaboration protocol

Figure 1 shows the dynamic collaboration protocol for process collaboration.

2.2. Extended Collaboration Protocol Profile (ECPP)

An ECPP is a quadruple of (START, END, IN, OUT), where: START is the set of start points where START ≠ ø

or CardinalitySTART ≥ 1. END is the set of end points where END ≠ ø or

CardinalityEND ≥ 1. IN is the set of incoming collaboration points. OUT is the set of outgoing collaboration points.

An example of an ECPP specification for a simple online banking service is:

START = {Login}END = {Logout}IN = {ApproveLoan}OUT = {CreditCheck}

2.3. Extended Collaboration Protocol Agreement (ECPA)

The ECPA extends the ebXML CPA by adding collaboration transactions set. When two processes need to collaborate with each other, they need to negotiate with each other to specify possible/valid collaboration transactions. An ECPA adds a set CT (Collaboration Transactions) which specifies a collection of collaboration transactions. A collaboration transaction is a pair of (out, in) where in IN1 and out OUT2 and IN1 is the IN set and OUT2

is the OUT set of participating collaboration services respectively. For two services to collaborate, the set CT must be a non-empty set.

An example of the CT set for an ECPA specification between an online banking service and a credit service is:

CT = {(CreditCheck, ProcessCreditChecking), (CreditOK, ApproveLoan)}

2.4. Use Scenario Specification (USS)Use scenario is a specification on how the service

can be used by other services [11]. To be more specific, a use scenario indicates the temporal logic and/or timing constraints on a sequence of function calls. It provides a usage pattern on how to invoke the interfaces for the service.

The USS uses a variety of specification language including the Linear Temporal Logic (LTL) to specify the usage pattern of the service with respect to a specific collaboration. As a result, a use scenario specification is built up from a set of proposition variables p1, p2,..., the usual logic connectives , , , and , and the temporal modal operators N (for next), G (for always), F (for eventually), U (for until), and R (for release).

An example of a use scenario specification for online banking service is:

Login F Logoutwhich means any login operation must finally

followed by a logout operation.

2.5. Internal Process Specification (IPS)This is an internal process specification which

specifies what the internal control logic for a specific service. With the internal process specification information, service matching technologies can verify both the interface information as well as the internal process specification. An example of internal process

specification of a simple online banking service is the auto loan application process specification that requires the collaboration with credit monitoring service for credit checking.

2.6. Collaboration Interface Specification (CIS)

This is a specification listing all interfaces of a service for collaborations. Interfaces have two types: in type interfaces take incoming events and out type interfaces issue out going events. Interfaces will be mapped to the collaboration points defined in the ECPP in a specific collaboration.

An example of interfaces specification of a simple online banking service is:

out SendMsg(MESSAGE)in GetMsg(MESSAGE)

where the SendMsg interface is an out type interface that can be used to request credit information and the GetMsg interface is an in type interface that can be used to get credit information from credit monitoring services.

3. Verification Framework for DCP

The DCP provides a challenging environment for verification. One can see the evolution of challenges for verification as follows: Traditionally, systems and software are verified

using the IV&V (Independent Verification and Validation) approach, where independent teams are used to verify and validate the system during system development.

The SOA challenges the IV&V approach as new services will be discovered after deployment, and thus it is necessary to have CV&V (Collaborative Verification and Validation) approach [1] where service brokers, providers and consumers work in a collaborative manner, and some of testing need to be performed at runtime, e.g., when a new service is discovered and being incorporated into the application.

The DCP is even more challenging than the conventional SOA because even the collaboration will be determined at runtime. While it is possible to re-specify the workflow at runtime during the dynamic reconfiguration in conventional SOA, it is different in DCP, where the actual collaboration is unknown until the participating services dynamically establish the protocol. Table 2 summarizes the comparison of traditional

IV&V, SOA CV&V, and DCP Collaboration V&V.

Table 2: Comparison of Independent Verification, Collaborative Verification & Dynamic Collaboration

Verification

Traditional IV&V Service-Oriented CV&V DCP Collaboration V&VApplication

ModelStatically constructed based on specification.

Workflow is specified but services can be dynamically discovered.

Dynamic application composition via run-time service collaboration

Operational testing

Off-line field testing or simulation.

On-line just-in-time testing in the application environment.

On-line just-in-time testing in the collaboration environment

Regression testing

Off-line regression testing. On-line regression testing using data dynamically collected.

Historical collaboration data can be re-played for regression testing.

Verification Approach

The verification team is independent of the development team to ensure objectivity and to avoid common-mode errors. Mostly done by software providers.

Verification by collaboration among service providers, application builders, and independent service brokers. The emphases are on runtime and just-in-time testing, and evaluation using data dynamically collected.

Before the establishment of collaboration protocol at runtime, a service has a partial view only, and thus verification will be limited. As the complete collaboration will be available at runtime, verification need to be performed at runtime.

Testing coverage

Input domain, structural (white-box), or functional (black-box) coverage.

Service providers can have traditional coverage, and service brokers and clients may have black-box (such as WSDL) coverage only.

As each service will have a partial view only, test coverage can be completed only when the actual collaboration is established.

Test case profiling

Static profiling Dynamic profiling with data collected by distributed agents.

Dynamic profiling and re-profiling at collaboration runtime

SimulationSpecification and models are simulated to verify the design and/or code

Just-in-time on-the-fly simulation for composite service

Simulation before deployment, on-the-fly simulation when protocol and parties are known at runtime.

Integration testing

Static configurations and systems must be linked before integration testing

Dynamic configuration and systems are linked at runtime and verified at runtime

Dynamic configuration and collaboration are established at runtime and verified at runtime

Model Checking

Model checking on the code or state model.

Just-in-time dynamic model checking on the specification in, e.g., WSDL and OWLS.

Model checking can be performed on the partial view, and again when the complete view is available.

The DCP process is divided into four stages, each stage has its own verification requirements and constraints. The following table shows the verification techniques that are applicable to each stage.

Table 3: Verification in Each DCP Stage Stage Static Dynamic

Prepare/Profiling

Process Consistency /

Model Checking

Simulation / Policy Enforcement / Test

Agent

Establishment N/AUSS compatibility

check / Simulation / Test Agent

Execution N/APolicy Enforcement / Monitoring / Test

Agent

Termination Update Profiling Policy Specification

/ Test Agent

3.1. Preparation / Profiling Stage VerificationIn this stage, the collaboration partner information

is unknown to the service. Thus, services have only has a partial view of the overall collaboration. Since the service specification is not available for the collaboration partner, the verification can only be performed based on the sample CPA that is stored in the service profile. The service profile can be later updated in the collaboration termination stage based on the data collected in the collaboration execution stage. Table 4 shows the specification completeness in collaboration preparation / profiling stage.

Table 4: Specification CompletenessSpec Completeness

ECPP Partial view with local ECPP onlyECPA Has previous sample ECPAUSS Partial view with local USS onlyIPS Partial view with local IPS onlyCIS Partial view with local CIS only

Static Analyses Completeness & Consistency (C&C) Checking

Various C&C can be performed on specifications to ensure that they are consistent and complete with each other based on following criteria:

element (element SETDefinition element SETIPS)and

element (element SETIPS element SETDefinition)denoting that for each element defined in the model,

it must be used in the IPS; and for each element used in the IPS, it must be defined in the model.

For examples, an online banking service specifies the following IPS:

LoginCheckBalanceWithdrawLogoutThen all operations specified in the IPS including

Login, CheckBalance, Withdraw, and Logout must be defined in the PSML-C model for the online banking service. On the other hand, if the Deposit operation is defined in the PSML-C model, it must be used in one of the IPS. Otherwise, the Deposit operation can not be included in any IPS. Consistency Checking by Model Checking

In the collaboration preparation / profiling stage, model checking ensures the collaboration capabilities specified in the ECPP is consistent with the internal process and the internal process specification satisfies the constraints specified in use scenario. If inconsistency exists, the ECPA established at runtime may not guarantee the collaboration can be carried out or the collaboration will be inefficient. As shown in Figure 1, there are ECPP, USS, and IPS for a given service in this stage that need to be verified. Service verification needs to be performed by:

Consistency model checking on USS and IPS Consistency model checking on ECPP and IPSTo perform the consistency model checking on USS

and IPS, model checking can be used to check whether the IPS follows the constraint specified in USS. Specifically, an IPS will be verified against the LTL formula specified in the USS.

For example, an online banking service specifies an LTL formula as followed:

(Login F Logout) (Login R Withdraw)and the following IPS:

LoginCheckBalanceWithdrawLogoutis a valid IPS, but

LoginCheckBalanceWithdrawand

CheckBalanceWithdrawLogoutare both invalid IPS.To perform the consistency model checking on

ECPP and IPS, the verification framework checks whether all set elements specified in the sets of ECPP are consistent with the operations defined in the IPS.

For example, an online banking service specifies an IPS as:

LoginCheckBalanceWithdrawLogoutIf the IN set of the ECPP is specified as:

IN: {CheckBalance, Deposit}

Then the ECPP and IPS is not consistent because there is no Deposit operation specified in this IPS. Dynamic Analyses

Dynamic runtime simulation with policy enforcement can also be applied in this stage to evaluate the runtime behaviors and optimize the collaboration performance. Other issues for simulation include simulation monitoring, simulation profiling, and simulation visualization. Dynamic Distributed Service-Oriented Simulation (DDSOS) [12] is a tool that provides such environment. However, at this time, the actual collaboration partners and protocol are not known, thus simulation can be performed on selected sample partners and protocols in the database and the simulation results will be applicable to those samples only.

Policy enforcement is another V&V technique that can be used during simulation and/or actual deployment [13]. A policy is simply a rule that will be triggered if the associated condition occurs, and an action will be activated to stop the current execution or

to execute a compensation routine. Policy will be enforced at runtime, and policies can be local or global.

Simulation can be performed to ensure that the concerned service is ready for participate in a collaboration at runtime. Recall that at this time, as collaborating partners and protocols are not known at this time, only sample simulation can be performed.

.Figure 2: Simulation with Unknown Partners

Another approach of dynamic analysis is to perform distributed testing with agents. Multi-Agent-Based Service Testing (MAST) [1]. MAST can be used to:

Test individual component services; Test composite services in the simulation

environment; and Monitor service at runtime.

Figure 3: The Combined Dynamic Simulation and Policy Enforcement within MAST Framework

The MAST framework can be performed with simulation and policy enforcement as shown in Figure 3. For example: an online banking service uses a combined customer’s credit report from the credit bureau and its own customer account information to decide whether to approve loan. The banking service has a local policy specification which requires the customer must has at least one checking account in the bank and must login before apply loan, which can be formally described using LTL as:

(Login R ApplyLoan)

Similarly the credit bureau has its local policy that the credit check request must come from a registered financial institution while rejecting personal credit check. This policy can be formally described as:

G F

With F = {Request.Sender SETRegistered Financial Institution}; After the dynamic collaboration established, the policy engine can draw local policy specifications from both parties and form global policy specifications, an

example dynamic generated global policy specification is: the user must firstly execute Login on the online banking service before the credit bureau service can execute a “CreditCheck” request, which can be formally described in LTL as: (OnlineBanking.Login R CreditBureau.CreditCheck))

Policy engine then will enforce both local and global policies during the dynamic service collaboration process, should a “CreditCheck” occur from an offline user, the system will raise the policy violation exception.

3.2. Establishment Stage VerificationIn establishment stage, the collaboration partner is

decided and ECPA has been negotiated. Thus the service can have a complete view of the collaboration partners and the overall collaboration. The following table shows the specification completeness in collaboration establishment stage.

Table 5: Specification Completeness Spec Completeness

ECPP Complete viewECPA Complete view with global ECPAUSS Complete viewIPS Complete view with global IPSCIS Complete view

During this stage, dynamic USS compatibility analysis, policy analysis in simulation and collaboration model checking can be performed based on the ECPA and service USS.

A USS compatibility analysis ensures that the services included in collaboration can work together as expected before the actual collaboration. For example, when a credit monitoring service collaborates with an online banking service, one of the USS for the credit monitoring service is:

Hold U GetMsg (ACC_INFO) N SendMsg (CreditOK)

and there is a USS for the online banking service which can be specified as below:

SendMsg(ACC_INFO) N Hold U GetMsg(CreditOK)

For the specifications above: The parameters for the collaboration interfaces

match with each other. The matching including the match of parameter number and parameter type.

The outgoing message ID “ACC_INFO” of online banking service matches the incoming message ID of the customer credit check service collaboration interface;

The incoming message ID “CreditOK” of online banking service matches the outgoing message ID of the customer credit check collaboration interface:For the Collaboration Point set (CP Set), we have:

{CreditRequest} OUTOnlineBanking {CreditCheck} INCC

and {CreditOK} OUTCC {CheckOut} INOnlineBanking

We can derive the Collaboration Transactions set is:

CT = {{OnlineBanking.CreditRequest, CC.CreditCheck}, {CC.CreditOK, OnlineBanking.CheckOut}) ≠ ø

Collaboration model checking can be done at this stage to check the validity of the established service collaboration sequence and workflow. Note that at this stage, an ECPA is established from the ECPPs of participating services. Model checking can be used to verify the behavior of ECPA.

Dynamic simulation and policy enforcement can also be performed at this stage. The techniques for these will be the same as described in Section 3.1. However, the major difference is that at this stage, simulation and policy enforcement will be respect to specific participating services because at this time both the participating parties and collaboration protocols are known. This is shown in the figure below:

Figure 4: Simulation with Known Partners

3.3. Execution Stage VerificationAt this stage, we can perform dynamic verification

only. Besides dynamic simulation, policy enforcement, run-time monitoring and testing may be the primary means in this stage. The major difference with the previous stage is that the system is running while in the previous stage the system is simulated.

Run-time monitoring at this stage ensures that the collaboration is executed under control and behave in the way specified in the ECPA. The monitoring service also listens to the outputs of the collaboration, collects the data, and reports to the backend service center for further analysis. In this manner, it is more like an auditing service.

3.4. Termination Stage VerificationAt this stage, the collaboration is terminated and the

test agents in MAST have collected the data from the collaboration session through the auditing services. The data can be processed to suggest improvement for future collaboration.

Figure 5: Verification in Collaboration Termination

As shown in Figure 5, analyses such as policy enforcement, dynamic testing, and re-profiling based on the data collected can be performed in this stage.

For example, in the collaboration termination stage, the collaboration between online banking service and credit monitoring service for the online auto loan application may analyze the data collected during the collaboration execution. The data shows that:

TimeIdle > TimeOutwhich is a violation of the online banking policy. In this case, the online auto loan application needs to be invalidated. Based on the results, re-profiling will be done after the data analyses. The static service profile

and its compatibility information with collaboration partners will be updated. For example: if the credit checking operation of online banking service always timeout, the timeout value of the operation may have been set too low. This is an iterative process.

3.5. Integrated DCP Architecture with Verification

Figure 6 shows an integrated DCP architecture with dynamic verification. Each service is specified in process specification, interface specification, and collaboration specification. Before each service can be registered to the repository, it will be verified and validated by multiple static analyses. The collaboration protocol profiles will be registered in the registry and stored in the repository for discovery and matching. Once the collaboration is established, dynamic analyses can be performed to verify the runtime behaviors of the service collaboration.

Service B

Collaboration Specification

Service A

Collaboration Specification

Dynamic Analysis

Static Analysis

Reconfiguration

Process Specification

ECPA

Repository

ECPP-A

Collaboration Protocol Registry

Completeness & Consistency

Simulation

ECPP-Y

ECPP-Z

ECPP-B

Model CheckingPatterns

Registration, Discovery &

Matching

Interface Specification

ECPPUse

ScenarioRecomposition

Policy Enforcement

RTV&V

Profiling

Monitoring

Constraint Specification

Process Specification

Interface Specification

ECPPUse

ScenarioConstraint Specification

ECPP-X

Figure 6: Dynamic Collaboration Architecture

4. Case Study

This section uses an example to illustrate the DCP verification framework. The goal of the attacking side is to have one of them to reach the destination, which is guarded by a robot car of the defending side. One of the attacking robot cars acts as a Bait, i.e., it will attempt to distract the attention of the guarding robot so that the Runner can reach the destination, as shown in Figure 7. The Runner needs to collaborate with the Bait to accomplish the mission.

Figure 7: Mission Description

4.1. Verification during Profiling Stage

4.1.1. Service Specification for BaitThe collaboration specification of the Bait is

defined as:ActionSet = {Locate, Approach, Engage,

Distract,Disengage}where:

START = {Locate}END: {Disengage}IN: {Locate, Disengage}OUT: {Locate, Approach, Engage, Distract}

and the use scenario is:( Engage U Distract) (Distract N Disengage)

which means that each Distract must be preceded by an Engage, and each Distract must be followed by a Disengage.

The process specification for the Bait is shown in Figure 8. The Bait will first locate enemy guard and approach it. After it engages the distraction process, it will lead the enemy guard to leave its original position and wait for disengage message.

Figure 8: PSML-S Process Specification for Bait

4.1.2. Service Specification for RunnerThe collaboration specification of the Runner is

specified as following:ActionSet = {Prepare, Run, Confirm, Retry}

where: START: {Prepare}END: {Confirm}IN: {Prepare, Run}OUT: {Prepare, Confirm}

and the use scenario is:( Prepare U Run) (Prepare N Run)

which means that each Run must be preceded by a Prepare and each Prepare must be followed by a Run.

The process specification for the Runner is shown in Figure 9. The Runner begins with preparing for the running. After it gets the message to run, it runs across enemy line and then confirms the mission accomplishment.

Figure 9: PSML-S Process Specification for Runner

4.1.3. Service VerificationBased on the specifications above, we can first

perform the static process consistency analysis to verify whether the process specifications are correct. This is done by verifying the process specification against the use scenario specification. For the Bait, we can identify that the calling sequence of

{Locate, Approach, Engage, Distract, Disengage}is a valid calling sequence while

{Locate, Approach, Engage, Distract}is not valid since the Distract is not followed by a Disengage which violate the use scenario specification.

Similarly we can verify that the calling sequence of{Prepare, Run, Confirm, Retry} is also valid.

4.2. Verification during Establishment StageAt this stage we can use simulation to check if the

Runner is triggered to run immediately after the Bait distracted the Guard. The actual collaboration is carried out in the process shown in Figure 10.

Figure 10: Final Verified Collaboration

A video of the experiment is available at http://asusrl.eas.asu.edu/EmbeddedExplorer/video/demo4min.wmv.

4.3. Verification during Execution StageIn this stage, the MAST and policy enforcement can

be used to verify that the services actually follow the ECPA established earlier. The behaviors of both Bait and Runner will be monitored and recorded by the agents in MAST. Policies will be enforced so that the Runner will not run until it gets the DISTRACTED message from the Bait.

4.4. Verification during Termination StageIn this example, it is discovered in the experiment

that the Distract operation takes longer time than expected, which leads to mission failure if the Runner is triggered to run after the Bait finishes the Distract operation. Thus the collaboration plan is revised to follow the following collaboration sequence:

{Bait.Locate, Bait.Approach, Bait.Engage, Runner.Run, Bait.Distract, Runner.Confirm, Bait.Disengage}

5. ConclusionThis paper presented a framework for verifying

DCP in a SOA environment. The DCP represents the most challenging situation for verification because the parties that involved and the actual collaboration

protocols are determined at runtime, thus most verification must be performed at runtime. While many traditional verification techniques such as C&C checking, model checking, simulation, and testing can be used, but the ways they are applied are different. The proposed verification framework performs significant verification at the preparation/profiling so that only limited verification needs to be performed at the establishment stage. Furthermore, at the termination stage, ECPP is updated based on the data collected during the execution stage so that future collaboration can be improved. This framework provides comprehensive verification architecture for the DCP in a SOA environment. .6. References[1] Xiaoying Bai, Guilan Dai, Dezheng Xu, W. T. Tsai, A

Multi-Agent Based Framework for Collaborative Testing on Web Services. IEEE International Workshop on Collaborative Computing, Integration, and Assurance (WCCIA), April 2006, pp. 205-210.

[2] X. Fu, T. Bultan, and J. Su, “Formal Verification of E-Services and Workflows,” Proc. Workshop on Web Services, E-Business, and the Semantic Web (WES), LNCS 2512, Springer-Verlag, 2002, pp. 188–202.

[3] DARPA: OWL-S: http://www.daml.org/services/owl-s/

[4] Intel: Service-Oriented Enterprise, The Technology Path to Business Transformation. http://www.intel.com/ business/bss/technologies/soe/soe_backgrounder.pdf

[5] Nickolas Kavantzas, David Burdett, Tony Fletcher, Yves Lafon, “Web Services Choreography Description Language (WS-CDL)”, Version 1.0, W3C Working Draft 17 Dec. 2004. http://www.w3.org/TR/ws-cdl-10/

[6] Frank Leymann, Web Services Flow Language, Version 1.0, May 2001. http://www-306.ibm.com/software/ solutions/webservices/pdf/WSFL.pdf

[7] OASIS: ebXML: http://www.ebxml.org/

[8] OASIS: Business Process Execution Language for Web Services (BPEL4WS), 2003. http://xml.coverpages.org/ bpel4ws.html

[9] R. Paul, “DoD Towards Software Services”, Tenth IEEE International Workshop on Object-oriented Real-time Dependable Systems (WORDS 05), February 2005, pp. 3-6.

[10] M. P. Singh, M. N. Huhns, Service-Oriented Computing, John Wiley & Sons, 2005.

[11] W. T. Tsai, R. Paul, H. Huang, B. Xiao, and Y. Chen, “Semantic Interoperability and Its Verification and Validation in C2 Systems”, 10th International Command and Control Research and Technology Symposium (ICCRTS), 2005.

[12] W.T. Tsai, C. Fan, Y. Chen, R. Paul, DDSOS: A Dynamic Distributed Service-Oriented Simulation Framework, in Proceedings of 39th Annual Simulation Symposium (ANSS), Huntsville, AL,

April 2006, pp. 160-167.

[13] W. T. Tsai, X. Liu, Y. Chen and R. Paul, “Simulation Verification and Validation by Dynamic Policy Enforcement”, Proc. of Annual Simulation Symposium, 2005, pp. 91-98.

[14] O. Zimmermann, Sven Milinski, M. Craes, F. Oellermann, "Second Generation Web Services-Oriented Architecture in Production in the Finance Industry", OOPSLA’04, Oct. Vancouver, 2004