Service Context Management for Exertionoriented Programming Greg Mc

Service Context Management for Exertionoriented Programming Greg Mc. Chesney Thesis Defense Presentation Computer Science, TTU greg. mcchesney@ttu. edu

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

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

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

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 Beginning 5 Greg Mc. Chesney

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 6 Greg Mc. Chesney

Sample Context 7 Greg Mc. Chesney Image courtesy of Dr. Sobolewski

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 8 Greg Mc. Chesney

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 9 Greg Mc. Chesney

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 10 Greg Mc. Chesney

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 11 Greg Mc. Chesney

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 12 Greg Mc. Chesney

Activity Diagram 13 Greg Mc. Chesney

Different Components Provider. List Interface. Browser Context. Editor Control. Panel 14 Greg Mc. Chesney

Context Browser-Use Case 15 Greg Mc. Chesney

Exertion Editor-Use Case 16 Greg Mc. Chesney

Context Browser- Architecture Diagram 17 Greg Mc. Chesney

Context Browser UI- Architecture Diagram 18 Greg Mc. Chesney

Exertion Editor UI- Architecture Diagram 19 Greg Mc. Chesney

Context Browser Sequence. Viewer 20 Greg Mc. Chesney

Context Browser Sequence. Admin 21 Greg Mc. Chesney

Exertion Editor-Sequence Creator 22 Greg Mc. Chesney

Exertion Editor- Sequence Submitter 23 Greg Mc. Chesney

24 Greg Mc. Chesney

25 Greg Mc. Chesney

Sargent Circle Requirements Check Requirements to Models Check Implementation to Requirements Groovy. Shell Data Validity Implementation 26 Greg Mc. Chesney UML Modeling Check Implementation to Models

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 27 Greg Mc. Chesney

Technical Architecture Context Browser Exertion Editor Utilities and Templates Requestor Service UIs Web Exertion Based Clients Intraportal Extraportal Infrastructure Providers Jobber, Tasker, Spacer , Grider, Caller, Methoder, Cataloger, Notifier, Logger, Reporter, Authenticator, Authorizer, Auditor, Policer, Key. Storer, Surrogater, Persister, File. Storer, SILENUS, FICUS SORCER Core Servicer, Service. Provider. Bean Exertion. Delegate, Service. Accessor Persistence File Store J 2 EE, Jini, Rio, GApp Context Management 28 Greg Mc. Chesney Provisioning and Activation Exertion Layer

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 29 Greg Mc. Chesney

Deployment 30 Greg Mc. Chesney

Demonstration Greg Mc. Chesney

Demonstration 32 Greg Mc. Chesney

Selecting a provider 33 Greg Mc. Chesney

Add New Provider 34 Greg Mc. Chesney

Modifying a context 35 Greg Mc. Chesney

• Supported Data Types – – – – 36 String Boolean Integer Double Float Groovy Expression URL Greg Mc. Chesney

37 Greg Mc. Chesney

• Directions-control if the path is marked for a particular operation – Default – Input – Output – In. Output 38 Greg Mc. Chesney

Functions Provided 39 Greg Mc. Chesney

Functions Provided 40 Greg Mc. Chesney

Functions Provided 41 Greg Mc. Chesney

Result of Exerting a Service 42 Greg Mc. Chesney

Groovy Expressions 43 Greg Mc. Chesney

Result of Groovy Expression 44 Greg Mc. Chesney

Integrated Exertion Editor 45 Greg Mc. Chesney

Utilize Default Editors 46 Greg Mc. Chesney

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 47 Greg Mc. Chesney

Greg Mc. Chesney

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. 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/prothhpcc. ppt> 49 Greg Mc. Chesney

Greg Mc. Chesney