Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
A Proposal for the Java Public Middleware API Vito Baggiolini SL/CO (1) Outline • Requirements • Set/Get – – – – – basic principle Interaction diagrams Java data types Overloaded vs. simple methods Exceptions • MonitorOn/Off • Data conversions • Synchronization between threads (2) Premisses • This is a proposal – intended as a productive compromise – quite some work, but needs to be discussed • This is not the BeansAPI – rather an enhanced version of Java CDEV API – BeansApi can be placed on top of this • Integration with Private MoM Client API is necessary (3) Outline • Requirements • Set/Get – – – – – basic principle Interaction diagrams Java data types Overloaded vs. simple methods Exceptions • MonitorOn/Off • Data conversions • Synchronization between threads (4) Requirements • Functional Requirements – Set/get access to (virtual) devices • sync and async • cycle-dependent or immediate – Monitoring of device properties • on-change or cycle-dependent • Non-functional requirements – – – – Simple but complete Generic (use in different types of applications) “True” Java Type safe (as far as possible) (5) “Simple” and “True Java” • Object instead of Data/DataEntry (user should not have to pack and unpack structures) • Use normal Java classes (not Data) for composite data structures • Overloaded methods where appropriate • Use return to return value in get() operations • Use Exceptions for error handling • Use Reflection for generic stuff (6) Design Overview • One generic RemoteDevice class – one RemoteDevice object per device instance – set/get, monitorOn/Off methods – no Context! • Constructor: RemoteDevice(String devClass, String devInstance); • Set/Get methods: setXXX(PropName, Value, …); Value = getXXX(PropName,…); XXX = Int, Double, Object etc. • Monitoring methods: MonToken = monitorOn(PropName, Listener); MonToken = monitorOn(PropName, CycleSel, Listener); monitorOff(MonToken); • Almost all methods throw exceptions! (7) Outline • Requirements • Set/Get – – – – – basic principle Interaction diagrams Java data types Overloaded vs. simple methods Exceptions • MonitorOn/Off • Data conversions • Synchronization between threads (8) Set/Get • Synchronous get/set int getInt(String propName); void setInt(String propName, int value); • Asynchronous get/set void getInt(String propName, ReplyListener rl); • Cycle-dependent, asynchronous get/set void getInt(String propName, CycleSelector sel, ReplyListener rl); • Filtered1, cycle-dependent, asynchronous get/set void getInt(String propName, CycleSelector sel, Filter f, ReplyListener rl); 1) Filter is for server-side filtering of property data (9) Set/Get Variants void getInt(String propName, CycleSelector sel, Filter f, ReplyListener rl); • CycleSelector == null: • Filter == null: • ReplyListener == null: same as cycle-independent no filtering one-way (“fire&forget”) (10) Synchronous set Client : RemoteDevice : DataEntry : Data : OrbClient DeviceProxy(String) setInt(String, int) <create> <create> insertInt( ) add( ) set(IoPoint, Data) <error handling> <return> (11) Synchronous get Client : RemoteDevice : DataEntry : Data : OrbClient DeviceProxy(String) getInt(String) get(IoPoint) <return Data> remove( ) extractInt( ) <return result> (12) Async get Client : RemoteDevice : ResultHandle : Data : OrbClient <create> <create> getInt(String, ReplyHandler) <create and pack> get(IoPoint) do other things... slow get action handle(Data) <unpack> (13) Data Types in Java • Java has the following data types: – 8 primitive types (int, long, float, double, byte, boolean, char) they cannot be accessed as Object – All the rest can be treated as Object (even an Array of primitive types is an Object) – Java 1.1 defines Classes corresponding to primitive types (Integer, Long, Float, Double, Byte Boolean, Character) these can be accessed as Object! • Design Issue: separate or combined methods ? (14) Proposal: separate methods • One group of methods per primitive type setInt() setLong() setFloat() setDouble() setByte() setChar() setBoolean() • One group of methods for Object types setObject() can be used for anything, including Arrays and Data/DataEntry • Complex data types are passed with setObject() they are extracted and packed into Data/DataEntry using Reflection (15) Why Methods for primitive Types? • Why not use setObject() also for primitive types? • Example: set/get of an int – set: setInt(value); setObject(new Integer(value)); – get: value = getInt(); value = ((Integer)getObject()).intValue(); A bit clumsy, isn’t it? • Many methods are no problem! – for user: as long as they are consistent and logical (and: IDE’s represent overloaded methods as one) – for performance: methods are dispatched with hashtable(16) Multiple Methods in JBuilder (17) Exceptions • java.rmi.RemoteException: if a problem is encountered in Middleware or in device • java.lang.InvalidArgumentException: if bad information is passed to a method, (e.g. an object with bad contents to setObject) (18) Outline • Requirements & Design Principles • Set/Get – – – – – basic principle Java data types Overloaded vs. simple methods Exceptions Interaction diagrams • MonitorOn/Off • Data conversions • Synchronization between threads (19) MonitorOn/Off • Monitor a property on-change: MonToken monitorOn(String propName, monListener l); void monitorOff(MonToken mt); • Monitor with CycleSelector: MonToken monitorOn(String propName, CycleSelector cs, monListener l); • Monitor all properties of an Instance (required?) MonToken MonitorAll(monListener l); • MonitorToken automatically unsubscribes if abandoned – Based on Java Garbage Collection (finalize) (20) MonitorOn client : DataListener : RemoteDevice : MonitoringToken : SubscriptionHandle : Mom/Orb? <create> monitorOn(String, DataListener) monitorOn(IoPoint, Listener) <create> <return SubscriptionHandle> <create> <return MonitoringToken> (21) MonitorOff Client JVM : MonitoringToken : RemoteDevice : SubscriptionHandle : Mom/Orb? Client-initiated monitorOff monitorOff(MonitoringToken) getSubHandle( ) monitorOff(SubscriptionHandle) Automatic monitorOff via Java Garbage Collection <abandon> finalize( ) getSubHandle( ) monitorOff(SubscriptionHandle) monitorOff(SubscriptionHandle) (22) Outline • Requirements & Design Principles • Set/Get – – – – – basic principle Java data types Overloaded vs. simple methods Exceptions Interaction diagrams • MonitorOn/Off • Data conversions • Synchronization between threads (23) Conversion Data Java types • With a static DataConverter class • Methods: Converter.getAsData(Object val); Converter.getAsObject(Data val); Converter.getAsData(int val); Converter.getAsInt(Data val); etc... • Based on Java Reflection (24) Outline • Requirements & Design Principles • Set/Get – – – – – basic principle Java data types Overloaded vs. simple methods Exceptions Interaction diagrams • MonitorOn/Off • Data conversions • Synchronization between threads (25) Callbacks and Synchronization • Problem: primary and callback thread need to be synchronized • Synchronization can be tricky! Provide synchronization facilities in Middleware Framework • Pattern “FutureReply” for Async set/get (26) FutureReply Pattern • By Greg Lavender and Doug Lea • A pattern... – Based on a 1-slot buffer with locking – Enables a producer and a consumer thread to reliably exchange data items • 3 Methods: – put(): for producer to put data item into buffer – get(timeout): for consumer to wait and take data item when it’s ready (blocking) – isReady(): for consumer to check if data is there (27) Async get with FutureReply (1) Client FutureReply : ResultHandle : RemoteDevice : Data : OrbClient <create> <create> getInt(String, ReplyHandler) <create and pack> get(IoPoint) do other things... slow get action (28) Async get with FutureReply (2) Client FutureReply : ResultHandle : RemoteDevice do other things... : Data : OrbClient slow get action isReady( ) getInt(timeout) Check if result is avaliable Block until result is available (with timeout) handle(Data) <unpack> <return of get()> (29) Our FutureReply Variant • Should have get methods similar to those of RemoteDevice – FutureReply’s getXxx() method matches type of retrieved value – Sync: double res = device.getDouble(propName); – Async: void getString(propName, futureReply); double res = futureReply.getDouble(); • FutureReply’s getXxx() methods throw Exceptions (30)