1. Greg McChesney Thesis Defense Presentation Computer Science, TTU Greg.mcchesney@ttu.edu Service Context Management for Exertion- oriented Programming

2. Greg McChesney2 Overall Presentation Goal or Primary Purpose Beginning Create a life-cycle for context management in Exertion-Oriented Programming

3. Greg McChesney3 Proposal Objectives As a result of this presentation, you will be able to: –Understand the purpose of service contexts –Understand why a life-cycle is required –Utilize the life-cycle for your SORCER projects –Create a context in SORCER –Modify a context in SORCER –Execute an exertion in SORCER –View a returned exertion context from the federation Beginning

4. Greg McChesney4 Speaker’s Qualifications Greg McChesney is a graduate student at TTU Greg McChesney is planning to graduate in May of 2009 with a Master’s in Computer Science Completed a related project as a feasibility study in Communication Networks Beginning

5. Greg McChesney5 Did you know? There is no network-centric methodology for creating service contexts in the SORCER environment. Beginning

6. Greg McChesney6 Presentation Agenda Background knowledge What is a service context? Discuss why a life-cycle is required Overview of life-cycle Discuss Context Creation Panel Feasibility Study Schedule Beginning

7. Background Knowledge Many different Exertion-Oriented (EO) Systems Implementation based on SORCER –Developed by Texas Tech SORCER Lab –Based on Jini network technology –Framework constantly evolving –Interoperability with existing providers a concern for new development Greg McChesney7

8. All About Contexts A service context is a basic data structure in SOOA Used for communication between provider and requestor (a data exchange contract) A service context depends on the provider and the method being executed Data specification of hierarchical attributes the method will require Stored in a tree like format of path/value Greg McChesney8

9. Sample Context Greg McChesney9 Image courtesy of Dr. Sobolewski

10. Need for a Life-Cycle Two roles –Provider No methodology to obtain a service context from a provider No methodology to interactively create network centric contexts No method of updating or removing a context from a provider –Requestor Greg McChesney10

11. Need for a Life-Cycle –Requestor Exertion-oriented programming cannot be network centric without context management A new service provider - Context Browser will provide more accessibility Need service context editing operations for EO programming Greg McChesney11

12. Proposed Life-Cycle Implement service context editing operations into provider classes –New operations will be remotely invokeable Get- Requestor Save -Admin Delete -Admin Create Context Browser to utilize the methods Greg McChesney12

13. Life-Cycle Explained Context must be: –Stored locally by provider –Reloaded on provider restart –Saved on update/create –Return undefined service context on error Changes must be –Compliant with existing providers –Provide backup file in case of bad context Greg McChesney13

14. Activity Diagram Greg McChesney14

15. Different Components Greg McChesney15

16. Use Case Diagram Context Browser Greg McChesney16

17. Component Diagram Context Browser Greg McChesney17

18. Context Browser UI Component Diagram Greg McChesney18

19. Context Browser Sequence- Viewer Greg McChesney19

20. Context Browser Sequence- Admin Greg McChesney20

21. Context Browser-Class Diagram Greg McChesney21

22. Greg McChesney22 Need for a Exertion Editor No network-centric method for creating context for exertions No network-centric method for reusing a context for exertions No common graphical method of creating exertions with context directly from providers in SORCER –Each provider must have own GUI interface –Users must learn each providers interface Provide easier network-centric development of new services Middle

23. Edit the Context? Why would we want to edit a service context before we launch the exertion? –The service context can often describe input variables that are not static, editing it allows us to change them. –Example: The AccountTester would be useless if you could not specify how much you were depositing or withdrawing. Greg McChesney23

24. Exertion Editor-Use Case Greg McChesney24

25. Exertion Editor-Component Diagram Greg McChesney25

26. Exertion Editor UI-Component Diagram Greg McChesney26

27. Exertion Editor-Sequence Creator Greg McChesney27

28. Exertion Editor- Sequence Submitter Greg McChesney28

29. Exertion Editor-Class Diagram Greg McChesney29

30. Verification & Validation Verification –Is the approach correct –Does it meet the specifications outlined Validation –Does the approach accurately fix the issues set out to address. –Conceptual Validation-Ensure models meet goals –Operational Validation-Ensure implemented model meets goal as intended Greg McChesney30

31. Sargent Circle Greg McChesney31 GroovyShell

32. Feasibility Study Create the Context Browser provider to test Life-Cycle methods –Get Context –Add Context –Update Context –Delete Context Utilize Arithmetic provider to demonstrate the power of the Exertion Editor. Greg McChesney32

33. Greg McChesney

34. 34 Summary Benefits of Exertion Editor –Simplified user interface –Less work for new provider creators In combination with a new Context Editor will provide: –Complete Context Management –Exertion initiation –Ability to use network determine a context End

35. Greg McChesney