vii 2 z final slides os gi iess 2010
DESCRIPTION
Think Large, Act Small: An Approach to Web Services for Embedded Systems Based on the OSGi FrameworkIrina Astrova, Arne Koschel, Roman Roelofsen, David Bosschaert, and Volker AhlersTRANSCRIPT
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
Flexible, standardized technology combination useful Here: OSGi & ESB (Apache CXF) + ‘Java Embedding’
12
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
‘Kind of’ internal advertisement service
Frequently used for OSGi applications
17
Implementation Configuration approaches 3 options provided
Java properties
Declarative Service Spec. (DSS)
Spring-OSGi (not here)
. . .
ExampleService service = new ExampleServiceImpl(); Dictionary dict = new Hashtable(); dict.put (“expose.service”, true) ; dict.put (“expose.interface”, ExampleService.class); dict.put (“expose.url”, “http://localhost:8080/exampleService”); context.registerService (ExampleService.class.getName(),
service, dict);
<?xml version=“1.0” encoding=”UTF−8”?> <component name=“ExampleService”> <implementation class=“com.example.ExampleServiceImpl”/>
<property name=“expose.service”>true</property> <property name=“expose.interface”>com.example.ExampleService </property> <property name=“expose.url”>http://localhost:8080/exampleService </property> <service> <provide interface=“com.example.ExampleService”/> </service>
</component>
18
Implementation Remote access design Req. from 2nd scenario:
Remote Access
Two options examined Creating a remote API. Creating a proxy (which
we followed prototypically)
19
Implementation Remote access from OSGi
20
Implementation Adopting CXF for embedded Java Platforms
Java Standard Edition Embedded (Java SEE).
Almost full Java 5 spec. Only 30MB memory footprint compared to
60MB java SE Several processors
JamVM Java 5 based also Compared to Java SEE: very small
footprint and runs on ARM processors.
Java Micro Edition (Java ME) ARM processors, PowerPC and Intel x86
processors. Java ME CDC is viable for low end
devices with memory footprint starting from 2 MB.
Adoption results
Adoption easy for Java SEE and JamVM Java 5 code runs just fine JamVM required some class additions. A
few changes for java.io and java.xml required.
Java ME CDC Java 1.4 based, but can run Java 5 byte
code For new language constructs (annotations)
we used the Harmony tool for byte code weaving
Annotatiosn simulated using reflection Thus some CXF modifications required
21
Conclusion & Outlook Core contributions
Evaluation, if OSGi/CXF can meet the requirements of example scenarios.
Adoption of OSGi/CXF to Java embedded platforms in order to meet the memory restrictions of embedded systems.
Our properties based approach influenced the OSGi standard It was presented to OSGi expert group and in similar form
later used by the distributed OSGi specification.
Outlook: Current research work Asynchronous, distributed event-based messaging for OSGi
22
Questions ? Questions !
Arne Koschel
University of Applied Sciences, Faculty IV, Department for Computer Science Hannover, Germany
[email protected] www.fakultaet4.fh-hannover.de http://www.koschel-edv.de/arne_koschel_publications
Irina Astrova
Tallinn University of Technology Institute of Cybernetics, Tallinn, Estonia