Upload
patty
View
36
Download
0
Tags:
Embed Size (px)
DESCRIPTION
Service Context Management for Exertion-oriented Programming. Greg McChesney Thesis Defense Presentation Computer Science, TTU [email protected]. Presentation Agenda . Problem Statement Objective Background knowledge Design Verification and Validation Implementation Demonstration - PowerPoint PPT Presentation
Citation preview
Greg McChesneyThesis Defense PresentationComputer Science, [email protected]
Service Context Management for Exertion-oriented Programming
Greg McChesney2
Presentation Agenda
• Problem Statement• Objective• Background knowledge• Design• Verification and Validation• Implementation• Demonstration• Benefits
Beginning
Greg McChesney3
Problem Statement
Beginning
• Problemo No full life-cycle for context management
in exertion-oriented programmingo The current Cataloger service does not
sufficiently display context detailso No service UI context editor for
interactive exertion-oriented programming
o No standard service UI for all providers
Greg McChesney4
Problem Statement
Beginning
• Conclusiono A life-cycle context management is
needed.o Life-cycle must support:
• Creating Contexts• Updating Contexts• Deleting Contexts
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
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
Sample Context
Greg McChesney7 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
Greg McChesney8
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
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
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
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
Activity Diagram
Greg McChesney13
Different Components
Greg McChesney14
ProviderList InterfaceBrowser ContextEditor
ControlPanel
Context Browser-Use Case
Greg McChesney15
Exertion Editor-Use Case
Greg McChesney16
Context Browser- Architecture Diagram
Greg McChesney17
Context Browser UI- Architecture Diagram
Greg McChesney18
Exertion Editor UI- Architecture Diagram
Greg McChesney19
Context Browser Sequence- Viewer
Greg McChesney20
Context Browser Sequence- Admin
Greg McChesney21
Exertion Editor-Sequence Creator
Greg McChesney22
Exertion Editor- Sequence Submitter
Greg McChesney23
Greg McChesney24
Greg McChesney25
Sargent Circle
Greg McChesney26
GroovyShell
Implementation
Check Implementation to Models
Check Implementation to Requirements
Data Validity
UML Modeling
Check Requirements to
Models
Requirements
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
Technical Architecture
Greg McChesney28
Utilities and Templates Web Exertion Based Clients
Requestor Service UIs Intraportal Extraportal
Infrastructure ProvidersJobber, Tasker, Spacer , Grider, Caller, Methoder, Cataloger, Notifier, Logger,
Reporter, Authenticator, Authorizer, Auditor, Policer, KeyStorer, Surrogater, Persister, FileStorer, SILENUS, FICUS
Persistence Provisioning and Activation
File Store Exertion Layer
J2EE, Jini, Rio, GApp
SORCER CoreServicer, ServiceProvider,
ServiceProviderBeanExertionDelegate, ServiceAccessor
Exertion Editor
Context Management
Context Browser
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
Deployment
Greg McChesney30
Greg McChesney
Demonstration
Demonstration
Greg McChesney32Context Browser
Selecting a provider
Greg McChesney33
Select Provider
Add New Provider
Greg McChesney34
New providers appear without disrupting the user
Modifying a context
Greg McChesney35
Double click a data node to edit
• Supported Data Types– String– Boolean– Integer– Double– Float– Groovy Expression– URL
Greg McChesney36
Greg McChesney37
Double click a path to edit
• Directions-control if the path is marked for a particular operation– Default– Input– Output– InOutput
Greg McChesney38
Functions Provided
Greg McChesney39
Adds a new path
Adds a new data node
Removes currently selected
item
Functions Provided
Greg McChesney40
Empties the Context
Gives user option to load another saved
context
Provides user a method to remove
contexts
Functions Provided
Greg McChesney41
Save this context
Save this context as a different name
Exert the service and output result
context
Result of Exerting a Service
Greg McChesney42
Output context from exertion
Groovy Expressions
Greg McChesney43
Enter expression in terms of arithmetic0’s value
Result of Groovy Expression
Greg McChesney44
Output of the math operation
Integrated Exertion Editor
Greg McChesney45
New provider echo has no user interface
Utilize Default Editors
Greg McChesney46
Exertion Editor is now available for each provider
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
Greg McChesney
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/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/proth-hpcc.ppt>
Greg McChesney49
Greg McChesney