Andy Smith: Would you like to introduce yourself? Andy Smith: Sure. My name is Andy Smith. I'm one of the developers working on the SODA project. SODA stands for Service-Orient Device Architecture. This is an open source project available through the Eclipse Open Healthcare Framework. These concepts were originally driven from the embedded space. So the embedded space introduces a number of different challenges. That you typically wouldn't see in the enterprise development environment. Typically, the enterprise, you have a little bit more control over the infrastructure and supporting that T. Whereas embedded systems, while they do provide a wide variety of devices, they also introduce a wide variety of vendors, manufacturers, and technologies. Andy Smith: Embedded systems basically means there's a physical piece of hardware that you're doing something with, right? Andy Smith: Right. Andy Smith: Instead of just purely software, just deploying on servers somewhere with web browsers just to contrast it from other enterprise software. Andy Smith: Correct. So adding this complexity includes running within constrained environments. Andy Smith: And these constrained environments can include anything from very small devices, such as temperature sensors, to cell phones or edge servers, which may control a number of different devices. So SODA attempts to address some of these issues. Andy Smith: One of the goals is to provide efforts to standardize and simplify the integration of these devices with the enterprise solutions by introducing a services-based model. Andy Smith: To do this, SODA attempts to leverage existing and emerging standards from the embedded and IT domains to provide well-defined interfaces for hardware devices, enabling a flow of information to and from service-oriented architectures. Andy Smith: This will allow developers and systems to interact with sensors and actuators just as the business services do today. Andy Smith: Right. Andy Smith: We'll take a look at the SODA stack. Andy Smith: The SODA stack provides a clean, logical model supporting development of interfaces to devices at the enterprise.
2:01Andy Smith: The SODA stack is comprised of a series of layers. Andy Smith: These layers include a physical device, the device interface, the agent, the application, the SOA binding, and the SOA mechanism. Andy Smith: So if you look at that from a conceptual view, so starting at the bottom and moving up, we take a look at the physical device. Andy Smith: Physical devices are typically classified as sensors and actuators. Andy Smith: So sensors read data from the real world while actuators actually push data down to affect something within the real world. Andy Smith: So an example of a sensor would be a temperature device that takes a reading for the current temperature. Andy Smith: Whereas something like a display device may take input from a controller and display that to an end user. Andy Smith: The device interface provides the low-level protocol for the device. Andy Smith: And this can either be an industry standard or it can be manufacturer specific depending on the requirement. Andy Smith: At the next layer, that agent abstracts the device into a generic device or set of messages that can interface with the application. Andy Smith: So an example of this would be a temperature agent that supports a standard temperature interface that may connect many different devices. Andy Smith: But they all provide a similar type of reading back to that temperature. Andy Smith: Right. Andy Smith: The application is typically where the business logic outside the enterprise is placed. Andy Smith: This is where the logic for filtering or combining events from devices is located. Andy Smith: The SOA binding provides the enterprise connectivity between the application and device logic. Andy Smith: This includes a variety of access alternatives depending on the environment. Andy Smith: Some examples of this could be standard web service or JMS messaging. Andy Smith: The SOA mechanism is used to describe the back-end infrastructure such as an application or process server or an enterprise service bus. Andy Smith: Right. Andy Smith: Right. Andy Smith: And so what parts of this layer are on sort of devices versus on servers somewhere?
4:02Andy Smith: So we'll get to that a little bit later on and how we broke that out in the Stepstone Reference Implementation. Andy Smith: Typically, the SOA framework down would be an edge server. Andy Smith: Right. Andy Smith: Whereas the EPC or other SOA mechanism would be at the enterprise level, so thinking more of a heavyweight application server. Andy Smith: We also use -- so for the Stepstone Reference Implementation, we're still leveraging OSGI from that. Andy Smith: But it's not directly communicating with the devices. Andy Smith: Right, right, right. Andy Smith: Correct. Andy Smith: So the OSGI parts are kind of at the application code on down layers, it seems like. Andy Smith: And of course, maybe some translation in the binding framework. Andy Smith: Well, so we're using the OSGI runtime for both sides in the Stepstone Reference Implementation. Andy Smith: All right. Andy Smith: Okay. Andy Smith: We're still leveraging the OSGI runtime, and we'll get to that a little bit later on. Andy Smith: So while SOA does not dictate a particular technology, the OSGI runtime provides a good complement to this architecture, enabling the layers to be represented as bundles. Andy Smith: So when you add existing Eclipse tooling into the scenario provided -- so adding existing Eclipse tooling into this scenario provided some of the foundation for the Stepstone Reference Implementation. Andy Smith: Stepstone was developed through a collaborative effort between IBM and the University of Florida. Andy Smith: Stepstone provides a reference implementation that delivers a patient monitoring system that demonstrates how SOA and supporting tools can be used to build wellness and healthcare systems through embedded technologies, SOA, and open standards. Andy Smith: So some of the core components in the Stepstone Reference Implementation are, for one, OSGI. Andy Smith: We also leverage DeviceKit, which enables the development of Java applications that interface with physical devices that run as OSGI services. Andy Smith: And then SAT provides tooling that enables easier management of dependencies and services in an OSGI environment. Andy Smith: And are those -- are those all open source things that you use for it, or what are the exact implementations of those things that you have?
6:05Andy Smith: Yeah, those -- so both of those projects are available on the Open Healthcare Framework site. Andy Smith: Okay. Andy Smith: So you guys actually made those yourself? Andy Smith: So that wasn't part of the Stepstone Reference Implementation. Andy Smith: Those were already existing, and we leveraged those. Andy Smith: So the Stepstone -- the Stepstone project can be broken into two sections. Andy Smith: There's the edge, and then there's the back end. Andy Smith: So the edge is the component that provides a reference implementation for a runtime that would typically reside on the edge of the network, Andy Smith: communicating with the devices over a variety of different protocols. Andy Smith: And so those protocols can be Bluetooth or serial for 802.11, for example. Andy Smith: In the Stepstone scenario, the edge resides in the home of the patient and provides a controller for various devices in the home. Andy Smith: The edge also leverages device kit, SAT and OSGI, to expose these devices as standard web services that interface with an SOA back end. Andy Smith: So the back end serves as a reference service-oriented architecture for the reference implementation. Andy Smith: The back end provides a data store allowing the events from the devices to be stored and viewed in a web application running in an OSGI environment. Andy Smith: Since both the edge and the back end applications are deployed in an OSGI environment, Andy Smith: this enables a flexible and pluggable framework to deploy and manage new devices and applications.