Presentation is loading. Please wait.

Presentation is loading. Please wait.

Implementing MLP Thomas Lindgren / Fredrik Linder / Magnus Eklund CellPoint AB speaker.

Similar presentations


Presentation on theme: "Implementing MLP Thomas Lindgren / Fredrik Linder / Magnus Eklund CellPoint AB speaker."— Presentation transcript:

1

2 Implementing MLP Thomas Lindgren / Fredrik Linder / Magnus Eklund CellPoint AB speaker

3 Location services Distinctive feature of mobile services Measurements from network collected in a location server (spec: 03.71) Clients access information via HTTP/XML interface to server Clients are portals, resellers, operators, … which then provide info to end-users

4 Standardization Standardized info format from mobile net => location server Plethora of protocols for accessing info location server => client Location interoperability forum (LIF) founded to bring some order –Equipment manufacturers, operators, … –Mobile Location Protocol (MLP) = unifier

5 The MLP Protocol Mobile Location Protocol based on HTTP/1.1 and XML –About half a dozen DTDs define data Many features –Desired accuracy, max age, … –Presentation coordinate system –Varying geometric shapes in reply –Multitude of data formats ”Every feature is optional”

6 SIMPL2 and MLP SIMPL2 developed by Cellpoint as an MLP compatible protocol –Removed some features Zoning, triggering Still had to signal that features not supported –Added some features CLPT-specific extensions for charging records Many changes in MLP and SIMPL2 during development –Fourteen SIMPL2 draft specifications prior to release Seven released during May-June

7 SIMPL2 request application_4 secret

8 SIMPL2 reply W N 570

9 Implementing MLP Integrate inets and xmerl Act as server (MLS) Act as proxy (MLB) –Must still handle all of MLP for proxying non-CLPT location servers Thoroughly validate all incoming data –Requests and replies Translate external  internal format Dispatch to other server or compute location

10 The bad part Aggressive dev schedule (5-6 months x 3 people) –Goal: Release soon after MLP specification is finalized Specification mutates quickly –Major and minor syntax and feature changes –Data formats –Error codes –Specification bug fixes Only protocol syntax specified, not semantics –Semantics sometimes unclear

11 The first-half score Unsatisfactory code –Specification changes => patch upon patch Unsatisfactory testing –Hard for developers to test such a big protocol –Hard for QA to know what worked in a given release Time spent on reacting to trouble reports and specification changes –Release date approaching, but not release

12 Second-half kickoff We needed to get bugs and changes under control –Code must become easy to change Esp. XML validation –Code must have high quality before QA begins Fixing bugs via QA too slow and unhappy for us and QA Must quickly resolve arguments about TRs –Many specification changes => many arguments about what was valid => lost time

13 Abstraction Get rid of records in crucial places –Use abstract data types instead –Encapsulate data representation in module –Can check that data are consistent when created –Operations are named => legible code, intention clear –(Programming 101 …) Why weren’t ADTs used already? –Record notation more convenient (e.g., pattern match) –Records already provide representation independence (sort of)

14 Quick and dirty encapsulation #request_rec{misc = Priv, subscr_i=X#subscr_rec.f3} => request_adt:set_subscriber_info(Priv, X) -module(request_adt). set_subscriber_info(Priv, X) -> #request_req{misc=Priv, subscr_i=X#subscr_rec.f3}.

15 XML validation Original code: traverse xml tree, check values Rewrite for fast change –Use a rule interpreter + separate validation rule set –Easy to check that rules obey current specification –Easy to rewrite or extend without intro bugs Pace of development made this crucial Many draft specs => each must be integrated quickly

16 Validation rules -define(tag_specs, [{'svc_init', blank, [{'ver', {'or', [{member, ["3.0.0"]}, {unsupported, ver}]}}]},... ]). apply_rule(blank, Value) -> [] == strip_whites(Value); apply_rule({'or', Rules}, Value) -> lists:any(fun(Rule) -> apply_rule(Rule, Value) end, Rules);...

17 Improve quality Go for (pre-QA) automated testing –Not a new idea, but awesomely useful (again) –Wrote tester from scratch effort paid back very quickly –Exercise all protocol features –Regression test case added when TR appears –Detects integration bugs as well SIMPL2 ”on top of food chain”

18 Test case specification test_series(1, 1) -> Clients = [{"service_a", "secret", ?OK},...], MSID = "...", [ {Expect, ?svc_init(?hdr_client(Name, Pwd), ?slir(?msids(MSID), ?default_geo_info)) || {Name, Pwd, Expect} <- Clients ];...

19 Social issues Some XP practices used (see paper) Pair programming worked well More refactoring should have been done –Elegance is (should not be) optional –Hard to take the time

20 Evaluation Worked very well in this setting –Bug fixing reduced –Bug hunting reduced –Faster turnaround We could direct efforts to the right areas –Resolve grey areas of SIMPL2 and MLP –Tighten code –Add test cases –”Virtuous circle”

21 Performance evaluation Measured SIMPL2 by running test suite –Single request at a time on unloaded system –Varying cases rather than weighted to normal Results: –15% time in scanning and parsing –8% in validation –18% in port_command, port_close, … (tests include acting as proxy or server, Oracle access, …) –So any speedup from optimizing validation is limited

22 Future work Extend data driven design –Rule-driven translation from/to internal format? Generate a validating XML parser given a validation spec? –Extend xmerl

23 Final score ADTs > Records Data driven design (= validation rules) reduce complexity Automated testing XP-practices (pair programming) SIMPL2 released to customer same week as final MLP specification was released Another grisprotokoll bites the dust


Download ppt "Implementing MLP Thomas Lindgren / Fredrik Linder / Magnus Eklund CellPoint AB speaker."

Similar presentations


Ads by Google