Greg McChesneyThesis Defense PresentationComputer Science, TTUGreg.mcchesney@ttu.edu

Service Context Management for Exertion-oriented Programming

Greg McChesney2

Overall Presentation Goal or Primary Purpose

Beginning

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

Greg McChesney3

Proposal Objectives

• As a result of this presentation, you will be able to:– Understand the purpose of service 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– Execute an exertion in SORCER– View a returned exertion context from the

federation

Beginning

Greg McChesney4

Speaker’s Qualifications

• Greg McChesney is a graduate student at TTU• Greg McChesney is planning to graduate in

May of 2009 with a Master’s in Computer Science

• Completed a related project as a feasibility study in Communication Networks

Beginning

Greg McChesney5

Did you know?

There is no network-centric methodology for creating service contexts in the SORCER environment.

Beginning

Greg McChesney6

Presentation Agenda

• Background knowledge• What is a service context?• Discuss why a life-cycle is required• Overview of life-cycle• Discuss Context Creation Panel• Feasibility Study• Schedule

Beginning

Background Knowledge

• Many different Exertion-Oriented (EO) Systems• Implementation based on SORCER

– Developed by Texas Tech SORCER Lab– Based on Jini network technology– Framework constantly evolving– Interoperability with existing providers a concern

for new development

Greg McChesney7

All About 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 McChesney8

Sample Context

Greg McChesney9 Image courtesy of Dr. Sobolewski

Need for a Life-Cycle

• Two roles– Provider

• 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

– Requestor

Greg McChesney10

Need for a Life-Cycle

– Requestor• Exertion-oriented programming cannot be

network centric without context management• A new service provider - Context Browser will

provide more accessibility• Need service context editing operations for

EO programming

Greg McChesney11

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

Greg McChesney12

Life-Cycle Explained

• Context 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 McChesney13

Activity Diagram

Greg McChesney14

Different Components

Greg McChesney15

Use Case Diagram Context Browser

Greg McChesney16

Component Diagram Context Browser

Greg McChesney17

Context Browser UI Component Diagram

Greg McChesney18

Context Browser Sequence- Viewer

Greg McChesney19

Context Browser Sequence- Admin

Greg McChesney20

Context Browser-Class Diagram

Greg McChesney21

Greg McChesney22

Need for a Exertion Editor

• No network-centric method for creating context for exertions

• No network-centric method for reusing a context for exertions

• No common graphical method of creating exertions with context directly from providers in SORCER– Each provider must have own GUI interface– Users must learn each providers interface

• Provide easier network-centric development of new services

Middle

Edit the Context?

• Why would we want to edit a service context before we launch the exertion?– The service context can often describe 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.

Greg McChesney23

Exertion Editor-Use Case

Greg McChesney24

Exertion Editor-Component Diagram

Greg McChesney25

Exertion Editor UI-Component Diagram

Greg McChesney26

Exertion Editor-Sequence Creator

Greg McChesney27

Exertion Editor- Sequence Submitter

Greg McChesney28

Exertion Editor-Class Diagram

Greg McChesney29

Verification & Validation

• Verification– Is the approach correct– Does it meet the specifications outlined

• Validation– Does the approach accurately fix the issues set

out to address.– Conceptual Validation-Ensure models meet

goals– Operational Validation-Ensure implemented

model meets goal as intended

Greg McChesney30

Sargent Circle

Greg McChesney31

GroovyShell

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.

Greg McChesney32

Greg McChesney

Greg McChesney34

Summary

• Benefits of Exertion Editor– Simplified user interface– Less work for new provider creators

• In combination with a new Context Editor will provide:– Complete Context Management– Exertion initiation – Ability to use network determine a context

End

Greg McChesney