Think Large, Act Small: An Approach to Web Services for Embedded Systems Based on the OSGi Framework Roman Roelofsen Prosyst Köln Germany David Bosschaert Progress Dublin Ireland Volker Ahlers University of Applied Sciences and Arts, Hannover, Germany Arne Koschel University of Applied Sciences and Arts, Hannover, Germany Irina Astrova Institute of Cybernetics Univ. Tallinn Estonia
Think Large, Act Small: An Approach to Web Services for Embedded Systems Based on the OSGi Framework Irina Astrova, Arne Koschel, Roman Roelofsen, David Bosschaert, and Volker Ahlers
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Think Large, Act Small: An Approach to Web Services for Embedded Systems Based on the OSGi Framework
Roman Roelofsen Prosyst
Köln Germany
David Bosschaert Progress
Dublin Ireland
Volker Ahlers University of Applied Sciences and Arts,
Hannover, Germany
Arne Koschel University of Applied Sciences and Arts,
Hannover, Germany
Irina Astrova Institute of Cybernetics
Univ. Tallinn Estonia
And now something different
Let‘s get a bit technical Beware – Some code included
3
Agenda Background, Scenarios, Requirements
Adding ESB / Web services based Distribution Capabilities to OSGi Challenges with embedded Web Services OSGi & Apache CXF Implementation details Adoption to smaller devices: Java VM choices
Conclusion
4
Background Project Setup Cross country research (Germany, Estonia) /
Industry (Ireland, USA) cooperation including ‘on-site’ development in Ireland
Software vendor (espec. middleware) Enhancements for IT services standards
specification (including OSGi / Web services) ‘in mind’
5
Background SOA, ESB, Web Services Service Oriented Architecture is a
distributed system architecture concept
Services with well described interface(s)
Service / Messaging Backbone Often: Logical / Technical
“Enterprise Service Bus (ESB)”
Integration of components often based on productive systems
Different communication paradigms Request-Response; Oneway; …
Implementation possible with different technologies, e.g.
CORBA, Web Services, Java EE, .Net, . . . Web Services w.WSDL, SOAP typical
6
Background Embedded Systems Smaller memory footprint ‘Typical’ processors
ARM: 32 Bit, low power consumption, typical for mobiles, PDAs
some Power PC (e.g. PlayStation) some Intel X86
‘Passing by’ service providers typical if used ‘in movement’
7
Scenarios Why Embedded Web Services? Web services usually used in
large distributed systems.
Two example scenarios from in-car embedded devices Car tracking Advertising
Attributes of both Inside car communication
with ‘outside world’ servers, e.g. via UMTS network.
Web services usage, thus dynamic service offerings will occur.
8
Requirements Requirements Driven by Scenarios R1: Exposing Information for External Consumers
Car tracking service should be independent of a specific car manufacturer; respect existing standards like SOAP to enable third-party integration; expose the (same) information using different technologies at the same
time (to broaden the number of perspective users) ease technical consumption of information, so no new proprietary
protocols and semantics should be introduced.
R2: Accessing External Information Advertising service
needs to access external information using existing standards like SOAP (car tracking service exposes them);
should abstract from underlying technologies to ease consumption of external information.
9
Requirements Requirements Driven by Scenarios R3: Enable Simultaneous Use of Technologies
Depending on the services offered to or by the in-car embedded device, different technologies will be used. However, the use of one technology should not prevent the in-car embedded device from using another technology. Since the technologies may evolve independently from each other, the in-car embedded device should be able to replace the technologies. On the other hand, different technologies may be used at the same time. However, a simultaneous use of technologies should not lead to an inconsistent environment.
R4: Facilitate Loose Coupling between Services and Technologies The term loose coupling usually refers to the coupling between services and
consumers, especially over a network. Here, the coupling between services and technologies is getting observed. Services may use different technologies at the same time. However, they may not know in advance, which of the technologies will be used. Therefore, a loose coupling between services and technologies is required.
10
Agenda Background, Scenarios, Requirements
Adding ESB / Web services based Distribution Capabilities to OSGi Challenges with embedded Web Services OSGi & Apache CXF Implementation details Adoption to smaller devices: Java VM choices
Conclusion
11
Implementation
Design Issues: Embedded Web Services
Independent transport protocol Scenarios have highly independent parties, so multiple
independent Web services transports are required (e.g., not only HTTP)
Highly dynamic service offerings A full WS stack would help, but embedded devices might be
too small wrt their resources Nonetheless: WS standard required
Implementation Used Technology: OSGi Standardized, small
footprint ‘in memory SOA’ for Java
OSGi core Bundles and
services for modularization and encapsulation
13
Implementation Used Technology: OSGi OSGi was selected for several reasons, including (but not limited to)
its dynamic service capabilities – suitable for ‘in movement scenes’ Bundles and service ‘come and go’ in different, independent versions at
runtime Local OSGi service registry (SR) Deployable on all kind of devices ‘from sensor nodes to mainframes’ Bundle concept increases the isolation between different modules
As long as the metatdata is properly defined, OSGi provides a notion of execution environments to select bundles/capabilities based on the current hardware or environment; thus, a fair bit of hardware independency
Java based Java Community Process (JCP) standard
Missing in OSGi at that time though distribution features
14
Implementation Used Technology: Apache CXF Free, open source Small footprint, multiple protocol ESB Fits well to requirements
Info exposure Read OSGi service registry for service properties
External information access ESB abstracts from local / remote view
Simultaneous use of technologies ESB abstracts transparently from multiple technologies
Loose coupling between services and technologies Bundles use different configurations No knowledge about technologies required that process the specified properties
to create an endpoint. Scenarios have quite heterogeneous distributed environment where different
networks or services may need different technologies. CXF allows these independent parties to use the needed technologies while
participating in other networks or with other services provided that a common set of technologies exists.
15
Implementation Independent Bundles
‘CXF’ and ‘Web service’ are provided as 2 independent OSGi bundles, thus CXF bundle can be installed after the
Web service bundle and removed after a certain time.
To enforce a loose coupling between the two but still enable the use of each other, the Whiteboard pattern was applied
16
Implementation
Whiteboard pattern Originally alternative to listener/observer pattern