Download presentation
Presentation is loading. Please wait.
Published byFrancis Morton Modified over 9 years ago
1
Greg McChesney Thesis Defense Presentation Computer Science, TTU greg.mcchesney@ttu.edu Service Context Management for Exertion- oriented Programming
2
Greg McChesney2 Presentation Agenda Problem Statement Objective Background knowledge Design Verification and Validation Implementation Demonstration Benefits Beginning
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
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
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
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
7
Sample Context Greg McChesney7 Image courtesy of Dr. Sobolewski
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
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 McChesney9
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 McChesney10
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
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 McChesney12
13
Activity Diagram Greg McChesney13
14
Different Components Greg McChesney14 ProviderListInterfaceBrowserContextEditor ControlPanel
15
Context Browser-Use Case Greg McChesney15
16
Exertion Editor-Use Case Greg McChesney16
17
Context Browser- Architecture Diagram Greg McChesney17
18
Context Browser UI- Architecture Diagram Greg McChesney18
19
Exertion Editor UI- Architecture Diagram Greg McChesney19
20
Context Browser Sequence- Viewer Greg McChesney20
21
Context Browser Sequence- Admin Greg McChesney21
22
Exertion Editor-Sequence Creator Greg McChesney22
23
Exertion Editor- Sequence Submitter Greg McChesney23
24
Greg McChesney24
25
Greg McChesney25
26
Sargent Circle Greg McChesney26 GroovyShell Implementation Check Implementation to Models Check Implementation to Requirements Data Validity UML Modeling Check Requirements to Models Requirements
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
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
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
30
Deployment Greg McChesney30
31
Greg McChesney Demonstration
32
Greg McChesney32
33
Selecting a provider Greg McChesney33
34
Add New Provider Greg McChesney34
35
Modifying a context Greg McChesney35
36
Supported Data Types –String –Boolean –Integer –Double –Float –Groovy Expression –URL Greg McChesney36
37
Greg McChesney37
38
Directions-control if the path is marked for a particular operation –Default –Input –Output –InOutput Greg McChesney38
39
Functions Provided Greg McChesney39
40
Functions Provided Greg McChesney40
41
Functions Provided Greg McChesney41
42
Result of Exerting a Service Greg McChesney42
43
Groovy Expressions Greg McChesney43
44
Result of Groovy Expression Greg McChesney44
45
Integrated Exertion Editor Greg McChesney45
46
Utilize Default Editors Greg McChesney46
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
48
Greg McChesney
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
50
Greg McChesney
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.