This slideshow presents the basics of the 2009 RoomWare Server defintiion

1. RoomWare Server
2009 version

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

5. Making this possible
Device Device
Device Device
Device Device

6. And this
Local machine
Device Device
Other machines
in the network
Device Device
The web
Device Device

7. Using RoomWare Server
Device Device
Device RoomWare Device
Server
Device Device

8. Sockets
Device Device
Socket Socket
Device Socket RoomWare Socket Device
Server
Socket Socket
Device Device

9. And Mediators
Device Device
M M
Device M RoomWare M Device
Server
M M
Device Device

10. Mediators
Events, Requests, Responses
Device M M Device
• Mediators translate the data to something
the other party can understand
• Communication is between mediators

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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..

17. Plugins
Events, Requests, Responses
Device M P K P M Device
RoomWare
Server M Mediator
P Plugin
K Kernel

18. 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

19. Plugin “A”
Event
Event Data
Event name
Event list
Event name
Subscriber Plugin “B”
Subscriber Plugin “D”
Subscriber Plugin “N”

20. Events
• Are broadcasted to anyone who listens
• Have no return address

21. Plugin “A”
Request
Request Data + Plugin ID Plugin “A”
Event name
Event list Data
Event name
Subscriber Plugin “B” Response
Subscriber Plugin “D” Response
Subscriber Plugin “N” Response

22. Request
• Are broadcasted to anyone who listens
• Have a return address
• Recieve a Response with the requested
data

23. The Kernel
Device Device
M M
P P
Device M P K
P P M Device
P P
M M
Device Device
RoomWare
Server

24. Kernel
• The Kernel is “Communication Central”
• It distributes the Messages to the right
Plugins
• It has no memory of what has happend
before

25. More details
• The next slides show how the plugin is
connected to the mediator and how
communication takes place

26. RoomWare Server
Post
Message
handler
Recieve
Socket
Plugin
Mediator
Socket
Post
Recieve Message Device Device
Device
handler handler driver

27. 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

28. 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

29. 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

30. Making this possible
Device Device
Device Device
Device Device