Transcript Diapositive 1

Staging Telephony Service Creation:
A Language Approach
Charles Consel1, Fabien Latry1, and Julien Mercadal1
1Phoenix
Research Group
INRIA / LaBRI
http://phoenix.labri.fr
IPTComm – July 2007
Context
 Why ?
– Expectations among users to create telephony services.
 What ?
– Call routing services,
– Signaling-related operations.
 Where ?
– Located on network servers.
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
2
Challenges in Call Routing Services
 Call routing is an intricate task, requiring expertise in a
number of areas
– Distributed systems, networking, telecommunications.
 Diversity management is very challenging
– Programmers : end-user, PABX administrator, telephony carrier,
– Technologies: APIs, languages, platforms.
 Reliability of call routing services is a strong pre-requisite
– Domain properties to verify.
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
3
Bridging The Gap
 Gap between business  IT
Implementation expert
 technologies
IPTComm - July 2007
Telephony expert
 service logic
Phoenix Group - INRIA / LaBRI
4
Bridging The Gap

Call routing domain
– Telephony experts,
– High level (e.g., modeling)
– Code generation difficult.
What
GAP
Domain
Knowledge
How

Call routing implementation
– Implementation experts,
– Technology dependant,
– Code verification difficult.
IPTComm - July 2007
public class Example {
[...]
private AddressFactory factory =
getAddressFactory();
public void processRequest (Request rq){
...
}
}
Phoenix Group - INRIA / LaBRI
5
Our Approach
 Aim
– Providing a language for each kind of experts,
– Improving:
» Accessibility of routing service programming,
» Reliability of service development.
 Idea
– Relying on programming languages, and specifically on domainspecific languages (DSLs),
– Introducing a layered architecture of DSLs,
– Leveraging high-level tools to compile and verify services.
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
6
Domain-Specific Languages
 Domain-specific language
» Domain-specific notations and concepts,
» Abstracting implementation details,
» Easing program development.
 Different kinds of DSLs
– Modeling the domain vs. programming the domain
» A DSL may or may not require programming skills.
– Domain-specific modeling language (DSML)
» Centered around end-user; requires domain expertise (e.g., CPL).
– Domain-specific programming language (DSPL)
» Centered around implementation; requires programming expertise (e.g.,
SPL).
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
7
Bridging The Gap
DSML
Modeling
What
GAP
Domain
Knowledge
How
public class Example {
[...]
private AddressFactory factory =
getAddressFactory();
Implementation
Implementation
public void processRequest (Request rq){
...
}
}
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
8
A Layered Approach
 DSML
– Targets the DSPL
– Verification of domain
properties

DSML
Modeling
DSPL
Programming
DSPL
– Interface between the domain
and the implementation
– Generates implementation
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
Implementation
Implementation
9
A DSPL as a Pivotal Layer
Preference / Constraint / Trust level / Purpose / Abstraction level /…
DSML 1
DSML 2
…
 Bridge the gap, but also
– Simplify the compilation,
– Enable to have a variety of DSMLs,
– Target multiple implementations.
DSPL
Implementation 1
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
Implementation 2
…
10
Staging Processings
Verification related to the domain
DSML 1
DSML 2
…
DSML Compilation
Verification related to the program
DSPL
DSPL Compilation
Implementation 1
Implementation 2
…
http://phoenix.labri.fr/processings
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
11
Processing DSMLs: Case Study
 DSMLs
– Call Processing Language (CPL)
» XML-based scripting language,
» Domain experts, non-programmers.
– VisuCom
» Graphical language,
» Domain experts, non-programmers
 DSPL
– Session Processing Language (SPL)
» Abstracts over underlying protocols, platform,
» Programmers.
 High-level tools
– Program generation,
– Program verification.
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
12
Processing DSMLs: Case Study
CPL or VisuCom
Program
Stratego/XT
Stratego/XT
SPL Program
TLA+ Specification
Compilation
TLC Model Checker
Error
Report
Verification
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
13
Compilation: From CPL to SPL
<?xml version="1.0" encoding="UTF-8"?>
<cpl>
<subaction id="voicemail">
<location url="sip:[email protected]">
<redirect/>
</location>
</subaction>
<incoming>
<location url="sip:[email protected]">
<proxy>
<busy>
<sub ref="voicemail"/>
</busy>
<otherwise>
<address-switch field="origin">
<address is="sip:[email protected]">
<location url="tel:+19175554242">
<proxy />
</location>
</address>
</address-switch>
</otherwise>
</proxy>
</location>
</incoming>
</cpl>
SPL
service example {
processing {
dialog {
response incoming INVITE() {
response r = forward 'sip:[email protected]';
if (r == /ERROR/CLIENT/BUSY_HERE) {
return forward 'sip:[email protected]';
} else if (r == /ERROR) {
if (FROM == 'sip:[email protected]') {
return forward 'tel:+19175554242';
}
}
return r;
}
}
}
}
CPL
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
14
Compilation: From CPL to SPL
<?xml version="1.0" encoding="UTF-8"?>
<cpl>
<incoming>
<location url="sip:[email protected]">
<proxy>
<busy>
<location
url="sip:[email protected]">
<proxy />
</busy>
<otherwise>
<address-switch field="origin">
<address is="sip:[email protected]">
<location url="tel:+19175554242">
<proxy />
</location>
</address>
</address-switch>
</otherwise>
</proxy>
</location>
</incoming>
</cpl>
RuleRedirectNonTerminal :
<location url="callee"> <proxy> <busy> stat1* </busy>
<otherwise> stat2* </otherwise> </proxy> </location>
->
|[ response r = forward callee ;
if ( r == /ERROR/CLIENT/BUSY_HERE ) {
stat1*
} else {
stat2*
} ]|
where new => r
RuleFROMTest :
<address-switch field="origin"> <address is="caller"> stat1*
</address> </address-switch>
->
|[ if (FROM == caller) {
stat1*
} ]|
service example {
processing {
dialog {
response incoming INVITE() {
response r = forward 'sip:[email protected]';
if (r == /ERROR/CLIENT/BUSY_HERE) {
return forward 'sip:[email protected]';
} else if (r == /ERROR) {
if (FROM == 'sip:[email protected]') {
return forward 'tel:+19175554242';
} else {
return r;
}
}
return r;
}
}
}
}
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
15
Verification of Call Routing Properties
 Properties
–
–
–
–
No duplicate redirect,
No redirect to the caller,
No infeasible path,
Service interaction.
NoTwiceRedirectToTheSameURI ≜
□ (∀n  1..Len(signalingActions) : ∀m  n+1..Len(signalingActions) :
signalingActions[n] ≠ "Continuation" ⇒ signalingActions[n] ≠ signalingActions[m])
NoRedirectToTheCaller ≜
□(∃x  Contacts :
 ∀n  1..Len(callerTests) : x  callerTests[n]
 ∀m  1..Len(signalingActions) : signalingActions[m] ≠ x)
Consistency ≜
 □(∃x  Contacts : ∀n  1..Len(callerTests) : x  callerTests[n])
 □(date ≠ {})
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
16
Verification of Call Routing Properties
 Properties
–
–
–
–
No redirect to the caller,
No duplicate redirect,
No infeasible path,
Service interaction.
Incoming call
Is the day of the call
Tuesday ?
yes
3
5
Annual holidays
...
IPTComm - July 2007
Weekly meeting
2
no
Forward call to
Bob’s phone
4
Is the date of the call
between 07/12
and 07/17 ?
yes
6
1
Redirect call to
Bob’s voice mail
Phoenix Group - INRIA / LaBRI
no
Redirect call to
Bob’s cell phone
7
17
VisuCom


Graphical environment
Tightly coupled with information systems
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
18
VisuCom Service Model
checking
Call routing logic
Contact database
Service
 Evolution of the service logic with respect to data sources
– Description of the service logic : static
– Data on which the service relies on : dynamic
 Service : dynamic
 Need for consistency checking
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
19
Verification of Call Routing Properties
 Properties
–
–
–
–
No redirect to the caller,
No duplicate redirect,
No infeasible path,
Service interaction.
Data model:
Group customer: Alice, Bob, Daniel
Group VIP: Frank
 No intersection
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
20
TLC Error Report
TLC Version 2.0 of January 16, 2006
Model-checking
Implied-temporal checking--satisfiability problem has 2 branches.
Finished computing initial states: 1 distinct state generated.
Error: Invariant Consistency is violated. The behavior up to this point is:
STATE 1: <Initial predicate>
/\ callerTests = << >>
/\ currentNode = "Incoming"
/\ signalingActions = << >>
STATE 2: <Action line 32, col 9 to line 34, col 54 of module VisuCom>
/\ callerTests = << >>
/\ currentNode = "CustomerGroup"
/\ signalingActions = << >>
STATE 3: <Action line 37, col 9 to line 40, col 53 of module VisuCom>
/\ callerTests = << {"Alice", "Bob", "Daniel"} >>
/\ currentNode = "VIPGroup"
/\ signalingActions = << >>
STATE 4: <Action line 49, col 9 to line 52, col 59 of module VisuCom>
/\ callerTests = << {"Alice", "Bob", "Daniel"}, {"Frank"} >>
/\ currentNode = "Forward"
/\ signalingActions = << >>
5 states generated, 5 distinct states found, 2 states left on queue.
The depth of the complete state graph search is 4.
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
21
Assessment
 Benefits of the layered view of DSLs
– Simplification of the DSML processings,
– Specific treatment at each layer.
 High-level compilation approach
– Compilation more amenable to existing high-level program
generation tools,
– A bridge between a DSML and its implementation.
 High-level verification approach
– Verification more amenable to existing verification tools,
– Verification of domain-properties.
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
22
Conclusion
 An approach to improving the development and the
verification of call routing services.
– Accessibility of routing service programming,
– Development of reliable services.
 Approach
– Relying on a layered view of domain-specific languages,
– Leveraging high-level tools to compile and verify services.
 Validation of the approach for a realistic case study.
IPTComm - July 2007
Phoenix Group - INRIA / LaBRI
23