Скачать презентацию Commercial AOSD Deployment in Action Four years and Скачать презентацию Commercial AOSD Deployment in Action Four years and

4f4df6623a4ec05cbbc5b480e1550247.ppt

  • Количество слайдов: 28

Commercial AOSD Deployment in Action Four years and counting… five Nosherwan Minwalla Luis Blando 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 Outline · · · · Purpose and rationale Wholesaling in telecommunications. The act of ‘ 96 u Before and after (retail and wholesale model) Wholesale gateway system (SIGS) u Overview and architecture, the Edit Engine The need for edits; what they are; examples The Edit Engine u Circa 1960 u A few design decisions u Demeter within the Edit Engine (. class, . beh, . java) u The view from production Using AOSD u Efficiency u Resilience u Maintenance/evolution Analysis of maintenance/problems with the EE as they relate to AOSD Introducing a new paradigm in a pragmatic industrial setting u Roles and problems in their absence u Lessons from patterns Conclusions © 2002 – Verizon Communications

Purpose and rationale for this talk This talk is not about AOP …or Demeter 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 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 u 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) u CLECs have access to all local loops and switching centers/central offices u If the local loop is damaged, the ILEC is responsible for repair u The ILEC must provide a discount to the CLEC for dial tone (~17 -20%) u 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 · End Customer · ILEC Bell Before the act (Retail model) Examples of ILECs · End Customer · ILEC Bell Atlantic · phone GTE 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) End Customer phone CLEC LSR LR Wholesale Gateway ILEC After the act (Wholesale model) End Customer phone CLEC LSR LR Wholesale Gateway ILEC 1. Customer calls the CLEC call center and orders phone service 2. CLEC submits a Local Service Request (LSR) to the ILEC 3. A Local Response (LR) indicates errors or order completion and includes a due date for service activation 4. Errors are fixed by CLEC (or in some cases the ILEC) and the LSR resubmitted till there are no more errors 5. CLEC gives the customer a service activation due date 6. 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 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 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 Bis. Com Fax Server Edit Engine NDM EDI CORBA (IIOP) Web. Logic 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 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 SIGS More errors Retail Systems Why Edit (continued) Few/no errors CLEC LSR Edit Engine SIGS More errors Retail Systems Call Center (fix errors) 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 What does EE edit, and what sort of edits? · It edits fields on LSRs · The edits are u Format checks Field lengths and field domain inclusion u Relationship checks Form-level dependencies among fields u “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 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 u Must be exact Back-end edits (example cont’d) · Example 1: Validating an address u Must be exact string compare with provisioning system. u 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) · 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… u …and designing a language that business analysts could use to update the rules themselves u …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) u A few design decisions · The language was called EEL (Edit Engine Language) u Very simple semantics, except for interesting “wildcard” variations · Because of execution speed, the engine would be compiled as needed into native code (C++) u Interpreting the EEL at run time was not feasible (at the time) u 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 Generation Process . eel EELC framewor How is Demeter used in the Edit Engine Generation Process . eel EELC framewor k. cpp rules. cpp CC. cd EELC . beh demjava . javac LSR Edit Engine . class © 2002 – Verizon Communications

The class dictionary • Used to define the structure of the system, mimicking the 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 Compilation. Unit = Issue. List ~ {Issue. Declaration}. // an issue declaration starts with "issue", is followed by // a string (the name), an optional integer, and the body. Issue. Declaration = "ISSUE" String [ Integer ] Issue. Body. // an issue body is enclosed in braces and contains one // metaset and a list of rulesets Issue. Body = "{" Meta. Set Rule. Set. List "}". . cd EELC . beh demjava . javac . class // a metaset starts with "meta", is enclosed in braces, and // contains a list of metasetrules. Meta. Set = "meta" Meta. Set. Body = "{" Meta. Rule. List "}". // a ruleset starts with "set" and has a name, then // a brace and a list of rules followed by another brace Rule. Set. List ~ {Rule. Set}. Rule. Set = "set" Ident "{" Rule. List "}". . © 2002 – Verizon Communications

The behavior file Compilation. Unit { traversal all. Rules(EELVisitor) { to {Meta. Set. Rule, The behavior file Compilation. Unit { traversal all. Rules(EELVisitor) { to {Meta. Set. Rule, Spawnable. Rule. Set. Rule, Rule. Set. Rule}; • Used to define the functionality of the visitor that produces the C++ code as it traverses the structure defined in the. cd file } traversal constr. Meta(EELVisitor) { via Meta. Set. Rule to Name; } traversal constr. Other(EELVisitor) { to {Spawnable. Rule. Set. Rule, Rule. Set. Rule}; } traversal via. Rules(Validate. Visitor, Command. Visitor, Expression. Visitor) { bypassing Meta. Set. Rule to *; } traversal via. Meta. Rules(Meta. Validate. Visitor, Command. Visitor, Expression. Visitor) { bypassing Rule to *; } • Largely unchanged except for technology “refreshments”` } . cd EELC . beh demjava . javac . class Rule { traversal to. Static. Values(Validate. Visitor, Command. Visitor, Expression. Visitor) { to {Static. Value. Int, Static. Value. String}; } } Meta. Set. Rule { traversal to. Static. Values(Validate. Visitor, Command. Visitor, Expression. Visitor) { to {Static. Value. Int, Static. Value. String}; } } Header. Visitor { before Meta. Set. Rule (@ common_part(host. get_name(). to. String()); buffer += " virtual RWBoolean Meta. Check(Form*); n"; // find all the local variables and define them Validate. Visitor vv = new Validate. Visitor(); Command. Visitor cv = new Command. Visitor(); Expression. Visitor ev = new Expression. Visitor(); vv. set_cmd( cv ); cv. set_ev( ev ); host. to. Static. Values(vv, cv, ev); © 2002 – Verizon Communications

The (generated) Java file • Completely automatically generated. Embodies the weaved code that ultimately 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 … . cd EELC . beh demjava . 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. Input. Stream in) throws Parse. Error { return new Parser(in). _Main(); } public static Main parse(String s) { try { return parse(new java. io. Byte. Array. Input. Stream(s. get. Bytes())); } catch (Parse. Error e) { throw new Runtime. Exception(e. to. String()); } } 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. to. String() + "n"; buffer += "//===============================“; © 2002 – Verizon Communications

The view from production · The Edit Engine has been in production for 5+ The view from production · The Edit Engine has been in production for 5+ years u It processes up to 10, 000 orders per day u It has adapted to 4 Different LSOG guidelines u It has had 8 sets of developers come and go u It was the basis for a US Patent u 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 V 1 u C++, Lex, Yacc u 5 Using AOSD – Development (efficiency) ·EELC V 1 u C++, Lex, Yacc u 5 man-months u 2300 LOC, 12 files u Two experienced software engineers V 1 V 2 5 man-months V 1 V 2 2300 LOC ½ man month 1000 LOC ·EELC V 2 u Demeter/Java u 2 weeks (includes the time needed to learn Demeter/Java) u 1000 LOC, 2 files u One experienced software engineer (no Demeter/AOP knowledge exante) u The generated code is substantially better than V 1 © 2002 – Verizon Communications

Using AOSD – Development (resilience) “The adaptability of the system was put to the 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. 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 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 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: u 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 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 De. Lano 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 u u u 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 u 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 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 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. u Several implementations of rules engines have since followed using scripting languages like Java. Script or COM+ based solutions, none of which are as flexible, configurable for the business user, or as easy to extend as the AOP implementation. u 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 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… u 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. u Generating this interest is difficult, specially in the face of such “commercialization” of programming languages © 2002 – Verizon Communications