Transcript of Greg McChesney Thesis Defense Presentation Computer Science, TTU greg.mcchesney@ttu.edu Service...
- 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