SORCER Serviceoriented Platform Mike Sobolewski sobolsorcersoft org http

SORCER: Service-oriented Platform Mike Sobolewski sobol@sorcersoft. org http: //sorcersoft. org/sobol

Outline • • Transdisciplinary Computing Physics Based Distributed Collaborative Design Service-orientation & SORCER Architecture Service-oriented Mogramming (SML) – Exertion-Oriented Language (EOL) – Context Modeling Language (CML) • Agility vs. Amorphousness in SORCER • FSO SDLC

The Next 100 Years INFORMATIO N/ DIGITAL adaptive enterprise ECONOMIC VALUE ADDED DEVELOPMENT POST INDUSTRIAL Stage 4 Mass Adoption (Saturation) Stage 3 Public Recognition (Maturity) Stage 2 Early Adopters (Growth) Stage 1 Research (Conception) 1800 Io. T SOOA, FIPER SPOA, GApp portals, Agile C WWW, SOA, CAMNet SERVICE/ MOLECUL Saa. S AR Daa. S Paa. S Iaa. S Baa. S Eaaaa. SY C/S, CE, DICEtalk OO, DPL, UML chips, OSs computing sciences solid-sate physics information theory 1900 SORCER CRISPR m. Fi SOA, SML virtualization, TST/TADOprovisioning, blockchain FIPER spintronics, quantum computing nanotech, MEMS 2000 2100 The computer is the network. ⇒ The network is the computer => The service cooperation is the computer.

Transdisciplinary Processes Transdisciplinarity: An adaptive strategy that crosses many virtual disciplinary boundaries to create seamlessly a holistic approach to dynamic complex system. Morphing Expression at Runtine Script/Result Request Service Data Control Operations Strategies Solutions Command/Result Discipline Interdisciplinary Multidisciplinary Transdisciplinary Provider Services Static 1/1/20 Morphing Actualization at Runtime Dynamic Mike Sobolewski Services: data, operations, control strategies, and solutions (request/result)

SO Overlay Network Virtual Request Network SO Overlay Network Req Req Req SML Req Multityping Virtual Provider Network OO Overlay Network Prv Prv Prv Java Prv Provisioning Physical Network TCP/IP Exec Codes HTTP NAT 5

Virtual Network of Services (S 2 S) Virtual/Overlay Network Srv Srv Srv Physical Network Srv Virtual Srv Mapping TCP/IP HTTP NAT Service (Srv) as remote/local object -> OO applied to the network 6

Design Process Vision New Process Steps (BCA): Ø Increase Disciplines & Coupling Ø Increase Fidelity Ø Leverage All Compute Resources Geographic Location A Geographic Location B Geographic Location C Empirical Linear Potential Euler Dialable Fidelity NS . . Physics Based Distributed Collaborative Design . .

N 3 Diagram e. S 1, 2 1, 1 m 1 N 31 mx m y, 1 m 2, 2 ez, 1 N 32, 2 … m 3, 1 m 2, 2 et true … g e 6, 1 N 30 [g: e 1, 2; e 6, 3]e 6, *(e 1, 2(mx), m 1(e 1, 1, my, 2), m 3, 1(e 1, 1, ez, 2, et))

Physics Based Distributed Collaborative Design (Organizational View) Good “Community Members” Publish Information for Collaborators Rocket Propulsion We are silos and there is a good reason to keep it that way Flight Control Turbine Engine Design Study X Aerospace Structures Vehicle Aerodynamics People, Tech. , Data, & Tools As Needed Real Time Access to Applications & Data by ALL Communities Aerospace Distributed Collaborative Design! Propulsion Power O V

Language – Mankind Writing – Civilization Tărtăria tablets Tortoise shells Quipu Cuneiform script Movable metal type, and composing stick, descended from Gutenberg's press Network

Front-end vs. Back-end Programming Problem Domain Runtime Domain SWLs DSLs • Java • Scripts • C, C++ • Fortran • etc. • EOL • PML • VML API Agents Express Aerospace Mograms Solution Domain Transform SORCER Incorporate /Exec Codes Language engineering is the art of creating languages

Client/Server Client Server A client can use (as is) but cannot reconfigure a server(to be).

Requestor/Provider Requestor Service Query Call Question Request Provider Service Reply Result Answer Response A requestor can use a provider as to be. SO is about configuring and managing providers.

Model vs. Program Modeling Language Programming Language Imprecise Precise Not executable Executable Overview Detailed view High level Low level Textual/Visual Textual Informal semantics Execution semantics By-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?

Mogramming: Modeling/Programming Mogram: a concept that includes programs, models, and other things. Kleppe A. , 2009. Software Language Engineering, Pearson Education

Service-orientation Restictions • Stupid network • Static connectivity

Operation and Request Services execute Client Requestor Server Provider net-centric action Operation Service Provider elementary net-activity Elementary Request Service Provider combined net-activity Combined Request Service Provider Partnership

Request Services Subroutines Service Providers Local/Remote ATUs Local Objects ATU Back End ATU Method Front End SML Mogram UML Model API args Call Message Request Service Scalability Instructions of subroutines are concatenated statically. Objects collaborations are interconnected statically. Autonomous net/local service providers cooperate dynamically as specified by request services.

OS Roles Exec Codes Local/Remote Services Servers Back End OS Front End args Script Command WB Clients UA Mogram (exertion/model) Provider services are autonomous net/local software components assembled at runtime. SOA requires a registry for provider services.

Complexity => Dependency Management Subroutine Local/Remote Services Local Objects Back End Object Method API Front End SML Model UML Model args Call Message Managing Dependencies Mogram (exertion/model)

Service Contextion & Opservices Input Context Setters Getters Values Files Connectors DBs Service Contextion Appenders Contexts Output Context Evaluators Signatures Entry Task Exec Codes Providlets

Metamodel Hierarchy of the MOF/MSF M 3 MOF <<instance. Of>> M 2 UML <<instance. Of>> M 1 M 0 EBNF <<instance. Of>> MSF <<instance. Of>> Java << instance. Of>> <<instance. Of>> Groovy SML << instance. Of>> <<instance. Of>> Netlet Request Service SORCER Model Gradle <<instance. Of>> SORCER Runtime SORCER Project Service Processor <<instance. Of>> Process Expression => Process Actualization

Process Expression vs. Actualization Expression SML Exertion EOL Service System Mogram EOL/CML Language Context Model CML Mogram Service OS OS Service Federation Processor Signatures/Entries IS Actualization

Expression vs. Actualization Process Expression Actualization Language Grammar Machine Metamodel Processor UML, SML EBNF Execution Instructions Executable Codes PE 11/3/2020 Platform OS 24

Service Orientation • SW 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 Request Service Consumers Binding Opservices Provisioning Providers SW Development ATUs Distribution Customers 11/3/2020 25

Everything AWAT as a Service for You (Eaaaa. SY) • SORCER (FSOP, SML = CML + EOL) – Service requestors • Service models (exertions/context models) – Service federations • Collaborative local/remote service providers • MADO calculator • Java (OOP) – Service types (services) • Local/remote objects • Legacy code (executable codes) – Apps, Tools, Utilities

Why Do We Need Service Systems? • 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 1/1/20 Mike Sobolewski 27

From Node to Interactional Fidelity • • • Interactions among software agents represented by network diagram Information transfer between entities via data- or state-sharing alters nodes Adaptation within the system occurs as nodestates change by interactions “Few-node systems” have dynamics that are driven by node models “Many-node system” dynamics largely result from interactions among nodes As the number of possible system adaptations increases, the logic of all possible interactions exceeds what can be understood or analyzed Simple V&V-able nodes can still lead to complex non-V&V-able system High-level languages with the relevant granularity are needed Model fidelity of individual nodes is less important than fidelity of links Few-node System Many-node System

Transdisciplinary Engineering Front End Many-node System Autonomic Provisioning Reconfigure Everything Netlet/Result Transdisciplinary Back End 1/1/20 Mike Sobolewski Static Dynamic

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 Distributed System Hierarchical System

DMC Metamodeling Architecture Var-Model (modeling) Var (composite evaluation) Srv/Par (invocation) Context-Model (modeling) EGS-Fidelities Var/Srv/Par/Ent Associations Invocation Fidelities Srv/Par/Ent Associations Evaluation Manager Response Manager Invocation Manager Response Manager Evaluation Composition Evaluation Processor Invocation Composition Invocation Processor Object Platform (object-orientation) Service Platform (service-orientation) IS Platform (computation) c m Exertion (programming) s Services Data Context Service OS Service Shell Object Processor Service Processor Exert Processor Exec Code Object (state) Servicer Provider (net centricity) Data Attributes Service Types Operation Control Strategy Methods Control Flow Manager Qo. S Classifiers Service Beans Service Type Commands OS V 1 V 2 IS Processor Object Codes class Messages OO OS V 3 V 6 V 4 V 5 FMI Signature (Qo. S) FMI use c, m, s socket generalization composition V 1, V 2, V 3, V 4, V 5, V 6 - virtualizations

Service Orientation => Mograms

From Objects to Services OO Program Field Mogram Method Model Object orientation Exertion Service Functional Programming Imperative Programming

Metamodel Conceptualization Objects State/Method Services Autonomous components Primitives Entries Signatures Providers Mograms Functions Provider references Actualization services Data Contexts Data associations Context Models Exertions Functional associations Provider federations

Services => Mograms

Service Signatures => Microservices => Provider Services

SML Metamodel Generalizations Object State/Method Service execute(Service) : Object value(Entry) : Object provider(Signature) : Object exert(Mogram) : Mogram context(Mogram) : Context value(Context, <entry-name>) : Object Elementary Service Compound Service Data Service

SML Operators Service sig prv ent par srv var exec mog exert/value/cxt/stgy value/asis mod ins/outs/response cxt xrt get/put/add/rm task block job black – declarative operators green – operational operators

Hello Arithmetic Model m = srv. Model(
 in. Ent("multiply/x 1", 10. 0), in. Ent("multiply/x 2", 50. 0), in. Ent("add/x 1", 20. 0), in. Ent("add/x 2", 80. 0), 
 ent(sig("multiply", Multiplier. class, result("multiply/out", 
 in. Paths("multiply/x 1", "multiply/x 2")))), 
 ent(sig("add", Adder. class, result("add/out”, in. Paths("add/x 1", "add/x 2")))), 
 ent(sig("subtract", Subtractor. class, result("model/response", 
 in. Paths("multiply/out", "add/out"))))); 
 response. Up(m, "subtract"); 
depends. On(m, ent("subtract", paths("multiply", "add"))); 
Context out = response(m); 
 assert. True(get(out, "subtract"). equals(400. 0)); 1/1/20 Mike Sobolewski 39

Hello Arithmetic Exertion f 3(f 4(x 1, x 2), f 5(x 3, x 4)) as a service composition f 1(f 2(f 4(x 1, x 2), f 5(x 1, x 2)), f 3(x 4, x 5)) with pipes from t 4 and t 5 to t 3 Task f 4 = task(“f 4", sig("multiply", Multiplier. class), context("multiply", input("arg/x 1", 10. 0 d), input("arg/x 2", 50. 0 d), result("result/y"))); Task f 5 = task(“f 5", sig("add", Adder. class), context("add", input("arg/x 3", 20. 0 d), input("arg/x 4", 80. 0 d), result("result/y"))); Task f 3 = task(”f 3", sig("subtract", Subtractor. class), context("subtract", input("arg/x 5”), input("arg/x 6”), result("result/y"))); Job f 1= job(“f 1", job(“f 2", f 4, f 5, strategy(Flow. PAR, Access. PULL)), f 3, pipe(output(f 4, "result/y"), input(f 3, "arg/x 5")), pipe(output(f 5, "result/y"), input(f 3, "arg/x 6"))); assert. Equals(value(f 1), 400. 0); 1/1/20 Mike Sobolewski 40

N 3 Diagram e. S 1, 2 1, 1 m 1 N 31 mx m y, 1 m 2, 2 ez, 1 N 32, 2 … m 3, 1 m 2, 2 et true … g e 6, 1 N 30 [g: e 1, 2; e 6, 3]e 6, *(e 1, 2(mx), m 1(e 1, 1, my, 2), m 3, 1(e 1, 1, ez, 2, et))

Service e 1 = exertion(sig(“do. Analysis”, Explorer. class), context(…)); … Service em = exertion (…); Service m 1 = model(ent(…), …); … Service mn = model(srv(sig(…)), ent(…), …); Condition g = condition(…); Service mo = model( // order of entries does not matter ent(“e 1”, fi(“e 1, 1“, e 1)), ent(“m 1”, m 1, args(“e 1”))), … ent(“m 3”, fi(“m 3, 1”, m 3), args(“e 1”, fi(“ez, 2”, ez))), … out. Ent(“e 6”, loop(g, e 6, args(“m 3”, “m 1”, “e 1”))), response(“e 6”)); depends. On(mo, ent(fi(“e 1, 2“, “e 1“), “mx“), ent(“m 1“, “my“), ent(fi(“m 3, 1”, “m 3“), fi(“ez, 2”, “ez“)), ent(fi(“m 3, 2”, “m 3“), “et“)); Model out = exert(mo); // evaluate the model mo Context cxt = result(out); // get the evaluation result cxt = response(mo); // get declared response e 6 Object obj = response(mo, “e 1”); // get declared response e 1

Service e 1 = exertion(sig(“do. Analysis”, Exploration. class), context(…)); … Service em = exertion (…); Service m 1 = model(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), m 1 , fi(“m 3, 1”, m 3), e 6 , context(…, result(“opti/value”)); depends. On(xrt, ent(fi(“e 1, 2“, “e 1“), “mx“), ent(“m 1“, “my“), ent(fi(“m 3, 1”, “m 3“), fi(“ez, 2”, “ez“)), ent(fi(“m 3, 2”, “m 3“), “et“)); Exertion out = exert(xrt); // execute xrt Context cxt = context(out); // get result cxt = value(exertion); // get declared value at opti/value Object obj = value(xrt, “result/value”); // get value at the path result/value

Which way to go? Functional Orientation SO Modeling Managing Dependencies Managing Computing Complexity SO Mogramming Managing Control Strategies Service Orientation EO Programing Managing concurrently top-down/bottom-up problem solving

Exerting Dynamic Collaborations Federation (Processor) SOS Federation Member SO Mogram (Requestor) Job Task Context Model Signature type: preprocess postprocess append

Exerting Dynamic Collaborations Federation SOS Federation Member SO Mogram Job Task Context Model Signature type: preprocess postprocess append

Exerting On-demand Provisioned Collaborations Federation SOS Cataloger Provisioner Federation Member SO Mogram Job Task Context Model Signature type: preprocess postprocess append

Exerting Dynamic Collaborations Federation SOS Cataloger Provisioner Federation Member SO Mogram Job Task Context Model Signature type: preprocess postprocess append

SORCER Computing Plaform Macroservice Reified Service Provider Service t er Ex Shell PS 1 Kernel PS 2 oud SOS Cl PS 6 SS SS PS 5 SS PS 3 PS 4 Global Network SOS Federation End User Federation A macroservice becomes the end-user’s service federation. Creativity and innovation is transferred directly from the end user to the server.

SORCER Operating System (SOS) Everything AWAT as a Service for You (Eaaaa. SY) Request Services SOS Services Reified Service Elementary Shell PS 1 Kernel Exert PS 6 SS S 6 PS 2 SS PS 5 SS PS 3 PS 4 Global Network Combined User Defined (net/local) Service Partnership SOS (net/local) Net-Centric Processor Combined request services – multi-tier multi. Fi contextions Input and outputs contexts – domain intelligence SOS system service providers – network-centric intelligence Domain service provider partnership – net-centric processor

Domain-Specific Models and Services Contexts Exertions Models Service SORCER Providers OS Providers Domains-specific Objects Contexts Data Models Imperative Models Exertions Declarative Models Ent-Models Par-Models Var-Models Service Types e. g. Java Inte Service Providers Beans Invokers Evaluators Getters Setters Domain-Specific Exertions/Models are Business Local/Remote Objects in SO Programming

Models and Types of Variables • Variable (mathematics), a symbol that represents a quantity in a mathematical expression • Variable (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).

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

Types of Models and Entries in SORCER • All Ent. Model, Par. Model, Srv. Model, and Var. Model 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 function – Ent in an Ent. Model extending Context – a function with a domain consisting of other entries of its Ent. Model – Par in a Par. Model extends Ent. Model – a function with a domain having own context and context of its Par. Model. Own context overwrites its Par. Model context. – Srv in Srv. Model extends Par. Model - a function with a domain consisting of other entries of its Ent. Model including service signatures – Var in a Var. Model extends Srv. Model - a functional as a composition of three functions setter(getter(evaluator)) called a fidelity with a domain consisting of other vars in its Var. Model. A var may have selectable multiple fidelities.

Ent (Entry) Structure Context Model Ent Dependent Entries y 1 Evaluator x 1 x 2 x 3 vx 1 ey 1 vx 1 ex 2 z Value dependency ent("arg/x 6", 20. 0) ent("arg/x 6", ent("arg/x 7", 40. 0)) entry - returns evaluated value 1/1/20 Mike Sobolewski 55

Par (Parameter) Structure (Multiple invocations, each with own context invocation scope) Context Model Par y 1 f 1 y 1 f 2 y 1 fi Par Fidelities Dependent Entries x 2 x 3 Invocation Context Invoker z x 1 Value dependency Multifidelity – selectable procedural attachment (invoker) 1/1/20 Mike Sobolewski 56

Srv Structure (Signature-based services in the scope of context model) Context Model Srv Dependent entries y 1 f 1 y 1 f 2 y 1 fi Signature Fidelities x 1 Signature Provider Prv x 2 x 3 Input Paths z Value dependency Multifidelity – selectable signature/service provider 1/1/20 Mike Sobolewski 57

Var Structure (Evaluator/Getter/Setter/Differentiator) Var fidelity zfi : <y 1 ei, y 1 gi, y 1 si, dy 1 i> Context Model Var Dependent Vars y 1 Getters Evaluators y 1 g 1 y 1 fg 2 y 1 gi y 1 e 1 y 1 e 2 y 1 ei Differentiators dy 1 1 dx 1 dy 1 1 dx 2 dy 1 1 dx 3 dy 1 dx 3 x 1 x 2 x 3 Setter y 1 s 1 s y 1 s 2 y 1 gi z Values of derivative Vars Sensitivities dependency Multifidelity – selectable fidelity for the var 1/1/20 Mike Sobolewski 58 Var is a multi-higher-order function (multi-functional

Context-Oriented Modeling (with CML) • 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. 1/1/20 Mike Sobolewski 59

Rosen-Suzuki Model design vars: x 1, x 2, x 3, x 4 response vars: f, g 1, g 2, g 3, and f = x 1^2 -5. 0*x 1+x 2^2 -5. 0*x 2+2. 0*x 3^2 -21. 0*x 3+x 4^2+7. 0*x 4+50. 0 g 1 = x 1^2+x 1+x 2^2 -x 2+x 3^2+x 3+x 4^2 -x 4 -8. 0 g 2 = x 1^2 -x 1+2. 0*x 2^2+x 3^2+2. 0*x 4^2 -x 4 -10. 0 g 3 = 2. 0*x 1^2+2. 0*x 1+x 2^2 -x 2+x 3^2 -x 4 -5. 0 The goal is then to minimize f subject to g 1 <= 0, g 2 <= 0, and g 3 <= 0. 1/1/20 Mike Sobolewski 60

Rosen-Suzuki Model in CML int input. Var. Count = 4; int output. Var. Count = 4; Optimization. Model om = optimization. Model(”Rosen-Suzuki Model", input. Vars(vars(loop(input. Var. Count), "x", 20. 0, -100. 0, 100. 0)), output. Vars("f"), output. Vars("g”, output. Var. Count - 1), objective. Vars(var("fo", "f", Target. min )), constraint. Vars(var("g 1 c", "g 1", Relation. lt, 0. 0), var("g 2 c", "g 2", Relation. lt, 0. 0), var("g 3 c", "g 3", Relation. lt, 0. 0))); configure. Var. Model(om); configure. Sensitivity. Model(om); A var-model can be a local object or remote service 1/1/20 Mike Sobolewski 61

R-S Parametric Task Signature msig = sig(Parametric. Modeling. class, "Rosen-Suzuki Model"); String out. URL = Sorcer. get. Webster. Url() + "/rs-model/rs-out. data"; String in. URL = Sorcer. get. Webster. Url() + "/rs-model/rs-in. data"; Model. Task mt = parametric. Task(sig("calculate. Out. Table", msig), context(in. Table(in. URL), out. Table(out. URL, inputs("x 1", "x 2"), outputs("f", "g 1", "g 2")), result("table/out"), par(queue(20), pool(30)))); Table table = value(mt); 1/1/20 Mike Sobolewski 62

R-S Optimization. Task String home = System. getenv("IGRID_HOME"); String conmin. Strategyfile = home + "/modules/engineering/optimization/conmin/data/conminrosen. Suzuki. Min. dat"; String dispatch. Strategyfile = home + "/modules/examples/ex 10 b/data/rs. Dispatcher. Strategy. dat"; Task opti. Task = opti. Task(sig("explore", Exploration. class, "Rosen -Suzuki Explorer"), context(initial. Design(input("x 1", 1. 0), input("x 2", 1. 0), input("x 3", 1. 0), input("x 4", 1. 0)), par("optimizer/strategy", new Conmin. Strategy(new File(conmin. Strategyfile))), result("exploration/results")), strategy(Opti. MIN, dispatcher(sig(Rosen. Suzuki. Dispatcher. class)), model(sig("register", Optimization. Modeling. class)), optimizer(sig("register", Optimization. class)))); println(value(opti. Task)); 1/1/20 Mike Sobolewski 63

SOS, App, and Modeling Services nsh SOS Cloud mogram Exert Ents App Cloud v Model Cloud Var Evaluator (DS service provider) Var model (DS service provider) Ents Local var dependency Remote var dependency SOS service provider

System Agility • • • CAE DBSE TADO MBSE ACAE SORCER Product Design reconfigure Reconfigure everything in the system

System Amorphousness • • • CAE DBSE TADO MBSE ACAE SORCER Metadesign Morph system Reinstantiate system Product Design Reconfigure system Reconfigure everything => Sys agility => Design fidelities Different instances of design => So. S agility => Meta-fidelities

UNIX Platform vs. SORCER Platform UNIX SORCER Data File – 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) Interpreter UNIX Shell Network shell (nsh) System language C Java/Jini/Rio/SORCER API Command language UNIX shell scripting SML (EOL/CML/VML) Process control strategy Command flow logic Control contexts & control flow exertions Executable codes Many choices Unix pipes – processes; SORCER pipes – data contexts Command concatenation vs. Font ended service composition Local shell vs. network shell 1/1/20 Mike Sobolewski 67

Developing Netlets 1. Use SORCER project templates for a service provider and requestor 2. Buy or develop codes and wrap as service providers 3. Develop a netlet with a service requestor having javac support for deploying, testing, and debugging 4. Copy a developed Java code into a file with a shebang ("#!nsh) and codebase artifacts included 5. Run/modify your file netlet with nsh for your problem solving 6. When essential updates are needed for your mogram, go to #3 Netlets are DSL programs, technically both Groovy scripts and Java sources

Air Cycle Machine Mogram Model air. Cycle. Model = model("air. Cycle. Model", //get file off. Design. Cases and return the Third. Hx. Data object srv(sig("get. Third. Hx. Data. From. Off. Design. Case", Third. Hx. Data. class, result("off. Design. Cases”, in. Paths("ac 2 Hex. Out 1")))), srv(sig("do. Evaluate. Propulsion", Mstc. Gate. Provider. class, result("full. Engine. Deck", in. Paths("off. Design. Cases")))), srv(sig("parse. Propto. ACM", Acm. Openloop. Provider. class, result("acm. File", in. Paths("full. Engine. Deck")))), srv(sig("execute. Air. Cycle. Machine", Acm. Openloop. Provider. class, result("acm. Out. File”, in. Paths("acm. File")))), srv(sig("get. Acm. Output. Make. Third. Hx. Data", Third. Hx. Data. class, result("ac 2 Hex. Out 2”, in. Paths("acm. Out. File"))))); response. Up(air. Cycle. Model, "get. Acm. Output. Make. Third. Hx. Data"); Block air. Cycle. Machine. Mogram = block( //this is the initial guess to the iteration from the context coming in context(in. Ent("off. Design. Cases", "Off. Design. Cases. dat")), // holds the input data for the mstcgate call task("off. Design. Cases", sig("get. Third. Hx. Data. From. Off. Design. Case", Third. Hx. Data. class, result("ac 2 Hex. Out 1", in. Paths("off. Design. Cases")))), loop(condition("{ ac 2 Hex. Out 1, ac 2 Hex. Out 2 -> ac 2 Hex. Out 1. equals(ac 2 Hex. Out 2) }”, "ac 2 Hex. Out 1", "ac 2 Hex. Out 2"), air. Cycle. Model)); exert(air. Cycle. Machine. Mogram);

FSO SDLC Metadesign/ Design Analysis/N 3 Inception • FSO So. S Analysis - N 3 diagrams Construction - Context Models - Service Exertions - Fidelities • Mograms • Connectors • Service types Transition • Service Providers Maintenance