1 / 50

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

Service Context Management for Exertion-oriented Programming. Greg McChesney Thesis Defense Presentation Computer Science, TTU greg.mcchesney@ttu.edu. Presentation Agenda. Problem Statement Objective Background knowledge Design Verification and Validation Implementation Demonstration

abla
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related