Stanford University Engineering Informatics Group http eil stanford

Stanford University Engineering Informatics Group (http: //eil. stanford. edu) Ubiquitous Computing Environment for Engineering Services • • • David Liu Jim Cheng Pooja Trivedi Kincho Law Gio Wiederhold Department of Electrical Engineering Department of Civil and Environmental Engineering Department of Computer Science

Agenda • Ubiquitous Computing Environment – Overview – Demo • Service Integration – FICAS 2 Stanford University

Ubiquitous Computing – An AEC Scenario 3 Stanford University

An Integrated Service Environment 4 Stanford University

Ubiquitous Computing – Research Issues • Accessibility – Wireless Network Infrastructure – Wireless Devices – Device-independent Software Services • Interactivity – Data Integration Methodology – Software Integration Infrastructure 5 Stanford University

Distributed Engineering Service and Integration Mediators (Content and Access) Information Exchange (DBMS, PSL, IFC, XML) Service Integration (FICAS) Engineering Application Services 6 Stanford University

Supporting Multiple Devices Via Active Mediator 7 Stanford University

Using PSL As Standard Exchange Language 8 Stanford University

Using FICAS For Service Integration 9 Stanford University

Putting It All Together – Demonstration 10 Stanford University

Review Design on 4 D Viewer 4 D Model Taken on 3/25/2001 From 4 DViewer 11 Stanford University

Review Schedule on Primavera 12 Stanford University

Review Schedule on Microsoft Project 13 Stanford University

View Schedule on Site http: //171. . . !! http: //med. . . !! SCHEDULE Review the schedule and make appropriate updates by changing the value in duration: SCHEDULEID STARTDATE DURATION 18 T 1 -33201 01 -31 -2001 1. …………. . Update 18 T 1 -33241 02 -01 -2001 History SCHEDULE Review the schedule and make appropriate updates by changing the value in duration: SCHEDULEID STARTDATE DURATION 18 T 1 -33201 01 -31 -2001 1. …………. . Update 18 T 1 -33241 02 -01 -2001 14 Stanford University

Modifying Schedule On-site http: //med. . . !! SCHEDULE History Review the schedule and make appropriate updates by changing the value in duration: SCHEDULEID STARTDATE DURATION 18 T 1 -33201 01 -31 -2001 40…………. . Update 18 T 1 -33241 02 -01 -2001 Change duration of activity 18 T 1 -33201 (“Erect Roof Elem 1”) From 1 day to 40 days 15 http: //med. . . !! SCHEDULE History Review the schedule and make appropriate updates by changing the value in duration: SCHEDULEID STARTDATE DURATION 18 T 1 -33201 01 -31 -2001 40…………. . Update 18 T 1 -33241 02 -01 -2001 Stanford University

Information Flow Chart 4 Desktop Browser Palm 3 Microsoft Project 1 Primavera P 3 2 4 DViewer Active Mediator XML PSL Oracle 8 i Relational Database 16 Stanford University

Review Modified Schedule on Primavera 1 17 Stanford University

Review Modified Design on 4 D Viewer 2 4 D Model Taken at 3/25/2001 From 4 DViewer 18 Stanford University

Review Modified Schedule on Microsoft Project 3 19 Stanford University

Review changed activities in Desktop Browser 4 Actual Change Affected Activities 20 Stanford University

FICAS (Flow-based Infrastructure for Composing Autonomous Services) 21 Stanford University

Service Composition 22 Stanford University

Service Composition Infrastructure • A Method to Specify Functionality – A compositional language – CLAS (Compositional Language for Autonomous Services) • A Method to Integrate Software Applications – A access protocol for desired software functionalities – ASAP (Autonomous Service Access Protocol) • An Environment to Execute Composed Services – A runtime environment that coordinates control-flows and data-flows – FICAS (Flow-based Infrastructure for Composition Autonomous Services) 23 Stanford University

CLAS (Compositional Language for Autonomous Services) 24 Stanford University

CLAS • Compositional Language for Autonomous Services – – A high-level declarative language Based on CLAM language developed in CHAIMS Simple (Intended for domain experts, NOT technical experts) Separation between composition and computation • Features – Decomposition of a CALL statement into 4 primitives • SETUP, INVOKE, EXTRACT, TERMINATE – Control primitives • IF … THEN … ELSE • WHILE – Mobile class • For specifying computational logic 25 Stanford University

Mobile Class for Specifying Computational Logic • Mobile Class – Java based – Dynamic routines that performs complex computational logic – Reusable /* Specification of a type conversion mobile class */ public class int 2 float implements Active. Node { public Data. Element execute(Vector params) { Data. Element arg = • Example of Mobile Class – Relational operators cond (A), attr (A), A cond B – Arithmetic operators +, -, , / – Data aggregation and abstraction – Type conversions (Data. Element) params. first. Element(); int val = arg. get. Int. Value(); return new Data. Element(). set. Value( new Double(val). double. Value()); } } /* Using m-class in a CLAS program */ floatnum = MCLASS("int 2 float", num) 26 Stanford University

Sample CLAS Program 1 Scheduling. Demo "http: //ficas. stanford. edu/Megaprogram" { /* Setup Services */ psl_svc = SETUP("SIPsl") p 3_svc = SETUP("SIP 3") notification_svc = SETUP("SINotification") /* Invoke and extract information from PSL Service */ psl = psl_svc. INVOKE("to-psl", "CEIL") ceil = psl. EXTRACT() /* Invoke Rescheduling Service */ p 3 = p 3_svc. INVOKE("reschedule", ceil) ceil 2 = p 3. EXTRACT() /* Store information using PSL Service */ oracle = psl_svc. INVOKE("to-oracle", ceil 2) status = oracle. EXTRACT() /* Invoke Notification Service */ notif = notification_svc. INVOKE("171. 64. 55. 32", 8250, status) } 27 /* Terminate Services */ psl_svc. TERMINATE() p 3_svc. TERMINATE() notification_svc. TERMINATE() Stanford University

Sample CLAS Program 2 /* Megaservice specified in CLAS */ Invocation 1 = Service 1. INVOKE(); Invocation 2 = Service 2. INVOKE(); A = Invocation 1. EXTRACT(); B = Invocation 2. EXTRACT(); Invocation 3 = Service 3. INVOKE(A, B); C = Invocation 3. EXTRACT(); Invocation 4 = Service 4. INVOKE(C) D = Invocation 4. EXTRACT(); 28 Stanford University

ASAP (Autonomous Service Access Protocol) 29 Stanford University

Autonomous Service Metamodel • Service Core – Represents the core service functionality – Wraps an existing software application • Data Containers – Handle input and output data – Form data-flows – Enable distributed data-flows • Event Queues – Handle inquiries and issue requests – Form control-flows – Enable asynchronous service invocations 30 Stanford University

Autonomous Service Access Protocol (ASAP) • ASAP – A light-weight, asynchronous and non-blocking event-based protocol – Defines how autonomous services respond to events – XML is used as transport medium for both control and data • ASAP Events – – 31 SETUP, TERMINATE: Initialization / termination of autonomous services INVOKE: Invocation of autonomous services MAPDATA: Management of data-flow between autonomous services CONTROLFILE: Execution of megaservice control files Stanford University

Autonomous Service Mediator (ASM) • Purposes of ASM – Facilitate wrapping of software applications into autonomous services – Implement data containers and event queues – Implement ASAP protocol public interface Service. Core { public boolean setup( Container inc, Container outc, Flow. Id inf); public boolean execute( Container inc, Container outc, Flow. Id inf); } 32 public boolean terminate( Container inc, Container outc, Flow. Id inf); Stanford University

FICAS Runtime 33 Stanford University

Overall FICAS Architecture 34 Stanford University

Service Integration Models 35 Stanford University

Data Dependencies within Megaservice /* Megaservice specified in CLAS */ Invocation 1 = Service 1. INVOKE(); Invocation 2 = Service 2. INVOKE(); A = Invocation 1. EXTRACT(); B = Invocation 2. EXTRACT(); Invocation 3 = Service 3. INVOKE(A, B); C = Invocation 3. EXTRACT(); Invocation 4 = Service 4. INVOKE(C) D = Invocation 4. EXTRACT(); 36 Stanford University

Event Dependency Graph – 1 C 1 D Service 1 Mega. Service 2 Service 3 Service 4 37 Stanford University

Event Dependency Graph – 1 Cn. D Service 1 Mega. Service 2 Service 3 Service 4 38 Stanford University

Performance Evaluation – Sample Scenario 10 Mbps or 1 Mbps Oracle. To. PSL Primavera P 3 Notifier 10 Mbps Measure Mega. Service Performance Under: 1 Cn. D (FICAS) 1 C 1 D (SOAP) LAN (10 mbps) 802. 11 (1 mbps) 39 Stanford University

Performance Evaluation – SOAP v. s. FICAS 1 C 1 D does NOT scale well with large data volume and limited network resources 1 Cn. D scales well 40 Stanford University

Effects of Control-flows on Performance 0 : message set up cost d : data message size / control message size 1 Cn. D becomes more efficient 41 Stanford University

Using Active Mediation for Performance Optimization Example: Type Conversion Using Broker Services versus Mobile Classes J. Ockerbloom, "Mediating Among Diverse Data Formats", Carnegie Mellon University, Ph. D. Thesis, 1998. 42 Stanford University

Executing M-class on Active Mediator 43 Stanford University

Implement “Output = SELECT 10 rows(R)” 44 Stanford University

Performance Comparison of SOAP and FICAS 45 Stanford University

Performance Under Different Mobile Class Placements 46 Stanford University

Distributed Component Models CORBA SOAP (Web Service) FICAS Data Representation CDR (Common Data Representation) XML Language Paradigm Method Call Procedure Call Invocation Model Client-Server Active Mediation Dataflow Model Centralized Distributed Synchronicity Sync / Asynchronous Transport Protocol IIOP HTTP, SMTP TCP Remote Reference Proxy Reference URL Service Description CORBA IDL (Interface Description Language) WSDL (Web Service Description Language) N/A Locating Services CORBA Naming Service UDDI (Universal Description, Discovery and Integration) Autonomous Service Directory 47 Stanford University

FICAS Summary • Objective – Investigate revolutionary approach to large-scale software composition • Approach – Develop and validate a distributed data-flow based service composition framework • Contributions – A high-level language (CLAS) that separates composition from computation – Protocol (ASAP) support for constructing autonomous services – Performance optimization with data-flow distribution – Active mediation to extend the capability of the compositional language and to facilitate data-flow optimization 48 Stanford University