Your SlideShare is downloading. ×

DCP Final Version.doc

172

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
172
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Verification Framework for Dynamic Collaborative Services in Service- Oriented Architecture W. T. Tsai, Qian Huang, Bingnan Xiao, and Yinong Chen Arizona State University, Tempe, AZ 85287-8809, USA {wtsai, qhuang, bnxiao, yinong}@asu.edu Abstract the verification process in the dynamic collaboration framework using an example. Section 5 concludes the This paper introduces a dynamic verification paper and discusses future work. framework for collaborative services in Service- Oriented Architecture (SOA). Collaboration plays a 2. Dynamic Service Collaboration critical role in SOA, an effective verification framework for collaboration will greatly reduce the 2.1.Evolution of Process Collaboration effort for rapid and adaptive service composition and Process collaboration requires more than data evaluation of applications based on collaborative collaborations. It requires not only interoperability, but services. The verification framework provides a also collaboration among participating parties to service-oriented infrastructure for completeness and achieve the designated mission. consistency analyses, model-checking, simulation, and Procedural Paradigm: Collaboration is often policy enforcement of process specification based on achieved statically via procedure calls, and most collaborative services in SOA. The paper presents the procedure calls must be explicitly specified in the code. concepts, architecture, profiling techniques and Object-Oriented paradigm: data and its illustrative examples that demonstrate the concepts processing are bound together. Collaboration can be and the techniques. achieved through message passing. Furthermore, polymorphism and dynamic binding allow actual methods called to be determined at runtime. However, 1. Introduction the methods selected are still limited to the methods pre-implemented in the inheritance hierarchy. Service-Oriented Architecture (SOA) is a new SOA paradigm: data may not be bound with its paradigm for software development 66. Service processing any more, services are discovered and collaboration is essential in SOA because a complex composed dynamically. However, services collaborate service is always composed of several constituent with each other according a pre-specified workflow services. Recently, ebXML has introduced a set of even though the workflow can be updated. Thus, the dynamic collaboration protocols (DCP) such as CPP collaboration parties may be determined at runtime, but (Collaboration Protocol Profile) and CPA collaboration protocols are often fixed. (Collaboration Protocol Agreement), the key concept DCP in SOA: This is still in the SOA paradigm, but of DCP is that services will determine their with DCP both collaboration parties and collaboration collaboration at runtime. This new dynamism also protocols are determined at runtime. This approach is introduces new challenges in verification and implemented by OASIS CPP/CPA 6 and PSML-C. validation (V&V) of SOA applications. This approach is more agile than the conventional This paper introduces a dynamic collaboration SOA. A typical DCP process can be divided into four verification framework for dynamic process stages: collaboration in SOA. The framework provides support •Preparation/Profiling stage: In this stage, each for static and dynamic analyses including consistency service that wishes to participate in DCP must prepare analysis, use scenario compatibility analysis, model a CPP which contains the list of protocols that the checking, simulation, dynamic testing, and policy service can understand. The CPP can be updated as enforcement to evaluate large scale distributed service- the service learns from actual collaboration. oriented systems. •Establishment stage: In this stage, participating The rest of this paper is organized as follows. services will exchange their CPPs, and agree on a Section 2 outlines the dynamic collaboration common protocol CPA that all participating services framework. Section 3 presents the collaboration share. verification framework in detail. Section 4 illustrates
  • 2. •Execution stage: In this phase, participating services START = {Login} will collaborate based on the CPA established earlier. END = {Logout} Data may be collected so that CPP can be updated for IN = {ApproveLoan} OUT = {CreditCheck} future collaboration. •Termination stage: In this phase, participating 2.3.Extended Collaboration Protocol services terminate the collaboration, and update their Agreement (ECPA) own CPPs based on the data collected. The The ECPA extends the ebXML CPA by adding collaboration session may be evaluated so that future collaboration transactions set. When two processes collaboration can be improved. need to collaborate with each other, they need to ebXML has defined its CPP and CPA standards, negotiate with each other to specify possible/valid however the kinds of collaboration that can be collaboration transactions. An ECPA adds a set CT implemented using ebXML’s CPP and CPA are (Collaboration Transactions) which specifies a limited. We have proposed an extended set of CPP and collection of collaboration transactions. A CPA to allow more flexible collaboration. The collaboration transaction is a pair of (out, in) where in extension is shown below and in Table 1: ∈ IN1 and out ∈ OUT2 and IN1 is the IN set and OUT2 • ECPP (Extended Collaboration Protocol Profile) is the OUT set of participating collaboration services • ECPA (Extended Collaboration Protocol respectively. For two services to collaborate, the set Agreement) CT must be a non-empty set. • USS (Use Scenario Specification) An example of the CT set for an ECPA • IPS (Internal Process Specification) specification between an online banking service and a • CIS (Collaboration Interface Specification) credit service is: Table 1: Service collaboration specifications CT = {(CreditCheck, ProcessCreditChecking), Spec Information (CreditOK, ApproveLoan)} ECPP Describes service collaboration capabilities. 2.4.Use Scenario Specification (USS) ECPA Describes the collaboration interactions Use scenario is a specification on how the service among the collaborative services. can be used by other services 6. To be more specific, a USS Describes how to carry out a specific use scenario indicates the temporal logic and/or timing collaboration with respect to a given ECPP. constraints on a sequence of function calls. It provides IPS Specifies service internal control logic. a usage pattern on how to invoke the interfaces for the CIS Defines service collaboration interfaces. service. The USS uses a variety of specification language CIS including the Linear Temporal Logic (LTL) to specify the usage pattern of the service with respect to a IPS ECPP USS specific collaboration. As a result, a use scenario specification is built up from a set of proposition Service ECPA variables p1, p2,..., the usual logic connectives ¬, ∧, ∨, and →, and the temporal modal operators N (for next), Figure 1: Dynamic collaboration protocol G (for always), F (for eventually), U (for until), and R Figure 1 shows the dynamic collaboration protocol (for release). for process collaboration. An example of a use scenario specification for online banking service is: 2.2.Extended Collaboration Protocol Profile Login ∧ F Logout (ECPP) which means any login operation must finally An ECPP is a quadruple of (START, END, IN, followed by a logout operation. OUT), where: 2.5.Internal Process Specification (IPS) • START is the set of start points where START ≠ This is an internal process specification which ø or CardinalitySTART ≥ 1. specifies what the internal control logic for a specific • END is the set of end points where END ≠ ø or service. With the internal process specification CardinalityEND ≥ 1. information, service matching technologies can verify • IN is the set of incoming collaboration points. both the interface information as well as the internal • OUT is the set of outgoing collaboration points. process specification. An example of internal process An example of an ECPP specification for a simple specification of a simple online banking service is the online banking service is: auto loan application process specification that requires
  • 3. the collaboration with credit monitoring service for • Traditionally, systems and software are verified credit checking. using the IV&V (Independent Verification and Validation) approach, where independent teams 2.6.Collaboration Interface Specification (CIS) are used to verify and validate the system during This is a specification listing all interfaces of a system development. service for collaborations. Interfaces have two types: • The SOA challenges the IV&V approach as new in type interfaces take incoming events and out type services will be discovered after deployment, and interfaces issue out going events. Interfaces will be thus it is necessary to have CV&V (Collaborative mapped to the collaboration points defined in the Verification and Validation) approach 6 where ECPP in a specific collaboration. service brokers, providers and consumers work in An example of interfaces specification of a simple a collaborative manner, and some of testing need online banking service is: out SendMsg(MESSAGE) to be performed at runtime, e.g., when a new in GetMsg(MESSAGE) service is discovered and being incorporated into where the SendMsg interface is an out type the application. interface that can be used to request credit information • The DCP is even more challenging than the and the GetMsg interface is an in type interface that conventional SOA because even the collaboration can be used to get credit information from credit will be determined at runtime. While it is possible monitoring services. to re-specify the workflow at runtime during the dynamic reconfiguration in conventional SOA, it 3. Verification Framework for DCP is different in DCP, where the actual collaboration is unknown until the participating services The DCP provides a challenging environment for dynamically establish the protocol. verification. One can see the evolution of challenges Table 2 summarizes the comparison of traditional for verification as follows: 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&V Application Statically constructed based Workflow is specified but services Dynamic application composition via Model on specification. can be dynamically discovered. run-time service collaboration Operational Off-line field testing or On-line just-in-time testing in the On-line just-in-time testing in the testing simulation. application environment. collaboration environment Regression Off-line regression testing. On-line regression testing using data Historical collaboration data can be re- testing dynamically collected. played for regression testing. The verification team is Verification by collaboration among Before the establishment of independent of the service providers, application collaboration protocol at runtime, a development team to ensure builders, and independent service service has a partial view only, and Verification objectivity and to avoid brokers. The emphases are on thus verification will be limited. As the Approach common-mode errors. runtime and just-in-time testing, and complete collaboration will be Mostly done by software evaluation using data dynamically available at runtime, verification need providers. collected. to be performed at runtime. Input domain, structural Service providers can have As each service will have a partial Testing (white-box), or functional traditional coverage, and service view only, test coverage can be coverage (black-box) coverage. brokers and clients may have black- completed only when the actual box (such as WSDL) coverage only. collaboration is established. Test case Static profiling Dynamic profiling with data Dynamic profiling and re-profiling at profiling collected by distributed agents. collaboration runtime Specification and models are Just-in-time on-the-fly simulation Simulation before deployment, on-the- Simulation simulated to verify the design for composite service fly simulation when protocol and and/or code parties are known at runtime. Static configurations and Dynamic configuration and systems Dynamic configuration and Integration systems must be linked are linked at runtime and verified at collaboration are established at runtime testing before integration testing runtime and verified at runtime Model checking on the code Just-in-time dynamic model Model checking can be performed on Model or state model. checking on the specification in, the partial view, and again when the Checking e.g., WSDL and OWLS. complete view is available.
  • 4. The DCP process is divided into four stages, each defined in the PSML-C model, it must be used in one stage has its own verification requirements and of the IPS. Otherwise, the Deposit operation can not be constraints. The following table shows the verification included in any IPS. techniques that are applicable to each stage. •Consistency Checking by Model Checking Table 3: Verification in Each DCP Stage In the collaboration preparation / profiling stage, Stage Static Dynamic model checking ensures the collaboration capabilities Process Simulation / Policy specified in the ECPP is consistent with the internal Prepare/ Consistency / Enforcement / Test process and the internal process specification satisfies Profiling Model Checking Agent the constraints specified in use scenario. If USS compatibility inconsistency exists, the ECPA established at runtime Establishment N/A check / Simulation / Test Agent may not guarantee the collaboration can be carried out Policy Enforcement or the collaboration will be inefficient. As shown in Execution N/A / Monitoring / Test Figure 1, there are ECPP, USS, and IPS for a given Agent service in this stage that need to be verified. Service Policy Specification verification needs to be performed by: Termination Update Profiling / Test Agent •Consistency model checking on USS and IPS •Consistency model checking on ECPP and IPS 3.1.Preparation / Profiling Stage Verification To perform the consistency model checking on USS In this stage, the collaboration partner information and IPS, model checking can be used to check whether is unknown to the service. Thus, services have only has the IPS follows the constraint specified in USS. a partial view of the overall collaboration. Since the Specifically, an IPS will be verified against the LTL service specification is not available for the formula specified in the USS. collaboration partner, the verification can only be For example, an online banking service specifies an performed based on the sample CPA that is stored in LTL formula as followed: (Login ∧ F Logout) ∧ (Login R ¬ Withdraw) the service profile. The service profile can be later and the following IPS: updated in the collaboration termination stage based on Login⋅CheckBalance⋅Withdraw⋅Logout the data collected in the collaboration execution stage. is a valid IPS, but Table 4 shows the specification completeness in Login⋅CheckBalance⋅Withdraw collaboration preparation / profiling stage. Table 4: Specification Completeness and CheckBalance⋅Withdraw⋅Logout Spec Completeness are both invalid IPS. ECPP Partial view with local ECPP only To perform the consistency model checking on ECPA Has previous sample ECPA ECPP and IPS, the verification framework checks USS Partial view with local USS only whether all set elements specified in the sets of ECPP IPS Partial view with local IPS only are consistent with the operations defined in the IPS. CIS Partial view with local CIS only For example, an online banking service specifies an Static Analyses IPS as: •Completeness & Consistency (C&C) Checking Login⋅CheckBalance⋅Withdraw⋅Logout Various C&C can be performed on specifications to If the IN set of the ECPP is specified as: ensure that they are consistent and complete with each IN: {CheckBalance, Deposit} other based on following criteria: Then the ECPP and IPS is not consistent because ∀element (element ∈SETDefinition → element ∈ SETIPS) there is no Deposit operation specified in this IPS. and Dynamic Analyses ¬∃element (element ∈SETIPS ∧ element ∉ SETDefinition) Dynamic runtime simulation with policy denoting that for each element defined in the model, enforcement can also be applied in this stage to it must be used in the IPS; and for each element used in evaluate the runtime behaviors and optimize the the IPS, it must be defined in the model. collaboration performance. Other issues for simulation For examples, an online banking service specifies include simulation monitoring, simulation profiling, the following IPS: and simulation visualization. Dynamic Distributed Login⋅CheckBalance⋅Withdraw⋅Logout Service-Oriented Simulation (DDSOS) 6 is a tool that Then all operations specified in the IPS including provides such environment. However, at this time, the Login, CheckBalance, Withdraw, and Logout must be actual collaboration partners and protocol are not defined in the PSML-C model for the online banking known, thus simulation can be performed on selected service. On the other hand, if the Deposit operation is sample partners and protocols in the database and the
  • 5. simulation results will be applicable to those samples ? ? ? only. Policy enforcement is another V&V technique that CIS can be used during simulation and/or actual ECPP USS deployment 6. A policy is simply a rule that will be IPS ECPA triggered if the associated condition occurs, and an Service action will be activated to stop the current execution or . to execute a compensation routine. Policy will be Figure 2: Simulation with Unknown Partners enforced at runtime, and policies can be local or global. Another approach of dynamic analysis is to perform Simulation can be performed to ensure that the distributed testing with agents. Multi-Agent-Based concerned service is ready for participate in a Service Testing (MAST) 6. MAST can be used to: collaboration at runtime. Recall that at this time, as •Test individual component services; collaborating partners and protocols are not known at •Test composite services in the simulation this time, only sample simulation can be performed. environment; and •Monitor service at runtime. Service Policy Spec . Provider MAST Service Deployment Test Plan Policy Runtime Policy Engine Test Plan Environment Database Runtime Test Plan Environment Dynamic Runtime USS/ Simulation Environment IPS/ Test ECPP Runner Collaboration Test Test Script Test Script Master Generator Database Test USS/ Coordinator IPS/ ECPP Test Monitor Test Service Analyser Service Evaluation Provider Figure 3: The Combined Dynamic Simulation and Policy Enforcement within MAST Framework The MAST framework can be performed with Policy engine then will enforce both local and simulation and policy enforcement as shown in Figure global policies during the dynamic service 3. For example: an online banking service uses a collaboration process, should a “CreditCheck” occur combined customer’s credit report from the credit from an offline user, the system will raise the policy bureau and its own customer account information to violation exception. decide whether to approve loan. The banking service has a local policy specification which requires the 3.2.Establishment Stage Verification customer must has at least one checking account in the In establishment stage, the collaboration partner is bank and must login before apply loan, which can be decided and ECPA has been negotiated. Thus the formally described using LTL as: service can have a complete view of the collaboration partners and the overall collaboration. The following (Login R ¬ ApplyLoan) table shows the specification completeness in Similarly the credit bureau has its local policy that collaboration establishment stage. the credit check request must come from a registered Table 5: Specification Completeness financial institution while rejecting personal credit Spec Completeness check. This policy can be formally described as: ECPP Complete view GF ECPA Complete view with global ECPA With F = {Request.Sender ∈ SETRegistered Financial Institution}; USS Complete view After the dynamic collaboration established, the policy IPS Complete view with global IPS engine can draw local policy specifications from both CIS Complete view parties and form global policy specifications, an During this stage, dynamic USS compatibility example dynamic generated global policy specification analysis, policy analysis in simulation and is: the user must firstly execute Login on the online collaboration model checking can be performed based banking service before the credit bureau service can on the ECPA and service USS. execute a “CreditCheck” request, which can be A USS compatibility analysis ensures that the formally described in LTL as: services included in collaboration can work together as (OnlineBanking.Login R ¬CreditBureau.CreditCheck)) expected before the actual collaboration. For example, when a credit monitoring service collaborates with an
  • 6. online banking service, one of the USS for the credit previous stage is that the system is running while in the monitoring service is: previous stage the system is simulated. Hold U GetMsg (ACC_INFO) ∧ N SendMsg (CreditOK) Run-time monitoring at this stage ensures that the collaboration is executed under control and behave in and there is a USS for the online banking service the way specified in the ECPA. The monitoring service which can be specified as below: also listens to the outputs of the collaboration, collects SendMsg(ACC_INFO) ∧ N Hold U GetMsg(CreditOK) the data, and reports to the backend service center for For the specifications above: further analysis. In this manner, it is more like an • The parameters for the collaboration interfaces auditing service. match with each other. The matching including the 3.4.Termination Stage Verification match of parameter number and parameter type. At this stage, the collaboration is terminated and the • The outgoing message ID “ACC_INFO” of online test agents in MAST have collected the data from the banking service matches the incoming message ID collaboration session through the auditing services. of the customer credit check service collaboration The data can be processed to suggest improvement for interface; future collaboration. • The incoming message ID “CreditOK” of online Model Refinement banking service matches the outgoing message ID Service 1 E C P US S Service n E C P US S Verification & N ... IPS of the customer credit check collaboration Validation IPS P P ECP A ECP A CIS CIS (C&C Analysis / Passed? interface: CIS Model Checking / Simulation) Y For the Collaboration Point set (CP Set), we have: ECPP USS IPS Deployed ECPA {CreditRequest} ⊆ OUTOnlineBanking ∧ {CreditCheck} ⊆ INCC Service Application and {CreditOK} ⊆ OUTCC ∧ {CheckOut} ⊆ INOnlineBanking MAST Testing w/ Feedback We can derive the Collaboration Transactions set is: Sample Profile Policy Enforcement Repository CT = {{OnlineBanking.CreditRequest, CC.CreditCheck}, Profile {CC.CreditOK, OnlineBanking.CheckOut}) ≠ ø Profile Repository Re-Profiling Data Collection Collaboration model checking can be done at this Figure 5: Verification in Collaboration Termination stage to check the validity of the established service As shown in Figure 5, analyses such as policy collaboration sequence and workflow. Note that at this enforcement, dynamic testing, and re-profiling based stage, an ECPA is established from the ECPPs of on the data collected can be performed in this stage. participating services. Model checking can be used to For example, in the collaboration termination stage, verify the behavior of ECPA. the collaboration between online banking service and Dynamic simulation and policy enforcement can credit monitoring service for the online auto loan also be performed at this stage. The techniques for application may analyze the data collected during the these will be the same as described in Section 3.1. collaboration execution. The data shows that: However, the major difference is that at this stage, TimeIdle > TimeOut simulation and policy enforcement will be respect to which is a violation of the online banking policy. In specific participating services because at this time both this case, the online auto loan application needs to be the participating parties and collaboration protocols are invalidated. Based on the results, re-profiling will be known. This is shown in the figure below: done after the data analyses. The static service profile Service 1 Service n ECPP USS ECPP USS and its compatibility information with collaboration ... IPS IPS ECPA ECPA CIS CIS partners will be updated. For example: if the credit checking operation of online banking service always CIS timeout, the timeout value of the operation may have ECPP USS been set too low. This is an iterative process. IPS ECPA Service 3.5.Integrated DCP Architecture with Verification Figure 4: Simulation with Known Partners Figure 6 shows an integrated DCP architecture with dynamic verification. Each service is specified in 3.3.Execution Stage Verification process specification, interface specification, and At this stage, we can perform dynamic verification collaboration specification. Before each service can be only. Besides dynamic simulation, policy enforcement, registered to the repository, it will be verified and run-time monitoring and testing may be the primary validated by multiple static analyses. The collaboration means in this stage. The major difference with the protocol profiles will be registered in the registry and
  • 7. stored in the repository for discovery and matching. which means that each Distract must be preceded by Once the collaboration is established, dynamic an Engage, and each Distract must be followed by a analyses can be performed to verify the runtime Disengage. behaviors of the service collaboration. The process specification for the Bait is shown in Static Analysis Completeness & Figure 8. The Bait will first locate enemy guard and Patterns Consistency Model Checking Simulation approach it. After it engages the distraction process, it will lead the enemy guard to leave its original position Dynamic Analysis Service A Process Collaboration Specification Registration, Discovery & and wait for disengage message. Specification Matching Recomposition Use Bait Constraint ECPP Locate Distract Scenario Specification do ACTION Locate Reconfiguration do ACTION Approach Interface Specification Collaboration Approach N Protocol Registry do ACTION Engage DISENGAGE? Monitoring do ACTION Distract ECPA while (! DISENGAGE) Hold Engage Y Profiling Repository do ACTION Disengage Disengage ECPP-A RTV&V Interface Specification Figure 8: PSML-S Process Specification for Bait ECPP-X Process Collaboration Specification Specification ECPP-Y Policy Enforcement Constraint Specification Use Scenario ECPP ECPP-Z 4.1.2.Service Specification for Runner Service B ECPP-B The collaboration specification of the Runner is Figure 6: Dynamic Collaboration Architecture specified as following: ActionSet = {Prepare, Run, Confirm, Retry} 4. Case Study where: START: {Prepare} END: {Confirm} This section uses an example to illustrate the DCP IN: {Prepare, Run} verification framework. The goal of the attacking side OUT: {Prepare, Confirm} is to have one of them to reach the destination, which and the use scenario is: is guarded by a robot car of the defending side. One of ¬(¬ Prepare U Run) ∧ (Prepare ∧ N Run) the attacking robot cars acts as a Bait, i.e., it will which means that each Run must be preceded by a attempt to distract the attention of the guarding robot Prepare and each Prepare must be followed by a Run. so that the Runner can reach the destination, as shown The process specification for the Runner is shown in Figure 7. The Runner needs to collaborate with the in Figure 9. The Runner begins with preparing for the Bait to accomplish the mission. running. After it gets the message to run, it runs across Bait enemy line and then confirms the mission Guard Guard accomplishment. Runner Runner Prepare 2 do ACTION Prepare Run while (! DISTRACTED) Hold N 3 do ACTION Run DISTRACTED? 1 4 do ACTION Confirm Y Confirm Figure 9: PSML-S Process Specification for Runner Bait Collaboration Runner 4.1.3.Service Verification Control Center Based on the specifications above, we can first Figure 7: Mission Description perform the static process consistency analysis to verify whether the process specifications are correct. 4.1.Verification during Profiling Stage This is done by verifying the process specification 4.1.1.Service Specification for Bait against the use scenario specification. For the Bait, we The collaboration specification of the Bait is can identify that the calling sequence of {Locate, Approach, Engage, Distract, Disengage} defined as: ActionSet = {Locate, Approach, Engage, is a valid calling sequence while Distract,Disengage} {Locate, Approach, Engage, Distract} where: is not valid since the Distract is not followed by a START = {Locate} Disengage which violate the use scenario specification. END: {Disengage} Similarly we can verify that the calling sequence of IN: {Locate, Disengage} {Prepare, Run, Confirm, Retry} is also valid. OUT: {Locate, Approach, Engage, Distract} and the use scenario is: ¬(¬ Engage U Distract) ∧ (Distract ∧ N Disengage)
  • 8. 4.2.Verification during Establishment Stage 6. References At this stage we can use simulation to check if the [1] Xiaoying Bai, Guilan Dai, Dezheng Xu, W. T. Tsai, A Runner is triggered to run immediately after the Bait Multi-Agent Based Framework for Collaborative distracted the Guard. The actual collaboration is Testing on Web Services. IEEE International Workshop carried out in the process shown in Figure 10. on Collaborative Computing, Integration, and Assurance Locate Bait Runner Prepare (WCCIA), April 2006, pp. 205-210. Approach [2] X. Fu, T. Bultan, and J. Su, “Formal Verification of E- Engage Services and Workflows,” Proc. Workshop on Web 1 2 Services, E-Business, and the Semantic Web (WES), Distract DISTRACTED Run LNCS 2512, Springer-Verlag, 2002, pp. 188–202. Disengage 4 DISENGAGE 3 Confirm [3] DARPA: OWL-S: http://www.daml.org/services/owl-s/ Figure 10: Final Verified Collaboration [4] Intel: Service-Oriented Enterprise, The Technology Path to Business Transformation. http://www.intel.com/ A video of the experiment is available at business/bss/technologies/soe/soe_backgrounder.pdf http://asusrl.eas.asu.edu/EmbeddedExplorer/video/dem o4min.wmv. [5] Nickolas Kavantzas, David Burdett, Tony Fletcher, Yves Lafon, “Web Services Choreography Description 4.3.Verification during Execution Stage Language (WS-CDL)”, Version 1.0, W3C Working In this stage, the MAST and policy enforcement can Draft 17 Dec. 2004. http://www.w3.org/TR/ws-cdl-10/ be used to verify that the services actually follow the [6] Frank Leymann, Web Services Flow Language, Version ECPA established earlier. The behaviors of both Bait 1.0, May 2001. http://www-306.ibm.com/software/ and Runner will be monitored and recorded by the solutions/webservices/pdf/WSFL.pdf agents in MAST. Policies will be enforced so that the [7] OASIS: ebXML: http://www.ebxml.org/ Runner will not run until it gets the DISTRACTED [8] OASIS: Business Process Execution Language for Web message from the Bait. Services (BPEL4WS), 2003. http://xml.coverpages.org/ bpel4ws.html 4.4.Verification during Termination Stage In this example, it is discovered in the experiment [9] R. Paul, “DoD Towards Software Services”, Tenth that the Distract operation takes longer time than IEEE International Workshop on Object-oriented Real- expected, which leads to mission failure if the Runner time Dependable Systems (WORDS 05), February 2005, pp. 3-6. is triggered to run after the Bait finishes the Distract operation. Thus the collaboration plan is revised to [10] M. P. Singh, M. N. Huhns, Service-Oriented follow the following collaboration sequence: Computing, John Wiley & Sons, 2005. {Bait.Locate, Bait.Approach, Bait.Engage, Runner.Run, [11] W. T. Tsai, R. Paul, H. Huang, B. Xiao, and Y. Chen, Bait.Distract, Runner.Confirm, Bait.Disengage} “Semantic Interoperability and Its Verification and Validation in C2 Systems”, 10th International Command 5. Conclusion and Control Research and Technology Symposium This paper presented a framework for verifying (ICCRTS), 2005. DCP in a SOA environment. The DCP represents the [12] W.T. Tsai, C. Fan, Y. Chen, R. Paul, DDSOS: A most challenging situation for verification because the Dynamic Distributed Service-Oriented Simulation parties that involved and the actual collaboration Framework, in Proceedings of 39th Annual protocols are determined at runtime, thus most Simulation Symposium (ANSS), Huntsville, AL, verification must be performed at runtime. While many April 2006, pp. 160-167. traditional verification techniques such as C&C [13] W. T. Tsai, X. Liu, Y. Chen and R. Paul, “Simulation checking, model checking, simulation, and testing can Verification and Validation by Dynamic Policy be used, but the ways they are applied are different. Enforcement”, Proc. of Annual Simulation Symposium, The proposed verification framework performs 2005, pp. 91-98. significant verification at the preparation/profiling so [14] O. Zimmermann, Sven Milinski, M. Craes, F. that only limited verification needs to be performed at Oellermann, "Second Generation Web Services- the establishment stage. Furthermore, at the Oriented Architecture in Production in the Finance termination stage, ECPP is updated based on the data Industry", OOPSLA’04, Oct. Vancouver, 2004 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. .

×