Greg McChesney Thesis Defense Presentation Computer Science, TTU greg.mcchesney@ttu.edu

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

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