• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
4/5/10 1 Dynamic Collaboration Protocol in Service Oriented ...
 

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

on

  • 438 views

 

Statistics

Views

Total Views
438
Views on SlideShare
438
Embed Views
0

Actions

Likes
0
Downloads
2
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • If more than one systems specified with use scenarios are to be put together to compose a complex system, the interoperation can be generated by intervene the use scenario for individual systems. By the constraints checking we can identify the interoperation that do not satisfy the constraints. Precondition checking / postcondition checking / critical region checking Constraints are specified separately and may be inconsistent with each other. Inconsistency does not have to be an error.
  • In procedural paradigm, collaboration is achieved statically. Function calls are hard coded in program and called explicitly. In object-oriented paradigm, data and its processing are bound together. Collaboration can be achieved through message passing. More effective technologies such as dynamic typing and dynamic binding are used in collaboration. Different functions can have same name and the function calls are determined in runtime. In Service-Oriented paradigm, data is not bound with its processing any more. Services are discovered and composed dynamically. All information required for processing are transferred among different services and are interpreted at runtime. Future development of process collaboration is targeted to adaptive service-oriented paradigm where adaptive control will be supported.

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

  • Dynamic Collaboration Protocol in Service Oriented Architecture W. T. Tsai Computer Science & Engineering Department Arizona State University Tempe, AZ 85287 [email_address]
  • Agenda
    • Overview of Interoperability
    • OASIS CPP/CPA Collaboration
    • Use Scenarios
    • Dynamic Collaboration Protocol (DCP)
    • Verification Framework for DCP
    • Case study
    • Summary
  • 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?
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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?
  • Agenda
    • Overview of Interoperability
    • OASIS CPP/CPA Collaboration
    • Use Scenarios
    • Dynamic Collaboration Protocol (DCP)
    • Verification Framework for DCP
    • Case study
    • Summary
  • 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.
  • OASIS ebXML CPP/CPA specification
    • 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
  • 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.
  • Working Architecture of CPP/CPA with ebXML Registry
  • 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.
  • Limitation of CPP/CPA Deadlock Starving
  • 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
  • Agenda
    • Overview of Interoperability
    • Data Provenance
    • OASIS CPP/CPA Collaboration
    • Use Scenarios
    • Dynamic Collaboration Protocol (DCP)
    • Verification Framework for DCP
    • Case study
    • Summary
  • 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.
  • 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.
  • 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.
  • 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.
  • Agenda
    • Overview of Interoperability
    • OASIS CPP/CPA Collaboration
    • Use Scenarios
    • Dynamic Collaboration Protocol (DCP)
    • Verification Framework for DCP
    • Case study
    • Summary
  • 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:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • Extended CPP (Cont.)
    • Following constraints are highly recommended but not required to the ECPP specification to describe a well-formed collaboration model:
      • Card START = 1  (Card IN > 0  Card OUT > 0)
    • An example of an ECPP specification for a simple online banking service is:
        • START = {Login}
        • END = {Logout}
        • IN = {ApproveLoan}
        • OUT = {CreditCheck}
  • 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  IN 1 and out  OUT 2 and IN 1 is the IN set and OUT 2 is the OUT set of collaboration services respectively.
  • 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.
  • 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.
  • 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.
  • PSML-C Composition & Collaboration Framework
  • 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.
  • 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
  • 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.
  • PSML-C Dynamic Collaboration Architecture
  • 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.
  • 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
  • Agenda
    • Overview of Interoperability
    • OASIS CPP/CPA Collaboration
    • Use Scenarios
    • Dynamic Collaboration Protocol (DCP)
    • Verification Framework for DCP
    • Case study
    • Summary
  • 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.
  • 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 profiling Test 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&V Service-Oriented CV&V Traditional IV&V
  • Verification in Each DCP Stage Policy Specification / Test Agent Update Profiling Termination Policy Enforcement / Monitoring / Test Agent N/A Execution USS compatibility check / Simulation / Test Agent N/A Establishment Simulation / Policy Enforcement / Test Agent Process Consistency / Model Checking Prepare/ Profiling Dynamic Static Stage
  • Verification at Preparation and Profiling Stage 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
    Simulation with Unknown Partners Partial view with local CIS only CIS Partial view with local IPS only IPS Partial view with local USS only USS Has previous sample ECPA ECPA Partial view with local ECPP only ECPP Completeness Spec
  • Verification at Establishment Stage Specification Completeness Table
    • Static Analysis
      • N/A
    • Dynamic Analysis
      • USS compatibility analysis
      • Dynamic simulation and policy enforcement
      • Distributed testing with Agents
    Simulation with Known Partners Complete view CIS Complete view with global IPS IPS Complete view USS Complete view with global ECPA ECPA Complete view ECPP Completeness Spec
  • Verification at Execution Stage Specification Completeness Table
    • Static Analysis
      • N/A
    • Dynamic Analysis
      • Runtime Monitoring and Testing
      • Dynamic simulation and policy enforcement
      • Distributed testing with Agents
    Simulation with Known Partners Complete view CIS Complete view with global IPS IPS Complete view USS Complete view with global ECPA ECPA Complete view ECPP Completeness Spec
  • Verification at Termination Stage
    • Static Analysis
      • Update Profiling
    • Dynamic Analysis
      • Policy enforcement
      • Re-profiling
      • Distributed testing with Agents
    Verification in Collaboration Termination
  • 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.
  • Agenda
    • Overview of Interoperability
    • OASIS CPP/CPA Collaboration
    • Use Scenarios
    • Dynamic Collaboration Protocol (DCP)
    • Verification Framework for DCP
    • Case study
    • Summary
  • Collaboration Example - Collaboration Scenario
    • The collaboration is based on the PSML-C collaboration framework.
  • Collaboration Example - Application Composition
    • For Collaboration Control Center, Bait, and Runner, we choose the tree pattern as the architecture pattern;
    • We choose the mediator pattern as the process pattern;
    • 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
  • 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
  • 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:
  • 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:
  • Collaboration Example - ECPA Negotiated
    • CT = { (Distract, Run), (Confirm, Disengage) }
  • 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
  • Rapid Application Building Example - Final Application
  • Agenda
    • Overview of Interoperability
    • OASIS CPP/CPA Collaboration
    • Use Scenarios
    • Dynamic Collaboration Protocol (DCP)
    • Verification Framework for DCP
    • Case study
    • Summary
  • 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
  • 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
  • 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
  • Thanks!