Greg McChesney

1
Service Context Management for Exertion-oriented
Programming

• Greg McChesney
• Thesis Proposal Presentation
• Computer Science, TTU
• Greg.mcchesney_at_ttu.edu

2
Overall Presentation Goal or Primary Purpose

• Create a life-cycle for context management in
  Exertion Oriented Programming

Beginning
3
Learning Objectives

• As a result of this presentation, you will be
  able to
• Understand the purpose of contexts
• Understand why a life-cycle is required
• Utilize the life-cycle for your SORCER projects
• Create a context in SORCER
• Modify a context in SORCER
• Launch a service in SORCER
• View returned context from the service

Beginning
4
Speakers Qualifications

• Greg McChesney is a graduate student at TTU
• Greg McChesney is planning to graduate in May of
  2009 with a Masters in Computer Science
• Greg McChesney thesis is on Cataloger and
  creating contexts and jobs in SORCER

Beginning
5
Did you know?
There is no method for creating dynamic Contexts,
Tasks, or Jobs in the SORCER environment.
Beginning
6
Presentation Agenda

• Background Knowledge
• What is a Context?
• Discuss why a life-cycle is required
• Overview of life-cycle
• Discuss Task Editor
• Feasibility Study
• Demo
• Schedule

Beginning
7
Background Knowledge

• Many different Exertion-Oriented Systems
• Implementation based on SORCER
• Created by Mike Sobolewski in 2002
• Based on JINI services
• Framework constantly evolving
• Interoperability with existing providers a
  concern for new development

8
All About Contexts

• A Context is a set of instructions for a
  provider.
• The context various depending on the provider and
  the method being executed.
• Contexts can specify anything about a provider
• Example
• The context for makeDeposit in the AccountTester
  is deposit/amountamount

9
Sample Context
Image courtesy of Dr. Sobolewski
10
Need for a Life-Cycle

• No method to dynamically create Contexts
• No method of updating or removing Contexts
• Exertion-oriented programming cannot be dynamic
  without Context management
• Updated Cataloger will provide more accessibility
• Need Context methods for a task-editor

11
Proposed Life-Cycle

• Implement Context Methods into provider classes
• New methods will be remotely invokeable
• Get
• Create
• Update
• Delete
• Update Cataloger to utilize new methods

12
Life-Cycle Explained

• Context must be
• Stored locally by provider
• Reloaded on provider restart
• Saved on update/create
• Return blank when none is found
• Changes must be
• Compliant with existing providers
• Provide backup file in case of bad context

13
Use Case Diagram Cataloger
14
Component Diagram Cataloger
15
Cataloger UI Component Diagram
16
Need for a Task Editor

• No common graphical method of creating tasks in
  SORCER
• Each provider must have own GUI interface
• Users must learn each providers interface
• Provide easier development of new services
• No method for creating Jobs
• No method for saving and reusing Jobs.

Middle
17
Edit the Context?

• Why would we want to edit the Context before we
  launch the Task?
• The Context can often described input variables
  that are not static, editing it allows us to
  change them.
• Example The AccountTester would be useless if
  you could not specify how much you were
  depositing or withdrawing.

18
Output of the Task

• Tasks return a Context for their output
• In the case of a simple Task the output is
  returned the user
• In a Job the output is used as input for the next
  Task

19
Use Case-Task Manager
20
Component Diagram-Task Manager
21
Task Manager UI Component Diagram
22
Feasibility Study

• Update Cataloger to test Life-Cycle methods
• Get Context
• Add Context
• Update Context
• Delete Context
• Utilize provider from Air Force Research Center
  (Mealstrom) to validate task manager works as
  intended

23
(No Transcript)
24
Summary

• Benefits of Task Creation Panel
• Simplified user interface
• Less work for new provider creators
• In combination with new Cataloger will provide
• Complete Context Management
• Task Initiation
• Job Initiation

End
25
Schedule

• Literature Review
• System Requirements
• Life-Cycle context management model
• Architecture and detailed design
• LCSM prototype
• Thesis proposal presentation
• Framework Implementation-End Of February
• Validation of Use Cases and deployment-Early
  March
• Thesis Defense- Mid March

26
(No Transcript)