Commercial AOSD Deployment in Action
Four years and counting…
five
Nosherwan Minwalla
Luis Blando
Presented at the
First International Conference on
Aspect-Oriented Software Development
University of Twente, Netherlands
April 2002
Outline








Purpose and rationale
Wholesaling in telecommunications. The act of ‘96
 Before and after (retail and wholesale model)
Wholesale gateway system (SIGS)
 Overview and architecture, the Edit Engine
The need for edits; what they are; examples
The Edit Engine
 Circa 1960
 A few design decisions
 Demeter within the Edit Engine (.class, .beh, .java)
 The view from production
Using AOSD
 Efficiency
 Resilience
 Maintenance/evolution
 Analysis of maintenance/problems with the EE as they relate to AOSD
Introducing a new paradigm in a pragmatic industrial setting
 Roles and problems in their absence
 Lessons from patterns
Conclusions
© 2002 – Verizon Communications
Purpose and rationale for this talk
This talk is not about AOP
…or Demeter
…or even programming
The focus is instead in presenting our experience when using AOSD to
build a mission critical system.
- the context
- the engine
- the results
- the problems
© 2002 – Verizon Communications
Why Wholesale in Telecommunications?
The Telecommunications Act of 1996



The act aimed to prevent local phone companies from being monopolies.
The principal barrier to entry in this industry was the large capital required to
set up infrastructure.
To solve this problem, existing local phone companies must resell their
infrastructure which supports local dial tone to long distance companies,
cable TV companies, or anyone wanting to start a local phone company
 Local phone companies before the Act are called Incumbent Local
Exchange Carriers (ILECs) whereas the companies to which these
services are resold are called Competitive Local Exchange Carriers
(CLECs)
 CLECs have access to all local loops and switching centers/central
offices
 If the local loop is damaged, the ILEC is responsible for repair
 The ILEC must provide a discount to the CLEC for dial tone (~17-20%)
 ILECs can only provide services like long distance if they can
substantiate sufficient competition in the local service space
© 2002 – Verizon Communications
Before the act (Retail model)
Examples of ILECs
phone
End
Customer
ILEC

GTE

Bell Atlantic

SBC
1. Customer calls ILEC call center and orders phone service
2. ILEC gives the customer a service activation due date
3. Service is activated on due date

ILEC bills customer directly

Customer reports problems to the ILEC; ILEC resolves problems
© 2002 – Verizon Communications
After the act (Wholesale model)
phone
End
Customer
LSR
CLEC
Wholesale
Gateway
ILEC
LR
1.
2.
3.
4.
5.
6.



Customer calls the CLEC call center and orders phone service
CLEC submits a Local Service Request (LSR) to the ILEC
A Local Response (LR) indicates errors or order completion and includes a
due date for service activation
Errors are fixed by CLEC (or in some cases the ILEC) and the LSR
resubmitted till there are no more errors
CLEC gives the customer a service activation due date
Service is activated on the due date
ILEC bills CLEC; CLEC bills customer
Customer reports problems to the CLEC; CLEC notifies ILEC; ILEC resolves
problems
In other words, a CLEC is a “proxy” for an ILEC, whereas the LSR/Gateway
combination acts as an “adapter” between their respective computer
systems
© 2002 – Verizon Communications
What does The Wholesale Gateway
(Secure Integrated Gateway System) do?




SIGS was GTE Corporation’s response to the need for a system adapter
It acts as a workflow which coordinates handshakes between CLECs and the ILECs Retail
Systems
It provides the necessary indirection to achieve security for ILEC data and prevents CLECs
from seeing each other’s data
Since it’s a single system, it helps ensure that Verizon treats all CLECs with parity (The
Telecommunications Act of 1996 requires this parity)
Ordering
Billing
Provisioning
Repair
Retail Systems
ILEC
Wholesale Gateway (SIGS)
CLEC
GUI
(Call Center)
XML
Web
EDI
Reseller
interfaces
© 2002 – Verizon Communications
SIGS Architecture
Back End Retail Systems
TCP/IP
CICS
Custom EAI layer (for ordering, billing and provisioning negotiation)
Workflow Manager
COM/
CORBA
TCP/IP
Visual Basic
GUI
BisCom
Fax Server
Edit Engine
NDM
EDI
CORBA (IIOP)
WebLogic Application Server
HTTP(S)
XML
HTTP(S)
www
CLEC
© 2002 – Verizon Communications
Why Edit?



An “edit” is simply TELCO parlance for a check for correctness made on a
long, convoluted, and cryptic data form
Aligned with their customer-centric philosophy, Verizon ‘West’ (formerly
GTE Corp.) was very lenient as far as the correctness of orders (LSRs) it
accepted. Syntactic as well as semantic errors were allowed. Based on
edits performed, a severity would be assigned to the errors on that order.
If the order was greater than a threshold they would be sent back to the
CLEC. If not, then a call center employee would attempt to fix these
errors.
LSRs with errors below a low threshold can be automated – i.e. they are
ready for negotiation with retail system. This automation is the basis for
cost savings and helps achieve the parity between CLECs.
© 2002 – Verizon Communications
Why Edit (continued)
Few/no errors
CLEC
LSR
Edit Engine
More errors
Retail Systems
Call Center
(fix errors)
SIGS
Too many errors/errors of a nature which can’t
be fixed by call center reps. CLEC must fix
© 2002 – Verizon Communications
What does EE edit, and what sort of edits?
 It edits fields on LSRs
 The edits are
 Format checks
Field lengths and field domain inclusion
 Relationship checks
Form-level dependencies among fields
 “Back-end checks”
Semantic checks based on business rules driven by
legacy systems
© 2002 – Verizon Communications
Back-end edits – an example
 In Telecommunications, even addresses aren’t simple!
Address line 1:
Address line 2:
City:
State:
Zip:
A USPS address
LOCNUM:
NAME:
SAPR:
SANO:
SASF:
SASD:
SASN:
SATH:
SASS:
SADLO:
FLOOR:
ROOM:
BLDG:
CITY:
STATE:
ZIP CODE:
LCON:
TEL NO:
A Telecommunications
address
© 2002 – Verizon Communications
Back-end edits (example cont’d)

Example 1: Validating an address
 Must be exact string compare with
provisioning system.
 Each address component (all 18 of
them) should be correct
Provisioning/Inventory systems
TCP/IP
Edit Engine
LSR
© 2002 – Verizon Communications
Edit “Engine”, circa 1960

There are lots of these edit rules (hundreds)

They are negotiated with CLECs and change often

Business analysts drive the change in the rules

However, in the past these edit rules were hard-coded in different
places within the COBOL, C, or C++ application which was
processing that part of the request

Thus the idea of centralizing all edits in a true engine was born…
 …and designing a language that business analysts could use to
update the rules themselves
 …and selecting a technology that would make the system
resilient to changes in the rules’ structure or content
© 2002 – Verizon Communications
A few design decisions
 The language was called EEL (Edit Engine Language) 
 Very simple semantics, except for interesting “wildcard”
variations
 Because of execution speed, the engine would be compiled
as needed into native code (C++)
 Interpreting the EEL at run time was not feasible (at the
time)
 We needed a subsystem/tool to generate the C++
representation of EEL rules
The EELC was born
And Demeter/Java was used to build it
© 2002 – Verizon Communications
How is Demeter used in the Edit Engine
Engine Generation Process
.eel
EELC
framewor
k.cpp
rules.cpp
CC
EELC
.cd
.beh
demjava
.java
javac
LSR
Edit Engine
.class
© 2002 – Verizon Communications
The class dictionary
•Used to define the structure of the
system, mimicking the grammar of the
edit engine language.
•Changed whenever new primitives
and other artifacts are added to the
language.
// an entire eel program is just a list (possibly empty) of
// issue declarations
CompilationUnit
= IssueList .
IssueList
~ {IssueDeclaration} .
// an issue declaration starts with "issue", is followed by
// a string (the name), an optional integer, and the body.
IssueDeclaration
= "ISSUE" <name> String
[ <num> Integer ]
IssueBody .
// an issue body is enclosed in braces and contains one
// metaset and a list of rulesets
IssueBody
= "{" <metaset> MetaSet
<sets>
RuleSetList "}" .
EELC
.cd
.beh
demjava
.java
javac
.class
// a metaset starts with "meta", is enclosed in braces, and
// contains a list of metasetrules.
MetaSet
= "meta" MetaSetBody .
MetaSetBody
= "{" <rules> MetaRuleList "}" .
// a ruleset starts with "set" and has a name, then
// a brace and a list of rules followed by another brace
RuleSetList
~ {RuleSet} .
RuleSet
= "set" <name> Ident
"{"
<rules> RuleList "}" .
. . .
© 2002 – Verizon Communications
The behavior file
CompilationUnit {
traversal allRules(EELVisitor)
{ to {MetaSetRule, SpawnableRuleSetRule, RuleSetRule};
•Used to define the functionality of the
visitor that produces the C++ code as
it traverses the structure defined in the
.cd file
}
traversal constrMeta(EELVisitor)
{ via MetaSetRule to Name; }
traversal constrOther(EELVisitor)
{ to {SpawnableRuleSetRule, RuleSetRule}; }
traversal viaRules(ValidateVisitor,CommandVisitor,ExpressionVisitor)
{ bypassing MetaSetRule to *; }
traversal
viaMetaRules(MetaValidateVisitor,CommandVisitor,ExpressionVisitor)
{ bypassing Rule to *; }
• Largely unchanged except for
technology “refreshments”`
}
EELC
.cd
.beh
demjava
.java
javac
.class
Rule {
traversal
toStaticValues(ValidateVisitor,CommandVisitor,ExpressionVisitor)
{ to {StaticValueInt,StaticValueString}; }
}
MetaSetRule {
traversal
toStaticValues(ValidateVisitor,CommandVisitor,ExpressionVisitor)
{ to {StaticValueInt,StaticValueString}; }
}
HeaderVisitor {
before MetaSetRule (@
common_part(host.get_name().toString());
buffer += "
virtual RWBoolean MetaCheck(Form*);\n";
// find all the local variables and define them
ValidateVisitor
vv = new ValidateVisitor();
CommandVisitor
cv = new CommandVisitor();
ExpressionVisitor ev = new ExpressionVisitor();
vv.set_cmd( cv );
cv.set_ev( ev );
host.toStaticValues(vv,cv,ev);
© 2002 – Verizon Communications
The (generated) Java file
• Completely automatically generated.
Embodies the weaved code that
ultimately processes the .eel files.
• After compiled with javac, it is
invoked with java Main …
EELC
.cd
.beh
demjava
.java
javac
.class
import java.util.*;
import java.io.*;
import EDU.neu.ccs.demeter.*;
class Main implements Cloneable {
public Main() {
super();
}
public static Main parse(java.io.InputStream in) throws ParseError
{ return new Parser(in)._Main(); }
public static Main parse(String s) {
try { return parse(new java.io.ByteArrayInputStream(s.getBytes()));
}
catch (ParseError e) { throw new RuntimeException(e.toString()); }
}
static public String header(String file_name, String desc) {
String buffer = new String();
String fname = file_name.replace( '.', '_' );
buffer +=
"//====================================================================
===\n";
buffer += "// " + file_name + "\n";
buffer += "//
- " + desc + "\n";
buffer += "//----------------------------------------------------------------------\n";
buffer += Main.copyright();
buffer += "//----------------------------------------------------------------------\n";
buffer += "// this is an automatically generated file. it was
generated on:\n";
Date date = new Date();
buffer += "// " + date.toString() + "\n";
buffer +=
"//=============================================================“;
© 2002 – Verizon Communications
The view from production
 The Edit Engine has been in production for 5+ years
 It processes up to 10,000 orders per day
 It has adapted to 4 Different LSOG guidelines
 It has had 8 sets of developers come and go
 It was the basis for a US Patent
 Errors in its processing could potentially cost Verizon
millions of dollars in fines from the FCC – to say nothing
of the lost revenue. As of now, there have been no
correctness problems introduced by the use of AOP.
© 2002 – Verizon Communications
Using AOSD – Development (efficiency)
EELC V1
 C++, Lex, Yacc
 5 man-months
 2300 LOC, 12 files
 Two experienced software engineers
V1
V2
5 man-months
V1
V2
2300 LOC
½ man month
1000 LOC
EELC V2
 Demeter/Java
 2 weeks (includes the time needed to learn Demeter/Java)
 1000 LOC, 2 files
 One experienced software engineer (no Demeter/AOP knowledge exante)
 The generated code is substantially better than V1
© 2002 – Verizon Communications
Using AOSD – Development (resilience)
“The adaptability of the system was put to the test in different occasions.
The original design was changed after the first iteration and the class
structure was modified. Later on, a rather major overhaul took place to
replace relatively 'lazy' code generation (i.e. relying on microcode) for
'working' code generation. Last, an optimization was necessary to reduce
the runtime of the generated code. It is at this latest stage when the biggest
execution time penalty was introduced, as several subtraversals were
reused over and over. This optimization (on the generated code) was almost
trivial to implement (less than an hour) but increased the execution time two
or three-fold.”
From the original project summary
November 1997
© 2002 – Verizon Communications
Using AOSD – Maintenance/Evolution
(Interviews with developers over a 6-year span)
(includes
non-AOP
components)
How hard was it to understand the source code?
How easy was it to add additional functionality?
How stable is the engine?
How scalable do you think it is?
How easy is it for business users to edit rules?
Year
Easy/Good
Not bad/Average
1
9
9
7
1
9
9
8
1
9
9
9
2
0
0
0
2
0
0
1
2
0
0
2
A complete
success!
LSOGs were
implemented in
these years
Harder/Bad
Very Hard/Worse
© 2002 – Verizon Communications
Analysis of maintenance/extension trends
Legibility of source code
Stability
As with most software, the source
became less easy to read as time
progressed
A relatively short period of instability
was encountered when CLEC
explosion caused the number of orders
to grow. However, this was a simple
load balancing issue and was easily
resolved.
Extensibility
When the FCC mandated major
changes to ordering guidelines
developers naturally found it harder to
extend functionality. The obvious
exception was when the engine was
originally constructed
Scalability
Initial problems with the scalability of
the application were resolved by the
author.
Bottom line:
 None of the problems in the entire lifecycle of the Edit
Engine were due to Aspect Oriented Design
© 2002 – Verizon Communications
The introduction of a new paradigm in a
pragmatic industrial setting

Introducing “embryonic tools” in an industry setting is hard. It is not
unlike other technical innovations…

David DeLano and Linda Rising of AG Communication Systems in
Arizona worked on the dynamics of technical innovation in industry
Their efforts over a 5 year period were presented in a tutorial at
OOPSLA 2001
Problems which their work addressed include







Most people are skeptical of new ideas
There are too many new ideas – it’s hard to keep up
Everyone is too busy
It takes time and energy to convince others of new ideas
Organizational change is not top-down or bottom-up but participative at all levels,
aligned thorough a common understanding
 Change is not an event, it’s an – often long – process
© 2002 – Verizon Communications
Roles used to solve these problems and
problems in absence of roles
We found that a small subset of the roles, stemming from patterns
they produced, mapped to our corporate environment – and in
particular to several individuals who embodied these patterns.
More importantly, some patterns were clearly missing which led to
architecturally not so good things…
THEN
Research
Environment
Evangelist
NEU
(Karl L) (NEU: Karl L)
Early Adopters
(Luis Blando)
NEU and BBN continue
this symbiotic relationship
Local Leader
Corporate Angel
NOW
Corporate “Fortune 10”
Environment
Dedicated Champion
Helper
© 2002 – Verizon Communications
Lessons learned from patterns

Applied research and prototype facilities such as GTE Labs are good
at adopting technology quickly but, somewhat counter-intuitively,
paradigms are not widely shared and reuse. (Unfortunately, these
facilities are slowly disappearing)

We believe that the framework which AOP provided to build the edit
engine could be used to construct several infrastructure components
– for example: workflow managers.

However, the lack of the several needed roles did not enable this
paradigm to endure.
 Several implementations of rules engines have since followed
using scripting languages like JavaScript or COM+ based
solutions, none of which are as flexible, configurable for the
business user, or as easy to extend as the AOP implementation.
 Notice that the edit engine can target any language so its
methodologies can be used in any environment.
© 2002 – Verizon Communications
Conclusions






The Edit Engine within SIGS has been a reasonable success
A major component within it is driven by AOSD, more specifically Demeter/Java and its
notions of aspect orientation
It has been in production for five years, as a mission-critical system. It is still going
today with no major outages or problems. The AOSD component is still in use today.
AOSD was an incredible enabler at development time, slashing cost and increasing
quality immediately
However, the lack of a hands-on, dedicated champion affected its adoption and
evolution, having been relegated to the status of “a cool trick from those guys at Labs”
by mainstream developers. It is being maintained, but not really learned…
 More commonly known as the Joe Programmer dilemma: “where do I point my
browser, java.sun.com or www.aosd.net?”
Dedicated champions in industry setting cannot focus entirely on AOSD. Thus, it is
important that mainstream software engineers take to AOP out of their own interest to
fuel the adoption dynamics. The evangelist or champion can start them off, but there
needs to be a clear interest from their end.
 Generating this interest is difficult, specially in the face of such “commercialization”
of programming languages
© 2002 – Verizon Communications
Descargar

Document