Download Data - Cern

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
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)