Slide 1

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

Slide 2

Greg McChesney2 Presentation Agenda Problem Statement Objective Background knowledge Design Verification and Validation Implementation Demonstration Benefits Beginning

Slide 3

Greg McChesney3 Problem Statement Beginning 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

Slide 4

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

Slide 5

Greg McChesney5 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

Slide 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 McChesney6

Slide 7

Sample Context Greg McChesney7 Image courtesy of Dr. Sobolewski

Slide 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 McChesney8

Slide 9

Need for a Life-Cycle Providers 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 McChesney9

Slide 10

Need for a Life-Cycle Requestors 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 McChesney10

Slide 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 McChesney11

Slide 12

Life-Cycle Explained Contexts 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 McChesney12

Slide 13

Activity Diagram Greg McChesney13

Slide 14

Different Components Greg McChesney14 ProviderListInterfaceBrowserContextEditor ControlPanel

Slide 15

Context Browser-Use Case Greg McChesney15

Slide 16

Exertion Editor-Use Case Greg McChesney16

Slide 17

Context Browser- Architecture Diagram Greg McChesney17

Slide 18

Context Browser UI- Architecture Diagram Greg McChesney18

Slide 19

Exertion Editor UI- Architecture Diagram Greg McChesney19

Slide 20

Context Browser Sequence- Viewer Greg McChesney20

Slide 21

Context Browser Sequence- Admin Greg McChesney21

Slide 22

Exertion Editor-Sequence Creator Greg McChesney22

Slide 23

Exertion Editor- Sequence Submitter Greg McChesney23

Slide 24

Greg McChesney24

Slide 25

Greg McChesney25

Slide 26

Sargent Circle Greg McChesney26 GroovyShell Implementation Check Implementation to Models Check Implementation to Requirements Data Validity UML Modeling Check Requirements to Models Requirements

Slide 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 McChesney27

Slide 28

Technical Architecture Greg McChesney28 Utilities and TemplatesWeb Exertion Based Clients RequestorService UIsIntraportalExtraportal Infrastructure Providers Jobber, Tasker, Spacer, Grider, Caller, Methoder, Cataloger, Notifier, Logger, Reporter, Authenticator, Authorizer, Auditor, Policer, KeyStorer, Surrogater, Persister, FileStorer, SILENUS, FICUS Persistence Provisioning and Activation File StoreExertion Layer J2EE, Jini, Rio, GApp SORCER Core Servicer, ServiceProvider, ServiceProviderBean ExertionDelegate, ServiceAccessor Exertion Editor Context Management Context Browser

Slide 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 McChesney29

Slide 30

Deployment Greg McChesney30

Slide 31

Greg McChesney Demonstration

Slide 32

Greg McChesney32

Slide 33

Selecting a provider Greg McChesney33

Slide 34

Add New Provider Greg McChesney34

Slide 35

Modifying a context Greg McChesney35

Slide 36

Supported Data Types String Boolean Integer Double Float Groovy Expression URL Greg McChesney36

Slide 37

Greg McChesney37

Slide 38

Directions-control if the path is marked for a particular operation Default Input Output InOutput Greg McChesney38

Slide 39

Functions Provided Greg McChesney39

Slide 40

Functions Provided Greg McChesney40

Slide 41

Functions Provided Greg McChesney41

Slide 42

Result of Exerting a Service Greg McChesney42

Slide 43

Groovy Expressions Greg McChesney43

Slide 44

Result of Groovy Expression Greg McChesney44

Slide 45

Integrated Exertion Editor Greg McChesney45

Slide 46

Utilize Default Editors Greg McChesney46

Slide 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 McChesney47

Slide 48

Greg McChesney

Slide 49

References Design Patterns: Model-View-Controller. Java.sun.com. 01 Jan 2002. 20 Oct. 2008 Sobolewski, Michael. SORCER Research. SORCER Research Lab at TTU. 20 Oct. 2008. 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. Soorianarayanan, Sekar and Sobolewski, Michael. SORCER Proth. Slide 6. Greg McChesney49

Slide 50

Greg McChesney