Greg McChesney Thesis Defense Presentation Computer Science, TTU greg.mcchesney@ttu

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

2. Presentation Agenda • Problem Statement • Objective • Background knowledge • Design • Verification and Validation • Implementation • Demonstration • Benefits Greg McChesney Beginning

3. Problem Statement • Problem • No full life-cycle for context management in exertion-oriented programming • The current Cataloger service does not sufficiently display context details • No service UI context editor for interactive exertion-oriented programming • No standard service UI for all providers Greg McChesney Beginning

4. Problem Statement • Conclusion • A life-cycle context management is needed. • Life-cycle must support: • Creating Contexts • Updating Contexts • Deleting Contexts Greg McChesney Beginning

5. Thesis Objectives • Create a life-cycle to manage contexts • Provide service UI to allow for interactive exertion-oriented programming • Ease new provider development in SORCER • Provide a common framework for Context modifications • Minimize the modifications required to existing providers Greg McChesney Beginning

6. Overview of 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 McChesney

7. Sample Context Image courtesy of Dr. Sobolewski Greg McChesney

8. Roles In SOOA • Two roles • Provider-provides a service to the network • The service can be requested via an exertion • Provider expects a context from the requestor with arguments for the method. • Requestor- is the client who connects to the provider • Requestor creates exertion which is sent to provider • Requestor must send context in a structure provider will understand Greg McChesney

9. Need for a Life-Cycle • Provider’s Issues • 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 Greg McChesney

10. Need for a Life-Cycle • Requestor’s Issues • Exertion-oriented programming cannot be network centric without context management • Two new service UIs - Context Browser in Cataloger Service UI and in Exertion Editor will provide more accessibility • Need service context editing operations for EO programming Greg McChesney

11. 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 • Create Exertion Editor which will allow for service context and exertion creation Greg McChesney

12. Life-Cycle Explained • Context’s 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 McChesney

13. Activity Diagram Greg McChesney

14. Different Components ProviderList InterfaceBrowser ContextEditor ControlPanel Greg McChesney

15. Context Browser-Use Case Greg McChesney

16. Exertion Editor-Use Case Greg McChesney

17. Context Browser- Architecture Diagram Greg McChesney

18. Context Browser UI- Architecture Diagram Greg McChesney

19. Exertion Editor UI- Architecture Diagram Greg McChesney

20. Context Browser Sequence- Viewer Greg McChesney

21. Context Browser Sequence- Admin Greg McChesney

22. Exertion Editor-Sequence Creator Greg McChesney

23. Exertion Editor- Sequence Submitter Greg McChesney

24. Greg McChesney

25. Greg McChesney

26. Sargent Circle Requirements Check Requirements to Models Check Implementation to Requirements GroovyShell Data Validity Implementation UML Modeling Check Implementation to Models Greg McChesney

27. Implementation to Validate Model • Implementation is based on SORCER • Developed by Texas Tech SORCER Lab • SORCER is based on Jini network technology • Framework constantly evolving • Interoperability with existing providers a concern for new development Greg McChesney

28. Technical Architecture Context Browser Exertion Editor Utilities and Templates Web Exertion Based Clients Requestor Service UIs Intraportal Extraportal Infrastructure Providers Jobber, Tasker, Spacer, Grider, Caller,Methoder, Cataloger, Notifier, Logger, Reporter, Authenticator, Authorizer, Auditor, Policer, KeyStorer,Surrogater, Persister, FileStorer,SILENUS, FICUS SORCER Core Servicer, ServiceProvider, ServiceProviderBean ExertionDelegate, ServiceAccessor Persistence Provisioning and Activation File Store Exertion Layer J2EE, Jini, Rio, GApp Context Management Greg McChesney

29. 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. • Address new provider development with integrated user interfaces Greg McChesney

30. Deployment Greg McChesney

31. Demonstration Greg McChesney

32. Demonstration Context Browser Greg McChesney

33. Selecting a provider Select Provider Greg McChesney

34. Add New Provider New providers appear without disrupting the user Greg McChesney

35. Modifying a context Double click a data node to edit Greg McChesney

36. Supported Data Types • String • Boolean • Integer • Double • Float • Groovy Expression • URL Greg McChesney

37. Double click a path to edit Greg McChesney

38. Directions-control if the path is marked for a particular operation • Default • Input • Output • InOutput Greg McChesney

39. Functions Provided Removes currently selected item Adds a new path Adds a new data node Greg McChesney

40. Functions Provided Provides user a method to remove contexts Gives user option to load another saved context Empties the Context Greg McChesney

41. Functions Provided Exert the service and output result context Save this context as a different name Save this context Greg McChesney

42. Result of Exerting a Service Output context from exertion Greg McChesney

43. Groovy Expressions Enter expression in terms of arithmetic0’s value Greg McChesney

44. Result of Groovy Expression Output of the math operation Greg McChesney

45. Integrated Exertion Editor New provider echo has no user interface Greg McChesney

46. Utilize Default Editors Exertion Editor is now available for each provider Greg McChesney

47. Benefits • Uniform service context tracking by providers • Uniform method context viewer and editor for service providers • Intuitive Service UI for Cataloger service contexts per provider/interface method • Intuitive Service UI for task service context Greg McChesney

48. Greg McChesney

49. References • “Design Patterns: Model-View-Controller.” Java.sun.com. 01 Jan 2002. 20 Oct. 2008 <http://java.sun.com/blueprints/patterns/MVC.html> • Sobolewski, Michael. “SORCER Research.” SORCER Research Lab at TTU. 20 Oct. 2008. <http://sorcer.cs.ttu.edu/fiper/fiper.html> • Sargent, R. G. Verification, Validation, and Accreditation of Simulation Models. (J. A. Joines, R. R. Barton, K. Kang, & P. A. Fishwick, Eds.) • Sobolewski, Michael. “Exertion Oriented Programming.” Page 19. <http://sorcer.cs.ttu.edu/publications/papers/2008/SL-TR-13.pdf> • Soorianarayanan, Sekar and Sobolewski, Michael. SORCER Proth. Slide 6. <http://sorcer.cs.ttu.edu/publications/presentations/proth-hpcc.ppt> Greg McChesney

50. Greg McChesney