Dynamic Collaboration Protocol in Service Oriented Architecture

1
Dynamic Collaboration Protocol in Service
Oriented Architecture

• W. T. Tsai
• Computer Science Engineering Department
• Arizona State University
• Tempe, AZ 85287
• wtsai_at_asu.edu

2
Agenda

• Overview of Interoperability
• Use Scenarios
• Dynamic Collaboration Protocol (DCP)
• Verification Framework for DCP
• Case study
• Summary

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?

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

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.

6
Agenda

• Overview of Interoperability
• Use Scenarios
• Dynamic Collaboration Protocol (DCP)
• Verification Framework for DCP
• Case study
• Summary

7
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.

8
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.

9
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 ones 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 VV.

10
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.
• ltgt
• Any entities enclosed by ltgt are parameter
  entities.
• With sub-processes, the use scenario can describe
  the interoperation of hierarchical systems in
  different levels.

11
Agenda

• Overview of Interoperability
• Use Scenarios
• Dynamic Collaboration Protocol (DCP)
• Verification Framework for DCP
• Case study
• Summary

12
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

13
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.

14
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.

15
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.

16
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.

17
PSML-C Collaboration Specification

• Collaboration specification consists of
• A set of extended CPPs (ECPP)
• A set of use scenarios and
• A set of predefined extended CPAs (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 ECPAs
  that have been used and evaluated in the
  previously carried out service collaboration for
  rapid collaboration establishment.

18
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.

19
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

20
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.

21
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 gt 0 ? CardOUT gt 0)
• An example of an ECPP specification for a simple
  online banking service is
• START Login
• END Logout
• IN ApproveLoan
• OUT CreditCheck

22
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.

23
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.

24
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.

25
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.

26
PSML-C Composition Collaboration Framework
27
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 CVV (Collaborative
  Verification Validation) technologies.

28
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 -gt Process -gt Constraint

29
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
• Application builder submit a request to the
  application repository to retrieve an appropriate
  application template
• The application builder decides which
  architecture pattern needs to be applied to build
  the application
• Only if the architecture of the application has
  been identified, the application builder
  identifies what process patterns can be applied
• Then, the constraint pattern may be applied to
  the application based on the architectural and
  behavioral design
• Application builder retrieves different services
  from the service pool according to the
  application template subscription information
  provided by the service broker
• The services will be tested against different
  acceptance criteria provided by the application
  builder for service selection
• Application builder simulates the composed
  service to evaluate the overall performance
• Application builder integrate the selected
  services and deploy the application.

30
PSML-C Dynamic Collaboration Architecture
31
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.

32
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

33
Agenda

• Overview of Interoperability
• Use Scenarios
• Dynamic Collaboration Protocol (DCP)
• Verification Framework for DCP
• Case study
• Summary

34
Verification Framework for Dynamic Collaboration
Protocol (DCP)

• Traditionally, systems and software are verified
  using the IVV (Independent Verification and
  Validation) approach, where independent teams are
  used to verify and validate the system during
  system development.
• The SOA challenges the IVV approach as new
  services will be discovered after deployment, and
  thus it is necessary to have CVV (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.

35
Verification Framework for Dynamic Collaboration
Protocol (DCP)
36
Verification in Each DCP Stage
37
Verification at Preparation and Profiling Stage

• Static Analysis
• Completeness Consistency (CC) 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

Specification Completeness Table
Simulation with Unknown Partners
38
Verification at Establishment Stage

• Static Analysis
• N/A
• Dynamic Analysis
• USS compatibility analysis
• Dynamic simulation and policy enforcement
• Distributed testing with Agents

Specification Completeness Table
Simulation with Known Partners
39
Verification at Execution Stage

• Static Analysis
• N/A
• Dynamic Analysis
• Runtime Monitoring and Testing
• Dynamic simulation and policy enforcement
• Distributed testing with Agents

Specification Completeness Table
Simulation with Known Partners
40
Verification at Termination Stage

• Static Analysis
• Update Profiling
• Dynamic Analysis
• Policy enforcement
• Re-profiling
• Distributed testing with Agents

Verification in Collaboration Termination
41
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.
42
Agenda

• Overview of Interoperability
• Use Scenarios
• Dynamic Collaboration Protocol (DCP)
• Verification Framework for DCP
• Case study
• Summary

43
Collaboration Example - Collaboration Scenario

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

44
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

45
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

46
Collaboration Example - ECPA Negotiated

• CT (Distract, Run), (Confirm, Disengage)

47
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

48
Rapid Application Building Example - Final
Application
49
Agenda

• Overview of Interoperability
• Use Scenarios
• Dynamic Collaboration Protocol (DCP)
• Verification Framework for DCP
• Case study
• Summary

50
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

51
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

52
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