SORCER: Service-oriented Platform - PowerPoint Presentation

Slide1

SORCER: Service-oriented Platform

Mike Sobolewski

sobol@sorcersoft.orghttp://sorcersoft.org/sobol

Slide2

Outline

Transdisciplinary ComputingPhysics Based Distributed Collaborative DesignService-orientation & SORCER ArchitectureService-oriented Mogramming (SML)Exertion-Oriented Language (EOL)Context Modeling Language (CML)

Agility vs. Amorphousness in SORCERFSO SDLC

Slide3

The Next 100 Years

The computer is the network. ⇒ The network is the computer => The service cooperation is the computer.

adaptive enterprise

IoT

SOOA,

FIPER

SPOA,

GApp portals, Agile CWWW, SOA, CAMNet

C/S, CE, DICEtalk OO, DPL, UML chips, OSs

computing sciences solid-sate physics information theory

INFORMATION/

DIGITAL

virtualization, provisioning, blockchain

spintronics, quantum computing

nanotech, MEMS

SERVICE/MOLECULAR

SORCER mFi SOA, SML TST/TADO FIPER

SaaSDaaSPaaSIaaSBaaSEaaSEaaaaSY

1800

Stage 1

Research

(Conception)

Stage 2

Early Adopters

(Growth)

Stage 3

Public Recognition

(Maturity)

Stage 4

Mass Adoption(Saturation)

ECONOMIC VALUE ADDED

DEVELOPMENT

POST

1900

2000

2100

INDUSTRIAL

CRISPR

Slide4

Transdisciplinary Processes

1/1/20

Mike Sobolewski

Data

Control

Strategies

Solutions

Operations

Services

: data, operations, control strategies, and solutions (

request/result)

Request Service

Transdisciplinary

Interdisciplinary

Multidisciplinary

Script/Result

Static

Dynamic

Command/Result

Discipline

Transdisciplinarity: An adaptive strategy that crosses many virtual disciplinary boundaries to create seamlessly a holistic approach to dynamic complex system.Morphing Expression at RuntineMorphing Actualization at RuntimeProvider Services

Slide5

5

NAT

TCP/IP

Physical

Network

HTTP

Prv

Prv

Prv

Prv

Prv

Prv

Prv

Prv

Virtual Request Network

Req

Req

ReqReqReqReqReqVirtual Provider Network OOOverlayNetworkSOOverlayNetworkSMLJavaExecCodesProvisioningMultitypingSO Overlay Network

Slide6

Virtual Network of Services (S2S)

6

NAT

Virtual Mapping

TCP/IP

Physical

Network

HTTP

Virtual/Overlay Network

Srv

Srv

Srv

Srv

Srv

Srv

Srv

Srv

Service (Srv) as remote/local object -> OO applied to the network

Slide7

Geographic Location B

Geographic Location A

Geographic Location C

.

.

.

.

.

.

New Process Steps (BCA):

Increase Disciplines & Coupling

Increase Fidelity

Leverage All Compute Resources

Physics Based Distributed Collaborative Design

Dialable

Fidelity

Empirical

Linear Potential

Euler

NS

Design Process Vision

Slide8

S1,2

e

1,1

N

3

Diagram

m

1

e

6,1

m2,2

m

3,1

[g: e

1,2;

e6,3]e6,*(e1,2(mx), m1(e1,1, my,2), m3,1(e1,1, ez,2, et))

g

…

…

N3

0truem2,2my,1etmxN31N32,2ez,1N32,1

Slide9

Physics Based Distributed Collaborative Design (Organizational View)

Vehicle

Aerodynamics

Flight Control

Aerospace

Propulsion

Rocket

Propulsion

Aerospace

Structures

Turbine

Engine

Power

We are silos and there is a good reason to keep it that way

People, Tech.,

Data, & Tools

As Needed Real Time Access

to Applications & Data by ALL Communities

Distributed Collaborative Design!

Good “Community Members” Publish Information for Collaborators

OVDesign Study X

Slide10

Language – MankindWriting – Civilization

Tortoise shells

Quipu

Cuneiform script

Movable metal type, and composing stick, descended from Gutenberg's press

Tărtăria tablets

Network

Slide11

Front-end vs. Back-end Programming

Language engineering is the art of creating languages

SORCER

Transform

Incorporate

Problem Domain

Runtime Domain

Solution Domain

DSLs

EOL

PML

VML

API

Agents

SWLs

JavaScriptsC, C++Fortranetc./Exec Codes

Mograms

Express

Aerospace

Slide12

Client/Server

Client

Server

A client can use (as is)

but cannot reconfigure a server(to be).

Slide13

Requestor/Provider

Requestor

Provider

A requestor can use a provider as to be.

SO is about configuring and managing providers.

Requestor Service

Query

Call

Question

Request

Provider Service

Reply

Result

Answer

Response

Slide14

Model vs. Program

Modeling Language

Programming Language

Imprecise

Precise

Not executable

Executable

Overview

Detailed view

High level

Low level

Textual/Visual

Textual

Informal semanticsExecution semanticsBy-product

Core product

Perceived differences between Modeling and Programming Languages.How should the product written in SW language be named?Model, program, query, or data definition, or any other word?

Slide15

Mogramming: Modeling/Programming

Mogram: a concept that includes programs, models, and other things.

Kleppe A., 2009. Software Language Engineering, Pearson Education

Slide16

Service-orientation Restictions

Stupid networkStatic connectivity

Slide17

Operation and Request Services

Operation Service

Service Provider

net-centric action

Combined

Request Service

Service Provider Partnership

combined net-activity

Elementary

Request Service

Service Provider

elementary net-activity

Client

Requestor

Server

Provider

execute

Slide18

Request Services

args

args

Call

Message

Request Service

Subroutines

Local Objects

Service Providers

Local/Remote ATUs

UML Model

SML

Mogram

Front End

API

Instructions of subroutines are concatenated statically.

Objects collaborations are interconnected statically.

Autonomous net/local service providers cooperate dynamically as specified by request services.

Back

End

ATUMethodScalabilityATU

Slide19

OS Roles

UA

args

Command

Clients

Mogram

(exertion/model)

Exec Codes

Servers

Local/Remote Services

Front End

Provider services are autonomous net/local software components

assembled at runtime.

SOA requires a registry for provider services.

Back

End

Script

OS

WB

Slide20

Complexity => Dependency Management

args

args

Call

Message

Mogram

(exertion/model)

Subroutine

Local Objects

Local/Remote Services

UML Model

SML

Model

Front End

API

Back

End

Object

Method

Managing Dependencies

Slide21

Service Contextion &

OpservicesInput Context

Output ContextValues

Files

DBs

Exec Codes

Evaluators

Providlets

Signatures

Setters

Getters

Connectors

Appenders

Contextion

Service

Contexts

Entry

Task

Slide22

Metamodel Hierarchy of the MOF/MSF

MOF

EBNF

Groovy

Gradle

SORCER Model

Java

UML

SORCER Project

SORCER Runtime

SML

Request Service

Netlet

MSF

Service Processor

M3

M2

M1

M0

<<

instanceOf>><<instanceOf>><<instanceOf>><<instanceOf>><<instanceOf>><<instanceOf>><<instanceOf>><<instanceOf>><<instanceOf>><< instanceOf>><< instanceOf>><<instanceOf>>Process Expression => Process Actualization

Slide23

Process Expression vs. Actualization

Service System

SMLExertionEOLContext ModelCMLMogram

EOL/CML

Service OS

Processor

Mogram

Language

Service Federation

OS

Actualization

Expression

Signatures/Entries

IS

Slide24

Expression vs. Actualization

1/1/20

24ProcessPlatform

Language

Machine

Grammar

Metamodel

Processor

Actualization

Expression

Instructions

Executable Codes

Execution

OS

EBNF

UML, SML

PE

Slide25

Service Orientation

1/1/20

25SW ATUs aren’t just things. They are servants. A software ATU is considered as a physical manifestation of a service or set of services - service avatar.Services map to increasingly demanding customer preferences, so companies must find ways to make them more granular, as well easier to bundle with other services.

Consumers want services to be convenient for them to create own service cooperation reflecting their experiences at runtime

–

creativity, innovation.

Producers

Providers

Opservices

ATUs

Customers

Consumers

Provisioning

Binding

SW Development

DistributionRequest Service

Slide26

Everything AWAT as a Service for You (EaaaaSY)

SORCER (FSOP, SML = CML + EOL)Service requestorsService models (exertions/context models)Service federations

Collaborative local/remote service providersMADO calculatorJava (OOP)Service types (services)Local/remote objectsLegacy code (executable codes)Apps, Tools, Utilities

Slide27

Why Do We Need Service Systems?

1/1/20

Mike Sobolewski

27

What works with small units often does not scale well to larger sizes

From automation to autonomy

From remote to federated (dynamically integrated)

From low to high fidelity

From task oriented to goal oriented (collaboration)

From deterministic to nondeterministic federations

From established to continuously adaptable systems

From code complexity to logic complexity due to adaptivity

Slide28

From Node to Interactional Fidelity

Interactions among software agents represented by network diagramInformation transfer between entities via data- or state-sharing alters nodesAdaptation within the system occurs as node-states change by interactions“Few-node systems” have dynamics that are driven by node models

“Many-node system” dynamics largely result from interactions among nodesAs the number of possible system adaptations increases, the logic of all possible interactions exceeds what can be understood or analyzedSimple V&V-able nodes can still lead to complex non-V&V-able systemHigh-level languages with the relevant granularity are neededModel fidelity of individual nodes is less important than fidelity of links

Many-node System

Few-node System

Slide29

Transdisciplinary Engineering

1/1/20

Mike Sobolewski

Many-node System

Netlet

/Result

Transdisciplinary

Static

Dynamic

Reconfigure Everything

Front End

Back End

Autonomic

Provisioning

Slide30

Architecting Software to Enable V&V

Complex adaptive systems will have many-node network structures

Can the network structure underlying a CAS be architected to enable V&V? Use hierarchical approach to do V&V at each level of system aggregation Highly distributed structures cannot be effectively aggregated to allow V&V System must be designed from outset to achieve needed hierarchical form “Design for V&V-ability”

is not done today

; it may be a key for future CAS

Granularity at each level must be fine enough to permit

clustered

modeling (entries and signatures)

Limits of clustered model fidelity will introduce uncertainty in V&V results

Not the largest source of uncertainty

Hierarchical System

Distributed System

Slide31

DMC

Metamodeling Architecture

generalization

composition

c, m, s socket

use

V1, V2, V3, V4, V5, V6

- virtualizations

Servicer Provider

(net centricity)

Services

Service OS

Service

Processor

Data

Context

Service Shell

Exert Processor

Service Platform

(service-orientation)

Exertion(programming)Object Platform (object-orientation)CommandsOS IS ProcessorsmEGS-FidelitiesVar (composite evaluation)EvaluationCompositionEvaluationManagerSrv/Par/EntAssociationsResponseManagerInvocationProcessorContext-Model (modeling)Service TypesControl Flow ManagerService BeansOperationQoSService TypeSignature (QoS)AttributesMethodsObject (state)ClassifiersMessagesOO OSObjectProcessorV1 V4 V2 V3 IS Platform(computation)DataControl StrategyObject CodesExec CodeVar/Srv/Par/Ent AssociationsResponseManagerEvaluationProcessorVar-Model (modeling)cclassV5 Srv/Par (invocation)InvocationFidelitiesInvocationCompositionInvocationManagerV6 FMIFMI

Slide32

Service Orientation => Mograms

Slide33

From Objects to Services

Mogram

Model

Service

Exertion

OO Program

Field

Object

Method

Imperative

Programming

Functional

Programming

Object

orientation

Slide34

Metamodel Conceptualization

State/Method Service

ServicesObjects MogramsPrimitives

Context Models

Exertions

Entries

Signatures

Functions

Provider references

Data associations

Provider federations

Data Contexts

Functional associationsAutonomous components

ProvidersActualization services

Slide35

Services => Mograms

Slide36

Service Signatures => Microservices=> Provider Services

Slide37

SML Metamodel Generalizations

execute(Service) : Object

provider(Signature) : Objectvalue(Entry) : Object

context

(Mogram) :

Context

exert

(Mogram) :

Mogram

value

(Context, <

entry-name>) : ObjectObject

State/Method Service

Data Service

Elementary Service

Compound Service

Slide38

SML Operators

Service

execsigprvent

mod

exert/value/

cxt

/

stgy

get/put/add/

rm

cxt

xrtpar

srvvartask

blockjob

mog

ins/outs/response

black – declarative operators

green – operational operators

value/

asis

Slide39

Hello Arithmetic Model

1/1/20

Mike Sobolewski

39

Model m =

srvModel

(


inEnt

(

"multiply/x1"

, 10.0),

inEnt("multiply/x2", 50.0), inEnt("add/x1", 20.0), inEnt("add/x2"

, 80.0),
 ent(sig("multiply", Multiplier.class, result

("multiply/out",
 inPaths("multiply/x1", "multiply/x2")))),


ent(

sig("add", Adder.class, result("add/out”, inPaths("add/x1", "add/x2")))),
 ent(sig("subtract", Subtractor.class, result("model/response",
 inPaths("multiply/out", "add/out")))));
responseUp(m, "subtract");
dependsOn

(m, ent("subtract", paths("multiply", "add")));
Context out =

response(m);


assertTrue(get

(out, "subtract"

).equals(400.0));

Slide40

Hello Arithmetic Exertion

1/1/20

Mike Sobolewski

40

Task f4 =

task

(“f4",

sig

("multiply",

Multiplier.class

),

context("multiply", input("arg/x1", 10.0d), input("arg/x2", 50.0d), result("result/y"))); Task f5 = task(“f5",

sig("add", Adder.class), context("add", input("arg/x3", 20.0d), input("arg/x4", 80.0d), result("result/y")));

Task f3 = task(”f3", sig("subtract", Subtractor.class),

context("subtract", input("

arg/x5”), input("arg/x6”), result("result/y")));Job f1= job(“f1", job(“f2", f4, f5, strategy(Flow.PAR, Access.PULL)), f3, pipe(output(f4, "result/y"), input(f3, "arg/x5")), pipe(output(f5, "result/y"), input(f3, "arg/x6")));

assertEquals(value(f1), 400.0);f3(f4(x1, x2), f5(x3, x4)) as a service composition f1(f2(f4(x1, x2), f5(x1, x2)), f3(x4, x5))with pipes from t4 and t5 to t3

Slide41

S1,2

e

1,1

N

3

Diagram

m

1

e

6,1

m2,2

m

3,1

[g: e

1,2;

e6,3]e6,*(e1,2(mx), m1(e1,1, my,2), m3,1(e1,1, ez,2, et))

g

…

…

N3

0truem2,2my,1etmxN31N32,2ez,1N32,1

Slide42

Service e1 = exertion(sig(“

doAnalysis”, Explorer.class), context(…));…Service em

= exertion (…);Service m1 = model(ent(…), ent(…), …);…Service mn = model(srv(sig(…)), ent(…), …);Condition g = condition(…); 

Service

mo

= model(

// order of entries does not matter

ent

(“e

1

”, fi(“e1,1“, e1)), ent(“m1”, m1, args(“e1”))), … ent(“m3”, fi(“m3,1”, m3), args(“e1”, fi(“ez,2”, ez))), … outEnt(“e

6”, loop(g, e6, args(“m3”, “m1”, “e1”))), response(“e6”));  dependsOn(mo, ent

(fi(“e1,2“, “e1“), “mx“), ent(“m1“, “my“), ent(fi(“m3,1

”, “m3“), fi(“e

z,2”, “ez“)), ent(fi(“m3,2”, “m3“), “et“)); Model out = exert(mo); // evaluate the model moContext cxt = result(out); // get the evaluation resultcxt = response(mo); // get declared response e6Object obj = response(mo, “e1”); // get declared response e1

Slide43

Service e1 = exertion(sig(“

doAnalysis”, Exploration.class), context(…));…Service em

= exertion (…);Service m1 = model(ent(…), ent(…), …);…Service mn = model(srv(sig(…)), ent(…), …);Condition g = condition(…); 

Service

xrt

= loop(g, block(

// services are ordered for execution

fi(“e

1,1

“, e

1

), m1, fi(“m3,1”, m3), e6, context(…, result(“opti/value”));  dependsOn(xrt, ent(fi(“e1,2“, “e1“), “mx“), ent(“m1“, “my“), ent(fi(“m

3,1”, “m3“), fi(“ez,2”, “ez“)), ent(fi(“m3,2”, “m3“), “et“)); Exertion out = exert(xrt); // execute

xrtContext cxt = context(out); // get resultcxt = value(exertion); // get declared value at opti/valueObject obj = value(xrt, “result/value”); // get value at the path result/value

Slide44

Which way to go?

SO

ModelingEO Programing

SO

Mogramming

Functional

Orientation

Service

Orientation

Managing Computing

Complexity

Managing concurrently top-down/bottom-up problem solving

Managing

Dependencies

Managing

Control

Strategies

Slide45

Exerting Dynamic Collaborations

Signature type: preprocess process postprocess append

Federation

(Processor)

SO Mogram

(Requestor)

Federation Member

Job

Task

Context

Model

Signature

SOS

Slide46

Exerting Dynamic Collaborations

Signature type: preprocess process postprocess append

Federation

SO Mogram

SOS

Federation Member

Job

Task

Context

Model

Signature

Slide47

Exerting On-demand Provisioned Collaborations

Signature type: preprocess process postprocess append

Federation

SO Mogram

Cataloger

Provisioner

Federation Member

Job

Task

Context

Model

Signature

SOS

Slide48

Exerting Dynamic Collaborations

Signature type: preprocess process postprocess append

Federation

SO Mogram

Cataloger

Provisioner

Federation Member

Job

Task

Context

Model

Signature

SOS

Slide49

Macroservice

Global Network

PS2

PS4

PS3

PS1

PS5

Provider Service

Shell

Kernel

End User Federation

Exert

SS

SS

SS

SOS Cloud

SOS

PS6

SOS Federation

Reified Service

SORCER Computing PlaformA macroservice becomes the end-user’s service federation.Creativity and innovation is transferred directly from the end user to the server.

Slide50

SORCER Operating System (SOS)

Combined request services – multi-tier

multiFi contextionsInput and outputs contexts – domain intelligence

SOS system service providers

–

network-centric intelligence

Domain service provider partnership – net-centric processor

Everything AWAT as a Service for You (

EaaaaSY

)

Combined

Global Network

PS2

PS4

PS3

PS1

PS5

Shell

Kernel

User Defined (net/local)

Service PartnershipSSSSSSSOSSOS ServicesReified Service S6SOS (net/local)ExertRequest ServicesPS6ElementaryNet-Centric Processor

Slide51

Domain-Specific Models and Services

Domains-specific Objects Contexts Data Models Imperative Models Exertions Declarative Models

Ent-Models Par-Models Var-Models Service Types e.g. Java InterfacesService Providers Beans Invokers Evaluators Getters Setters

Domain-Specific Exertions/Models are Business Local/Remote Objects in SO Programming

Providers

Contexts

Models

Exertions

SORCER

OS

Providers

Service

Slide52

Models and Types of Variables

Variable (mathematics), a symbol that represents a quantity in a mathematical expressionVariable (programming), a symbolic name associated with a value that may be changed

Variable (OO programming), a set of object’s attributes accessible via ‘getters’Model, a schematic description or representation of something, especially a system, phenomenon, or service, that accounts for its properties and is used to study its characteristics expressed in terms of entries (variables).

Slide53

Types of Variables in SORCER Models

Variable (SO modeling) – multifidelity entries ent, a collection of values

{<value/evaluator>} par, a collection of invokers {<invoker>}srv, a collection of signature-based services {<signature>} (fidelities)var, a collection of triplets {<evaluator, getter, setter>}evaluator: a composition of dependent variables getter: a pipeline of filters

setter: stores/persists a valid quantity

Slide54

Types of Models and Entries in SORCER

All EntModel, ParModel, SrvModel

, and VarModel are extended types of Context implementing a Model type.Context is a collection of interrelated functions as the following entries:Value-Entry in a Context (Data Model) – a constant functionEnt in an EntModel extending

Context

– a function with a domain consisting of other entries of its

EntModel

Par

in a

ParModel

extends

EntModel

– a function with a domain having own context and context of its ParModel. Own context overwrites its ParModel context.Srv in SrvModel extends ParModel - a function with a domain consisting of other entries of its EntModel including service signaturesVar in a VarModel extends SrvModel - a functional as a composition of three functions setter(getter(evaluator)) called a fidelity with a domain consisting of other vars in its VarModel. A var may have selectable multiple fidelities.

Slide55

ey1

Ent

(Entry) Structure

1/1/20

Mike Sobolewski

55

y1

Ent

x1

x2

x3

Dependent

Entries

dependency

entry - returns evaluated value

z

Value

vx1

vx1

ex2

ent("arg/x6", 20.0)ent("arg/x6", ent("arg/x7", 40.0))Context ModelEvaluator

Slide56

Invoker

Par (Parameter) Structure

(Multiple invocations, each with own context invocation scope)

1/1/20

Mike Sobolewski

56

y1

Par

Par Fidelities

x1

x2

x3

Dependent

Entries

dependency

Multifidelity

– selectable procedural attachment (invoker)

z

Value

y1f

iy1f2y1f1InvocationContextContext Model

Slide57

Signature

Srv

Structure

(Signature-based services in the scope of context model)

1/1/20

Mike Sobolewski

57

y1

Srv

Signature Fidelities

Dependent

entries

dependency

Multifidelity

– selectable signature/service provider

Prv

Provider

y1f

i

y1f2

y1f1Input PathsContext ModelzValuex1x2x3

Slide58

y1g

i

dy1dx1

dy1dx2

dy1dx3

dy1dx1

dy1dx2

dy1dx3

y1e

i

y1e2

y1g

i

y1fg2

Var Structure

(Evaluator/Getter/Setter/Differentiator)

1/1/20

Mike Sobolewski

58

y1

y1e1VarEvaluatorsy1g1GettersDifferentiatorsx1x2x3DependentVarsSettersValues of derivative Vars Sensitivitiesdependencydy11dx1dy11dx2dy11dx3Multifidelity – selectable fidelity for the varVar is a multi-higher-order function (multi-functionaly1s2y1s1zValueVar fidelity zfi : <y1ei, y1gi, y1si, dy1i>Context Model

Slide59

Context-Oriented Modeling (with CML)

1/1/20

Mike Sobolewski

59

In a CML modeling paradigm

entries

are used in a specific way to define heterogeneous context-oriented models, in particular

large-scale transdisciplinary models

including response, parametric, and optimization models.

The programming style CML is

declarative

; models describe the desired results of the output entries, without explicitly listing instructions or steps that need to be carried out to achieve the results. CML focuses on how entries connect – compose - in the scope of the model, unlike imperative programming, which focuses on how explicit control strategy. CML represents models as a series of interdependent entry connections, with multiple fidelities between the source of amorphousness.

Slide60

Rosen-Suzuki Model

1/1/20

Mike Sobolewski

60

design

vars

:

x1

,

x2

,

x3, x4response vars: f, g1,

g2, g3, andf = x1^2-5.0*x1+x2^2-5.0*x2+2.0*x3^2-21.0*x3+x4^2+7.0*x4+50.0g1 = x1^2+x1+x2^2-x2+x3^2+x3+x4^2-x4-8.0

g2 = x1^2-x1+2.0*x2^2+x3^2+2.0*x4^2-x4-10.0g3 = 2.0*x1^2+2.0*x1+x2^2-x2+x3^2-x4-5.0The goal is then to minimize f subject to

g1 <= 0, g2 <= 0, and g3 <= 0.

Slide61

Rosen-Suzuki Model in CML

1/1/20

Mike Sobolewski

61

int

inputVarCount

= 4;

int

outputVarCount

= 4;OptimizationModel om = optimizationModel(”Rosen-Suzuki Model", inputVars(vars

(loop(inputVarCount), "x", 20.0, -100.0, 100.0)), outputVars("f"), outputVars("g”,

outputVarCount - 1), objectiveVars(var("fo

", "f", Target.min

)), constraintVars(var("g1c", "g1", Relation.lt, 0.0), var("g2c", "g2", Relation.lt, 0.0), var("g3c","g3", Relation.lt, 0.0)));configureVarModel(om);configureSensitivityModel(om);A var-model can be a local object or remote service

Slide62

R-S Parametric Task

1/1/20

Mike Sobolewski

62

Signature

msig

= sig(

ParametricModeling.class

,

"Rosen-Suzuki Model");

String

outURL = Sorcer.getWebsterUrl() + "/rs-model/rs-out.data"; String inURL

= Sorcer.getWebsterUrl() + "/rs-model/rs-in.data";ModelTask

mt = parametricTask(sig("calculateOutTable",

msig), 

context(inTable(inURL), outTable(outURL, inputs("x1", "x2"), outputs("f", "g1", "g2")), result("table/out"), par(queue(20), pool(30))));Table table = value(mt);

Slide63

R-S OptimizationTask

1/1/20

Mike Sobolewski

63

String

home

=

System.getenv

("IGRID_HOME");

String

conminStrategyfile

= home + "/modules/engineering/optimization/conmin/data/conminrosenSuzukiMin.dat";String dispatchStrategyfile = home

+ "/modules/examples/ex10b/data/rsDispatcherStrategy.dat";Task optiTask = optiTask(sig

("explore", Exploration.class, "Rosen-Suzuki Explorer"), context(initialDesign(input("x1", 1.0), input("x2", 1.0),

input("x3", 1.0), input("x4", 1.0)),

par("optimizer/strategy", new ConminStrategy(new File(conminStrategyfile))), result("exploration/results")), strategy(Opti.MIN, dispatcher(sig(RosenSuzukiDispatcher.class)), model(sig("register", OptimizationModeling.class)), optimizer(sig("register", Optimization.class))));println(value(optiTask));

Slide64

Local var dependency

Remote var dependency

SOS service provider

Var

Evaluator (DS service provider)

Var model (DS service provider)

SOS Cloud

v

App Cloud

Ents

Model

Cloud

mogram

Ents

nsh

nsh

Exert

SOS, App, and Modeling Services

Slide65

System Agility

CAEDBSETADOMBSEACAE

SORCERDesignProduct

reconfigure

Reconfigure everything in the system

Slide66

System Amorphousness

CAEDBSETADOMBSEACAESORCER

DesignProduct

Morph system

Metadesign

Reinstantiate

system

Reconfigure system

Reconfigure everything => Sys agility => Design fidelities

Different instances of design =>

SoS

agility => Meta-fidelities

Slide67

UNIX Platform vs. SORCER Platform

UNIX

SORCERDataFile – file system

Service – dynamic service federations

Data flow

Pipes

Data context pipes

Cohesion

Everything is a file

Everything is a service

Processor

Native (instruction set)Remote/Local provider services (service federations)InterpreterUNIX ShellNetwork shell (nsh)

System languageCJava/Jini/Rio/SORCER APICommand languageUNIX shell scriptingSML (EOL/CML/VML)

Process control strategyCommand flow logicControl contexts & control flow exertionsExecutable codesMany choices

Many choices

Unix pipes – processes; SORCER pipes – data contextsCommand concatenation vs. Font ended service compositionLocal shell vs. network shell1/1/20Mike Sobolewski67

Slide68

Developing Netlets

Use SORCER project templates for a service provider and requestorBuy or develop codes and wrap as service providers

Develop a netlet with a service requestor having javac support for deploying, testing, and debuggingCopy a developed Java code into a file with a shebang ("#!nsh) and codebase artifacts includedRun/modify your file netlet with nsh for your problem solvingWhen essential updates are needed for your mogram, go to #3

Netlets are DSL programs, technically both Groovy scripts and Java sources

Slide69

Air Cycle Machine Mogram

Model airCycleModel = model("airCycleModel

", //get file offDesignCases and return the ThirdHxData object srv(sig("getThirdHxDataFromOffDesignCase", ThirdHxData.

class

,

result

(

"

offDesignCases

”

,

inPaths("ac2HexOut1")))), srv(sig("doEvaluatePropulsion", MstcGateProvider.class, result("fullEngineDeck", inPaths("offDesignCases")))), srv(sig("parseProptoACM", AcmOpenloopProvider.class

, result("acmFile", inPaths("fullEngineDeck")))), srv(sig("executeAirCycleMachine"

, AcmOpenloopProvider.class, result("acmOutFile”, inPaths("acmFile")))),

srv(sig

("getAcmOutputMakeThirdHxData", ThirdHxData.class, result("ac2HexOut2”, inPaths("acmOutFile")))));responseUp(airCycleModel, "getAcmOutputMakeThirdHxData");Block airCycleMachineMogram = block( //this is the initial guess to the iteration from the context coming in context(inEnt("offDesignCases","OffDesignCases.dat")), // holds the input data for the mstcgate call task("offDesignCases", sig("getThirdHxDataFromOffDesignCase", ThirdHxData.class, result("ac2HexOut1", inPaths("offDesignCases")))),

loop(condition("{ ac2HexOut1, ac2HexOut2 -> ac2HexOut1.equals(ac2HexOut2) }”, "ac2HexOut1", "ac2HexOut2"), airCycleModel));exert(airCycleMachineMogram);

Slide70

FSO SDLC

Maintenance

Transition

Construction

Metadesign

/Design

Analysis/

N

3

Inception

FSO

SoS

Analysis

N

3

diagramsContext ModelsService ExertionsFidelitiesMogramsConnectorsService typesService Providers