4/5/10 1 Dynamic Collaboration Protocol in Service Oriented ...

05/06/10 1

Dynamic Collaboration Protocol in Service Oriented Architecture

W. T. TsaiComputer Science & Engineering Department

Arizona State UniversityTempe, AZ [email protected]

05/06/10 2

Agenda

Overview of Interoperability OASIS CPP/CPA Collaboration Use Scenarios Dynamic Collaboration Protocol (DCP) Verification Framework for DCP Case study Summary

05/06/10 3

Interoperability

Interoperability is defined as The ability of two or more systems or components

to exchange information and to use the information that has been exchanged.

Interoperability is a critical issue for service-oriented systems. But interoperability of what?

05/06/10 4

Kinds of Interoperability

Protocol interoperability Allow two parties (services, processes, clients, or systems)

to communicate with each other. For example, WSDL, SOAP, OWL-S, HTTP, UDDI, ebXML.

Protocol interoperability is the minimum requirements. Issues: QoS, performance, implementation

Data interoperability Allow two parties (services, processes, clients, or systems)

to exchange data. MetaData, XML (data schema) Issues: Security, integrity, data provenance

05/06/10 5

Kinds of Interoperability

Process Interaction: Allow two parties to communicate with each other while the processes are running. Static arrangement: Both processes and interactions are

specified (or fixed) before interaction. This is traditional SOA. For example, one of them is a workflow of an application, the

other is a service. Both can be services.

Dynamic arrangement While interaction protocols are established at runtime.

But the first is to allow data exchange. (OASIS CPP/CPA) Allow these processes to interact with the workflow.

(ECPP/ECPA) Issues: This is the current challenge.

05/06/10 6

Interoperability in SOA

Following the concept of SOA, each sub-system in the composed complex system Is a self-contained autonomous system; Provides services; Collaborates with each other; and Loosely couples with other systems.

To achieve interoperability, each system needs to be able to Exchange data and services in a consistent and effective way. Provide universal access capacities independent of platforms.

05/06/10 7

Interoperability in SOA (cont.)

For service-oriented systems, services Exchange data; and Collaborate with fellow services in terms of tasks and missions.

While the current interoperability technologies such as standard interface and ontology are critical for SOA interoperability, they are not sufficient because: The current interface technologies provide method signatures

only for a single service. These method signatures do not provide sufficient information for

another new system or user to properly use the service, e.g. What is the proper calling sequence among methods of this service What is the dependency among methods of a service or another

service.

05/06/10 8

Interoperability in SOA (cont.)

To achieve full function, we need to expand the interoperability because: Data exchange is a small part of interoperability only; Systems need to interact with each other at run-time; One system may use the services provided by others; and Systems may need to work with some legacy systems.

To make heterogeneous systems working with each other, we need to have a framework which provides support for Platform independent system service specification, System wrapping for legacy systems, and System composition and re-composition.

05/06/10 9

Issues in Interoperability

We need to design efficient, secure and scalable protocols at all levels.

Data provenance is a serious challenge in SOA because we have numerous data going through a SOA system, and we need to know the “history” of data. How reliable is it? How secure is it? What is the integrity level? How accurate is it?

Metadata: how do we design the metadata we needed? How do we evolve metadata?

Process Interaction: how do we specify the possible interaction? How can two services establish a dynamic interaction at runtime? How can the two services verify/evaluate/monitor/assess the dynamic interaction?

Do we need this kind of interoperability? What are the implication of these kinds of interoperability?

05/06/10 10

Agenda


05/06/10 11

OASIS CPP/CPA Collaboration

Collaboration is an association, partnership, or agreement between two legal entities to conduct business. [OASIS] A collaboration likely results in at least one business

process being implied between entities. Collaboration over the World Wide Web is a broad

area of research involving wide-reaching issues [W3C] : Knowledge representation; Annotation of objects; Notification; and Any other issues which arise in the creation of shared

information systems and collaborative development.

05/06/10 12

OASIS ebXML CPP/CPA specification http://www.ebxml.org/specs/ebcpp-2.0.pdf

Collaboration-Protocol Profile (CPP) describes the Message-exchange capabilities of a Party.

Collaboration-Protocol Agreement (CPA) describes the Message-exchange agreement between two Parties.

A CPA MAY be created by computing the intersection of the two Partners' CPPs.

Included in the CPP and CPA are details of transport, messaging, security constraints, and bindings to a Business-Process-Specification (or, for short, Process-Specification) document.

The objective of the OASIS ebXML CPP/CPA specification is to ensure interoperability between two Parties even though they MAY procure application software and run-time support software from different vendors.

Both Parties SHALL use identical copies of the CPA to configure their run-time systems. The configuration process MAY be automated by means of a suitable tool that reads the CPA and performs the configuration process.

http://www.ebxml.org/specs/ebcpp-2.0.pdf

05/06/10 13

Overview of Collaboration-Protocol Agreement (CPA)

Party A and Party B use their CPPs to jointly construct a single copy of a CPA by calculating the intersection of the information in their CPPs. The resulting CPA defines how the two Parties will behave in performing their Business Collaboration.

05/06/10 14

Working Architecture of CPP/CPA with ebXML Registry

05/06/10 15

Limitation of CPP/CPA

Focus on message exchange only. Thus, any issues related to workflow will not be addressed at all. Common issues related to workflow during collaboration is

Deadlock: Each party is waiting for the other party to reply. Starvation: The other party fails to respond, and the party waiting

for the data is starving. Synchronization: both parties need to synchronize with each

other. Transaction: all or nothing. Missing: A message sent originally and received. But the

message was discarded after a receiver rollback, and needs the message to be re-sent, but the sender never rolls back.

Orphan: A message has been sent, but the sending party rolls back, and this message becomes invalid, but it has been sent and received.

05/06/10 16

Limitation of CPP/CPAParty1 Party2

SendMessage(M1)

SendMessage(M2)

Wait(M3)

Wait(M4)

SendMessage(M4)

SendMessage(M3)

Deadlock Starving

Party1 Party2

SendMessage(M1)

Infinite Loop

Wait(M2)

05/06/10 17

OASIS CPP/CPA Example

http://www.oasis-open.org/committees/ebxml-cppa/schema/cpa-example-2_0b.xml

http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-cpa-2_0b.xsd

http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-example-companyA-2_0b.xml

http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-example-companyB-2_0b.xml

Example of CPA Document

Example of CPP Document

http://www.oasis-open.org/committees/ebxml-cppa/schema/cpa-example-2_0b.xml

http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-cpa-2_0b.xsd

http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-example-companyA-2_0b.xml

http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-example-companyB-2_0b.xml

05/06/10 18

Agenda

Overview of Interoperability Data Provenance OASIS CPP/CPA Collaboration Use Scenarios Dynamic Collaboration Protocol (DCP) Verification Framework for DCP Case study Summary

05/06/10 19

Use Scenarios

Use scenarios Is designed for service interoperability specification It specifies how a service or system is used by other

services or systems. It focuses on the work flow part of the service

interoperability. It defines how a particular function can be used in a

stepwise fashion. Use Scenario vs. Process Specification

A process specification describes the behavior of a system when the system is activated with a specific input.

A use scenario describes a possible sequence of actions to activate a service provided by the system.

05/06/10 20

Use Scenario Analyses

With the use scenario specified, we can perform Automated interoperation generation Interoperation correctness checking Interoperability cross checking

With the support of the analytic techniques mentioned above, users can verify the correctness of use scenario. This can further enhance the interoperability of

systems.

05/06/10 21

ACDATE / Process Overview

The ACDATE (Actors, Conditions, Data, Actions, aTtributes, Events) modeling specification A language for modeling and specification in the domain of

system engineering and software engineering. It facilitates the specification, analysis, simulation, and execution

of the requirement and therefore the system. A Process is a semi-formal description of system functionality

It is a sequence of events expected during operation of system products which includes the environment conditions and usage rates as well as expected stimuli (inputs) and response (outputs).

ACDATE entities are the building blocks for Process specification. After one’s system requirements have been decomposed into

ACDATE entities, one can then specify Processes. This ACDATE/Process model allows for system modeling and

provides the capability to perform various analyses of requirement V&V.

05/06/10 22

Use Scenario Specification -- syntax & semantics structural constructs:

choice{ option[] option[] … option[] }: choice means that the interoperation can select any single sub-process (listed

as options) to continue the control flow. {} precond:

precond indicates the preconditions before a particular action postcond {}:

postcond indicate the postconditions after a particular action criticalreg {}:

criticalreg indicate a critical region such that no other actions can take place to interrupt the execution of actions within the critical region. Any action sequence outside a critical region can be intervened by any sub-process.

<>: Any entities enclosed by <> are parameter entities.

With sub-processes, the use scenario can describe the interoperation of hierarchical systems in different levels.

05/06/10 23

Agenda


05/06/10 24

Process Collaboration

Process collaboration is a higher-level collaboration than data collaborations. It requires higher interoperability of collaborative partners. It is more efficient, more adaptive and more dynamic than data

collaboration. The development of process collaboration is shown as following:

Process Collaboration

Procedural Paradigm

Object-Oriented Paradigm

Service-Oriented Paradigm

Adaptive Service-Oriented Paradigm

Static

Explicit function call

Dynamic Binding

Dynamic Typing

Dynamic Discovery

Dynamic Composition

Dynamic Control

Adaptive Control

Message Passing

05/06/10 25

Dynamic Process Collaboration

Dynamic allows different services to interoperate with each other at system runtime in SOA

The Dynamic on-demand service-oriented collaboration architecture is a flexible architecture: Application architecture, collaboration protocols and

individual services can be dynamically selected and reconfigured to fit the new application environment.

Dynamic collaboration includes: A collaboration specification language based on PSML-S; A set of on-demand process collaboration protocols by

extending ebXML collaboration protocols; and A collaboration framework based on CCSOA framework.

05/06/10 26

Service Specification

To achieve interoperability through network, the services need to be modeled and annotated in a standard formal/semi-formal specification Different services can understand each other and

communicate with each other.

Service specification is a very important part for effective service collaboration and composition.

05/06/10 27

Service Specification Evolution

Initial stage (interface stage) Service descriptions mainly contain the input/output information, such as

function name, return type, and parameter types. Process description stage

Service specifications contain an abstract process description in addition to interface information.

Service collaboration specification stage The service specifications not only contain everything in the previous two

stages, but also service collaboration protocols such as collaboration protocol establishment, collaboration protocol profiles, collaboration constraints, and patterns. WS-CDL WSFL

Consumer-centric specification stage The entire application can be specified, published, searched, discovered,

and composed.

05/06/10 28

PSML-C Service Specification

PSML-C is designed to support the specification, modeling, analysis, and simulation of service process collaboration based on PSML-S.

The PSML-C specification includes: Process Specification; Constraint Specification; Interface Specification; and Collaboration Specification.

Service Specification

Process Specification

Interface Specification

Collaboration Specification

Extended Collaboration Protocol ProfileExtended Collaboration

Protocol ProfileExtended Collaboration

Protocol Profile

Predefined ECPA Set

Extended Collaboration Protocol AgreementExtended Collaboration

Protocol AgreementExtended Collaboration Protocol Agreement

Use ScenarioUse

ScenarioUse

Scenario

Constraint Specification

05/06/10 29

PSML-C Collaboration Specification

Collaboration specification consists of A set of extended CPP’s (ECPP); A set of use scenarios; and A set of predefined extended CPA’s (ECPA).

Each ECPP Describes one collaboration capability of the service Is associated with one use scenario that provides

information on how the other services can use the interfaces published for this specific collaboration capability.

Each ECPP references to a process specification as the internal control logic for this specific collaboration capability.

The ECPA set which contains predefined ECPA’s that have been used and evaluated in the previously carried out service collaboration for rapid collaboration establishment.

05/06/10 30

PSML-C Dynamic Process Collaboration Protocols

PSML-C Process Collaboration Protocol is derived from the ebXML CPP and CPA. ebXML CPP & CPA primarily focus on the message exchange

capabilities of collaborating services. They provide general information on collaboration in E-Business

domain. But they lack of information on process collaboration.

PSML-C, based on PSML-S, has a process oriented modeling language which provides rich information on process specification.

This approach extends the ebXML CPP and CPA by adding more process related information to the service collaboration specification. Extended CPP and CPA specify more information on process

collaboration and system workflow.

05/06/10 31

PSML-C Dynamic Process Collaboration Protocols (Cont.)

PSML-C Collaboration Protocol consists of: Extended Collaboration Protocol Profile (ECPP): Describes the

collaboration capabilities of the service. Extended Collaboration Protocol Agreement (ECPA): Describes the

collaboration interactions among the collaborative services. Use Scenario: Describes how to carry out a specific collaboration with

respect to a given ECPP. Process Specification Reference: References to the internal control logic

of each service Service A Process

SpecificationExtended Collaboration

Protocol Profile

Extended Collaboration Protocol Agreement

Use Scenario

Service A Process Specification

Extended Collaboration Protocol Profile

Use Scenario

05/06/10 32

Extended CPP (ECPP)

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

A collection of entry points to the process specification where the process begins to execute.

The START set is a non-null set. END is the set of end points where END ≠ ø.

A collection of exit points of the process specification where the process finishes executing.

The END set is a non-null set. IN is the set of incoming collaboration points.

A collection of collaboration points of the process specification that can take incoming events. The IN set specifies what Actions in the process specification can be triggered by incoming

Events from other services. An in collaboration point will be further mapped to an in type interface of the service in the

collaboration agreement. OUT is the set of outgoing collaboration points.

A collection of collaboration points of the process specification that can issue outgoing events. The OUT set specifies what Actions in the process specification can issue outgoing Events to

invoke other services. An out collaboration point will be further mapped to an out type interface of the service in the

collaboration agreement.

05/06/10 33

Extended CPP (Cont.)

Following constraints are highly recommended but not required to the ECPP specification to describe a well-formed collaboration model: CardSTART = 1 ∧ (CardIN > 0 ∨ CardOUT > 0)

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

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

05/06/10 34

Extended CPA (ECPA)

PSML-C adds collaboration transaction to the ebXML CPA. When two processes need to collaborate with each other,

they need to negotiate with each other to specify possible/valid collaboration transaction.

An ECPA contains a set CT 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 collaboration services respectively.

05/06/10 35

Extended CPA (Cont.)

For two services to be able to collaborate, the set CT must be a non-null set.

An example of an ECPA specification between a simple online banking service and a credit service is:

CT = {(CreditCheck, ProcessCreditChecking), (CreditOK, ApproveLoan)}where CreditCheck: an out collaboration point of online banking service;ApproveLoan: an in collaboration point of online banking service;ProcessCreditChecking: an in collaboration point of credit service; and

CreditOK: an out collaboration point of credit service.

05/06/10 36

LTL Use Scenario Specification

The Use Scenario specification also uses the Linear Temporal Logic (LTL) syntax and semantics 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 Logout

which means any login operation must finally followed by a logout operation.

05/06/10 37

Process Specification Reference

Process specification reference is a reference to the process specification which specifies the internal control logic associated with an ECPP. With this reference information, service matching

technologies can verify both the interface information as well as the internal process specification.

An example of process specification reference of a simple online banking service is that the credit checking collaboration references to the auto loan application process specification.

05/06/10 38

PSML-C Composition & Collaboration Framework

Service Broker

Service Pool

Application Template

Pattern Repository

Service ProviderService Agent

Service Placeholder A

Service Placeholder N

Service Placeholder B

...

Service ProviderService Agent

Service ProviderService Agent...

Service Verification & Validation

Agent

Architecture PatternsApplication BuilderArchitecture Specification

Process SpecificationConstraint Specification

Process Patterns

Constraint Patterns

Application Repository

Application Registry

Service Registry

Service Repository

Service Discovery & Matching Agent

05/06/10 39

PSML-C Composition & Collaboration Framework (Cont.)

The service broker stores not only service specifications, but also application templates and collaboration patterns.

Application builders publish the application templates in the service broker.

Service providers can subscribe to the application registry. The pattern repository stores different types of collaboration

patterns including architecture patterns, process patterns, and constraint patterns.

The Service Discovery & Matching Agent (SDMA) discovers and matches not only the services but also the application templates.

The Service Verification & Validation Agent (SVVA) supports the verification and validation on both individual services and the composite service collaboration with CV&V (Collaborative Verification & Validation) technologies.

05/06/10 40

Collaboration Patterns

Collaboration Patterns are repeatable techniques used by collaborative services to facilitate rapid and adaptive service composition and collaboration. Reduce effort for composition Reuse previously identified collaboration

Compatible with the categorization in PSML-S specification and modeling process. Architecture Patterns Process (behavioral) Patterns Constraint Patterns

When compositing a new service, we follow the order below: Architecture -> Process -> Constraint

05/06/10 41

Application Composition Process

When building a new service-oriented application which is a composite service consisting of multiple collaborative services, the service composition and collaboration process can be described as following:1. Application builder submit a request to the application repository to retrieve

an appropriate application template;2. The application builder decides which architecture pattern needs to be

applied to build the application;3. Only if the architecture of the application has been identified, the application

builder identifies what process patterns can be applied;4. Then, the constraint pattern may be applied to the application based on the

architectural and behavioral design;5. Application builder retrieves different services from the service pool

according to the application template subscription information provided by the service broker;

6. The services will be tested against different acceptance criteria provided by the application builder for service selection;

7. Application builder simulates the composed service to evaluate the overall performance;

8. Application builder integrate the selected services and deploy the application.

05/06/10 42

PSML-C Dynamic Collaboration Architecture

Service B


Service A


Dynamic Analysis

Static Analysis

Reconfiguration


ECPA

Repository

ECPP-A

Collaboration Protocol Registry

Completeness & Consistency

Simulation

ECPP-Y

ECPP-Z

ECPP-B

Model CheckingPatterns

Registration, Discovery &

Matching


ECPPUse

ScenarioRecomposition

Policy Enforcement

RTV&V

Profiling

Monitoring




ECPPUse

ScenarioConstraint Specification

ECPP-X

05/06/10 43

PSML-C Dynamic Collaboration Architecture (Cont.)

For collaboration, each service will be specified with Process specification Interface specification Collaboration specification

Before each service can be registered to the repository, it will be verified and validated by multiple static analyses including simulation.

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 evaluate the runtime behaviors of the service collaboration.

05/06/10 44

PSML-C Collaboration Phases

Collaboration Preparation Service specification Static analyses Service registration Application template registration

Collaboration Establishment Service discovery and matching Service ranking Collaboration agreement negotiation Dynamic simulation

Collaboration Execution Policy enforcement Dynamic reconfiguration and recomposition Dynamic monitoring and profiling

Collaboration Termination Collaboration verification Collaboration evaluation

05/06/10 45

Agenda


05/06/10 46

Verification Framework for Dynamic Collaboration Protocol (DCP) 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 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.

05/06/10 47

Verification Framework for Dynamic Collaboration Protocol (DCP)

Simulation can be performed using sample applications before deployment, and just-in-time on-the-fly simulation can be performed when the actual collaboration protocol and parties are known at runtime.

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

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

Simulation

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

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

Model checking on the code or state model.

Model Checking

Dynamic profiling and re-profiling at collaboration runtime

Dynamic profiling with data collected by distributed agents.

Static profilingTest case profiling

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

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

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

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

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

Static configurations and systems must be linked before integration testing

Integration testing

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

On-line regression testing using data dynamically collected.

Off-line regression testing.Regression testing

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

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

Off-line field testing or simulation.Operational testing

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.

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.

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

Verification Approach

Dynamic application composition via run-time service collaboration

The workflow model is specified but services can be dynamically discovered.

Statically constructed based on specification.

Application Model

DCP Collaboration V&VService-Oriented CV&VTraditional IV&V

05/06/10 48

Verification in Each DCP Stage

Policy Specification / Test Agent

Update Profiling Termination

Policy Enforcement / Monitoring / Test Agent

N/AExecution

USS compatibility check / Simulation / Test Agent

N/AEstablishment

Simulation / Policy Enforcement / Test Agent

Process Consistency / Model Checking

Prepare/ Profiling

DynamicStaticStage

05/06/10 49

Verification at Preparation and Profiling Stage

Partial view with local CIS onlyCIS

Partial view with local IPS onlyIPS

Partial view with local USS onlyUSS

Has previous sample ECPAECPA

Partial view with local ECPP onlyECPP

CompletenessSpec

Specification Completeness Table

Static Analysis Completeness & Consistency

(C&C) Checking Consistency Checking by Model

Checking Consistency model checking on

USS and IPS Consistency model checking on

ECPP and IPS Dynamic Analysis

Dynamic runtime simulation Policy enforcement Distributed testing with Agents

Service

IPS

CIS

ECPP USS

ECPA

?? ?

Simulation with Unknown Partners

05/06/10 50

Verification at Establishment Stage

Complete view CIS

Complete view with global IPS IPS

Complete view USS

Complete view with global ECPA ECPA

Complete view ECPP

CompletenessSpec


Static Analysis N/A

Dynamic Analysis USS compatibility analysis Dynamic simulation and policy

enforcement Distributed testing with Agents

Simulation with Known Partners

Service

IPS

CIS

ECPP USS

ECPA

...IPS

CIS

ECPP USS

ECPA

Service 1

IPS

CIS

ECPP USS

ECPA

Service n

05/06/10 51

Verification at Execution Stage

Complete view CIS

Complete view with global IPS IPS

Complete view USS

Complete view with global ECPA ECPA

Complete view ECPP

CompletenessSpec


Static Analysis N/A

Dynamic Analysis Runtime Monitoring and Testing Dynamic simulation and policy

enforcement Distributed testing with Agents

Simulation with Known Partners

Service

IPS

CIS

ECPP USS

ECPA

...IPS

CIS

ECPP USS

ECPA

Service 1

IPS

CIS

ECPP USS

ECPA

Service n

05/06/10 52

Verification at Termination Stage

Static Analysis Update Profiling

Dynamic Analysis Policy enforcement Re-profiling Distributed testing with Agents

Profile

Service

IPS

CIS

ECPP USS

ECPA

...IPS

CIS

ECPP

USS

ECPA

Service 1

IPS

CIS

ECPP

USS

ECPA

Service n

ProfileRepository

Sample ProfileRepository

Feedback

Verification & Validation

(C&C Analysis / Model Checking /

Simulation)

Passed?

Model Refinement

N

MAST Testing w/ Policy Enforcement

Deployed Application

Y

Data CollectionRe-Profiling

Verification in Collaboration Termination

05/06/10 53

Integrated DCP architecture with dynamic verification

Service B


Service A


Dynamic Analysis

Static Analysis

Reconfiguration


ECPA

Repository

ECPP-A

Collaboration Protocol Registry

Completeness & Consistency

Simulation

ECPP-Y

ECPP-Z

ECPP-B

Model CheckingPatterns

Registration, Discovery &

Matching


ECPPUse

ScenarioRecomposition

Policy Enforcement

RTV&V

Profiling

Monitoring




ECPPUse

ScenarioConstraint Specification

ECPP-X

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.

05/06/10 54

Agenda


05/06/10 55

Collaboration Example - Collaboration Scenario

The collaboration is based on the PSML-C collaboration framework.

Collaboration Control Center

1

2

34

Bait

Guard

Runner

Bait

Guard

Runner

05/06/10 56

Collaboration Example - Application Composition

1. For Collaboration Control Center, Bait, and Runner, we choose the tree pattern as the architecture pattern;

2. We choose the mediator pattern as the process pattern;3. For constraint patterns:

Two way synchronous communication for communication channel between Collaboration Control Center and Runner;

One way synchronous communication for communication channel between Collaboration Control Center and Bait


Bait Runner


Bait Runner


Bait Runner

05/06/10 57

Collaboration Example - Adaptive Dynamic Re-composition

In case of emergency, all communications to the control center are not available: Dynamic recomposition Dynamically switch to direct collaboration


Bait Runner

05/06/10 58

Collaboration Example - Service Specification for Bait

ECPP for the Bait service: ActionSet = {Locate, Approach, Engage, Distract, Disengage}

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

Process Specification:

Approach

Engage

Distract

DISENGAGE?N

Bait

Disengage

Locate

Y

do ACTION Locatedo ACTION Approachdo ACTION Engagedo ACTION Distractwhile (! DISENGAGE) Holddo ACTION Disengage

05/06/10 59

Collaboration Example - Service Specification for Runner

ECPP for the Runner service: ActionSet = {Prepare, Run, Confirm, Retry}

Within which: START: {Prepare} END: {Confirm} IN: {Prepare, Run} OUT: {Prepare, Confirm}

Process Specification:

Prepare

DISTRACTED?N

Y

Run

Confirm

Runner

do ACTION Preparewhile (! DISTRACTED) Holddo ACTION Rundo ACTION Confirm

05/06/10 60

Collaboration Example - ECPA Negotiated

CT = { (Distract, Run), (Confirm, Disengage) }

Approach

Engage

Distract

Bait

Disengage

Locate Prepare

Run

Confirm

Runner

DISTRACTED

DISENGAGE

1 2

34

05/06/10 61

Rapid Application Building Example - Application Template Rapid application building is based on the CCSOA framework The application builder searches the application repository and retrieves the pre-

stored online shopping application mission workflow Each box with grey background denotes a service placeholder. Each collaboration point needs to be replaced with an actual service when building the

application. There are several pre-approved services linked to the collaboration points defined in the

application template. Diagrams below show the

Online shopping application template Service Repository

Account Service Shipping Service

Payment Service

ListCatalog

AddToCart

Continue Shopping ?

N

Logout

Login

Y

ProcessPayment

ProcessShipping

StartCheckout

PlaceOrder

Payment Validated ?

Shipping Validated ?

Y

Y

N

N

PlainShipping

PlainPayment

TrackedShipping

e-Payment

Account Service

SecureSignIn /Out

PlainSignIn/Out

Catalog Service

GraphicCatalog

TextCatalog

Checkout

SecureSignIn /Out

PlainSignIn/Out

05/06/10 62

Rapid Application Building Example - Final Application

Account Service Shipping Service

Payment Service

ListCatalog

AddToCart

Continue Shopping ?

N

Logout

Login

Y

ProcessPayment

ProcessShipping

StartCheckout

PlaceOrder

Payment Validated ?

Shipping Validated ?

Y

Y

N

N

TrackedShipping

e-Payment

Account Service

SecureSignIn /Out

Catalog Service

GraphicCatalog

Checkout

SecureSignIn /Out

05/06/10 63

Agenda


05/06/10 64

Summary

As a part of an integrated service-oriented development environment: PSML-S provides the modeling and specification capacity

for services. The model specified in PSML-S can be verified by

multiple analyses CCSOA provides a building framework for service

collaboration Application template

Based on the PSML-S and CCSOA, PSML-C provides capabilities of specification and analyses for service-oriented on-demand process collaboration. Application composition Service collaboration

05/06/10 65

Benefits

PSML-C collaboration framework facilitates the rapid and adaptive service composition and collaboration based on PSML-S and CCSOA: Multiple static analyses can be applied to evaluate

collaboration specification Collaboration can be simulated to evaluate the dynamic

behaviors of the collaboration Process specification based PSML-C collaboration

protocols facilitates the flexible on-demand process collaboration among the participants

Predefined collaboration patterns can greatly reduce the effort for application development Reuse the existing knowledge Changes can be applied rapidly at the pattern level

05/06/10 66

Benefits (Cont.)

With the PSML-C service composition and collaboration framework: User-Oriented services can be designed and

developed more efficiently It is possible to seamlessly deliver customized

value-added services any time, any where to any device

05/06/10 67

Thanks!

4/5/10 1 Dynamic Collaboration Protocol in Service Oriented ...

Documents

Transcript of 4/5/10 1 Dynamic Collaboration Protocol in Service Oriented ...