Greg McChesney Thesis Defense Presentation Computer Science,
TTU [email protected] 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
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
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
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