2. Why change?
• Easier to develop and plugin new “Devices”
• More flexibility to connect anything to
anything
• No dependency on Java
• Stable RoomWare Server core / new
devices are developed outside the
RoomWare core
3. Offering freedom for all
• Everything is message based
• For the Server any RoomWare Device is
like any other RoomWare Device
• Any “Device” can address any other
“Device”
• Any “Device” can send messages to any
other “Device” to state their events, their
wishes and needs
4. Using sockets
• Sockets are “pipelines” over a TCP/IP connection
• They are bi-directional and platform independent
• They can be created in PhP, Java, Flash, C#, Python
and so forth
• They run locally without a Web Server
• They have a proper event-model for pushing data
from “A” to “B” and back
• They will be used to connect anything to anything,
using the RoomWare server as a switch
10. And Mediators
Device Device
M M
Device M RoomWare M Device
Server
M M
Device Device
11. Mediators
Events, Requests, Responses
Device M M Device
• Mediators translate the data to something
the other party can understand
• Communication is between mediators
12. Mediator
• Connects a “Device” with the RoomWare
server
• Translates “Device” data to XML
• Translate data from other sources to
actions in the “Device”
• Communicates to RW Server via Sockets
• Data is standard XML
• Communication is Bi-directional
• Event or Request based
• Device can be another RoomWare Server
13. Devices
Messages, instructions, data
Device Device
• Devices can be anything (sensors, web
sites, desktop applications, electronics,
readers) and communicate in any protocol
• Very likely they do not understand each
other without a Mediator
14. Messages
<request name="getbluetoothlist" context="" devicename="BT reader Room2">
<data>
</data> <event name="newbluetoothdevice" context="request" devicename="BT reade
</request>
<data>
</data>
</event>
• Each “Device” can send to- and recieve
messages from any other devices
• A message can be a Request, a Response or
an Event
• Each message can contain data and
instructions
15. Message types
• <event: sent by device, to all listeners
• <request: named request from one device to all
listeners. Has a “context”
• <response: named response from listener to a
request, sent only to requester. Reflexts the
context as given by request
16. Message header
• Headers: <event <request <response
• Header data:
• listener: name of request, response, event listener
• context: local context - used to split responses / link them to a
context
• mediatorname: logical name of mediator in mediator via mediator
definition XML
• For response
• destinationid: specific address of device to send response to
• By RoomWare kernal - always added to message
• sourceid: ID of device assigned by kernal
• timeposted: moment the RoomWare kernal passed the request /
response / event
17. Inner Workings
RoomWare Server
Kernel
The bridge between the mediator
Plugin
and the kernel
Software that mediates between the
Mediator
RoomWare server and the “Device”
Device Can be websites, readers, sensors, etc..
18. Plugins
Events, Requests, Responses
Device M P K P M Device
RoomWare
Server M Mediator
P Plugin
K Kernel
19. Plugins
• A Plugin represents a Mediator and via the
Mediator the RoomWare Device
• When Mediators connect to the
RoomWare Server they get their own
Plugin in the RoomWare Server
• Each Plugin recieves an unique number
from the RoomWare server for internal
communication
• Each Plugin is subscribed to one or more
lists to recieve Events and Requests
20. Plugin “A”
Event
Event Data
Event name
Event list
Event name
Subscriber Plugin “B”
Subscriber Plugin “D”
Subscriber Plugin “N”
22. Plugin “A”
Request
Request Data + Plugin ID Plugin “A”
Request name
Request list Data
Request name
Subscriber Plugin “B” Response
Subscriber Plugin “D” Response
Subscriber Plugin “N” Response
23. Request
• Are broadcasted to anyone who listens
• Have a return address
• Recieve a Response with the requested
data
24. The Kernel
Device Device
M M
P P
Device M P K
P P M Device
P P
M M
Device Device
RoomWare
Server
25. Kernel
• The Kernel is “Communication Central”
• It distributes the Messages to the right
Plugins
• It has no memory of what has happend
before
26. More details
• The next slides show how the plugin is
connected to the mediator and how
communication takes place
27. RoomWare Server
Post
Message
handler
Recieve
Socket
Plugin
Mediator
Socket
Post
Recieve Message Device Device
Device
handler handler driver
28. Mediators and Plugins
• The Mediator connects each “Device” to the
RoomWare
• Each Mediator consists of a Message Handler and a
Socket connector
• For each Mediator, the RoomWare server creates
a Plugin to deal with the internal communication
• The connection between a Mediator and a Plugin
is done via a Socket
• The Plugin sends and recieves Messages to and
from the Kernel and to and from the Mediator
• The Kernel acts like a mail man and handles the
actual distribution of messages between Plugins
29. RoomWare Server
Events, Requests, Responses
Plugin Plugin
Post Receive
Message Message
handler handler
Receive Post
Socket Socket
Kernel
Communication
Mediator Mediator
Events, Requests, Responses
“Device” “Device”
Messages, instructions, data
30. Flow
1. A “Device” is connected to a Mediator (software)
2. The Mediator creates a connection to the
RoomWare server via a Socket
3. The RoomWare Server creates a Plugin for the
Mediator
4. This Plugin is registered with a unique ID in the
Kernel
5. Each Mediator passes an XML definition to the
Plugin to state to which Events and Requests it
subscibes to
6. When Mediator “A” sends a relevant message for
Mediator “B” the Kernal will pass that message to
the Plugin of Mediator “B” based on the
subscription to different lists