Service Behavior Consistency in the OSGi Platform

1. Service Behavior Consistency in the OSGi Platform Authors Y.Qin, H.Hao,L.Jun , G.Jidong and L.Jian Proceedings of 12th Asia-Pacific Software Engineering Conference (APSEC’05) (acceptance rate ~= 29%) Reporter C.F.Liao (廖峻鋒) Feb 15,2007

2. Outline • Preliminaries • Behavior Inconsistency Problem • The Proposed Solutions • Service Behavior Modeling • Verification of Service Behavior Consistency • Implementation skipped • Conclusion

3. Structural Consistent 220 V Structural Consistent but Behavioral Inconsistent! What this Paper is Talking About? Reusable Component 110V

4. Making Software Reusable Invoker Invoker When you modify service X, You have to rewrite all of it’s invokers! openTV(), X.10 openTV(), UPnP

5. Interface As Service Specification Invoker X.10 Implementation of openTV() The developers can substitute the service implementations without affecting the invoker. Spec of openTV() (Interface) UPnP Implementation of openTV()

6. Substitutable Components We can substitute Service A with Service B without affect overall system behavior iff Service A is Structural Consistent with Service B w.r.t. a common interface I

7. Term Definitions Service Client / Service Invoker Service Specification / Interface Service Implementation / Component / Service

8. Formal Definitions of Interfaces and Services • Service Specification (interface) • Service Implementation Unique id of IF A set of exported methods of IF A set of exported methods of S Unique id of S

9. Structural Consistency • SA is Structural Consistent with SB w.r.t An InterfaceIF if and only if LogService log SA LogService and log SB

10. init init finalize finalize log log init finalize logDB log Structural Consistency – An Example Given LogService ConsoleLogService We can obtain that DBLogService So ConsoleLogService is Structural Consistence with DBLogService w.r.t. LogService

11. Enhanced Structural Consistency in OSGi • OSGi enhances structural consistency by specifying “Properties” of components. • Format: • RFC 1960: ”A String Representation of LDAP search filters” • Example: &(DeviceName=TV2) (Size=21) |(vendor~=HP)(!(dpi<=300))(type=printer)

12. OSGi Services We can revise the previous definition of a Service to the following form: A set of properties of S A set of exported methods of S Unique id of S

13. Behavioral Consistency • Proposed by B.Liskov and N.Belkhatir at 1994 in the ACM Trans on PLS. • The interface mechanism in traditional OOP only guarantees Structural Consistency • The implementations may have unexpected behavior even if they are Structural Consistent. Behavior A matter of call sequences from the Service Client!

14. 220 V The Problem of Structural Consistency • Structural Consistency only guarantees the service implementations are structurally compatible with each other. • The underlying behavior of methods may different.  What if the 110V and 220V have the same socket shape? 110V

15. init init finalize finalize log log Behavior Consistency – An Example(1) LogService init log ConsoleLogService finalize

16. init finalize log init finalize logDB log Behavior Consistency – An Example(2) LogService init logDB log DBLogService The expected call sequences of LogService is different from that of DBLogService ! finalize

17. Ensuring the Behavior Consistency • Behavior Modeling • Workflow Net an extension of Petri Net to model the workflow management systems. • Proposed by W.M.P. van der Aalst in ATPN 1997. • Consistency Validation • Observation / Invocation Behavior Consistency Theory • Proposed by J.Ebert and G. Engels in 1994.

18. Behavior Model (BM) Places Input place / output place Transitions Directed Arcs A function that assigns each transition to a method BM is essentially a Workflow Net except TM is redefined.

19. Summary: Revised Definition of Service

20. Invocation Consistency Service S1’s Behavior Model is invocation consistent with S2’s Behavior Model if What is LMS ?

21. Legal Method Sequence (LMS) • Can be derived by depth-first traversal on a Reachability Graph of a Petri Net. Depth-First Traversal

22. init logDB log finalize Invocation Consistency - Example init log finalize LogService DBLogService

23. init init logDB logDBEnc logDB finalize DBLogService finalize LogService Invocation Consistency isn’t Enough !

24. Method Projection

25. Observation Consistency Service S1’s Behavior Model is observation consistent with S2’s Behavior Model if LogService DBLogService init logDB log finalize

26. init log finalize LogService Observation Consistency - Example init log logDB finalize DBLogService

27. Verifying Behavioral Consistency The Service Implementation S is Behavioral Consistent with Service Specification I iff : (S is invocation consistent with I) (S is observation consistent with I) (The proof of this theory is in [J.Ebert and G. Engels 94])

28. and Summary (1) Structural Consistency (Traditional OOP Reuse) Enhanced Structural Consistency (OSGi Service Reuse) Behavioral Consistency [Liskov et al.94] Modeling: UML Verification: Language Mechanism Modeling: UML Verification: OSGi Platform Modeling: Workflow Net Verification: IC / OC theorems Key=value

29. Motivation Problem Modeling Behavioral Subtyping [Liskov et al.94] Workflow Net [W.M.P. van der Aalst97] Methodology Integration / Mapping Solution Prototype Problem Domain Behavioral Consistency [Liskov et al.94] IC / OC Theorems [J.Ebert et al.94] Reachability Graph / LMS OSGi Component Model Modeling: Workflow Net Verification: IC / OC theorems Extension Multi-Service Coordination Behavioral Consistency Implementation SOBECA Summary (2)

30. Comments • This paper provides formal modeling methods of reusable components. • However, many errors in this paper. • Petri Net modeling will be more valuable if used to model distributed / concurrent components. • Stateful is considered harmful in service design, does the behavior consistency really matter?